How to be successful in the cloud?

Teams switching from traditional environments to a cloud model face many challenges. Working with cloud demands new skills from the team and a radical different approach to the development of software.

What are the factors that contribute to success?

To be able to survive in the cloud, a team needs to understand measuring. One does not simply drive to Italy with the dashboard blacked out and the windshield painted black. A team needs to implement measuring to see where they are going. This means application, infra and team metrics.

In order to take advantage of what the cloud has to offer, a team needs to invest in automation. Fully automated build pipeline, scaling infra, infra as code. These are fundamental for working in a cloud environment. They are also very practical when you work in a traditional environment, so you can start whenever you want.

A team needs to be multifunctional, this means that the team should be able to develop and maintain their product. Not all team members need to be able to do everything, but in total the team should not need external support. 

When a team needs to make decisions they should be able to do so themselves. They should not need to get authorizations from anybody else. After all a team knows best what they and their application is doing. A team should be in control of all their environments, pipelines, application and development.

Learning is the most important factor when it comes to working in the cloud. Continuous improvement can only be achieved by letting things fail, inspect and measuring. Teams need to learn how to fail fast, inspect early and improve skills and architecture.

How to be successful?

Measuring is done by defining KPIs with the team. Define reachable goals on performance, predictability, learning. Think about what you and your team want to improve and start measuring that. Make a simple and broad dashboard on which you show our KPIs and rework them on a regular basis. For the application and infra tools like ELK, Graphana en Prometheus can help a lot in getting insights in the application performance.

Rigorous automation is mandatory. By automating manual processes, a lot of time and quality is gained. Reserve enough time to improve automation. It is important that all team members contribute, all disciplines can reduce work and improve quality by automation. Build pipelines, automate triggers, incorporate quality.

Have you ever seen toddlers playing in a sandbox? Notice that they sit next to each other and play their own game. Only after they grow they learn to play together and share toys. This is the same behavior we see in teams, everybody working hard in their own discipline. It is only after we pair and learn to share knowledge and develop each others skills that we become more mature in our work and can become multifunctional. One of the nicest workshops you can do is to make T-shape profiles with the team. People will find shared interest that they can use to team up. 

To get authorization to the team, we need more than just the team. Management and change advisory boards must be willingly to give away their powers. But with great power comes great responsibility as well. So the team should be very transparent in order to gain the powers. This starts with getting grip on the flow in your work. Create a value stream map for all the products you create. Map the delays, risks and dependencies. Get management involved in the flow of things and your challenges. This will build trust and will grant you more powers.

You can only really be successful if you know how to fail. Make failure small and simple, define quality standards, inspect all failures thoroughly in order to learn. Involve the people around the team in the inspection and learning process. One start is to learn how to read error log files with the team, inspect stack traces and logfiles. You can also use tools to try to break your application like chaos monkey or attack proxies.

Have success

When you implement the points above you have a good jump start at being successful in the cloud. By regular inspection and being transparent, you, your team and the people you depend on can help grow a successful cloud implementation. And the beauty is, that it also works if you working in a more traditional environment.

What are the characteristics of a DevOps team?

Putting Ops in a Dev team or vice versa it is not sufficient for practicing DevOps. There is more to it. So what does a DevOps team typically do?

1. Measure

A DevOps team measures itself, it's product and the business value it generates. The team measures itself via feedback and reviewing of goals. The product is measured via tests through automated pipelines and value is measured via stakeholders and performance indicators in the application it builds.

2. Performance

A DevOps team strives for performance and improvement at all time. By regular inspection a DevOps team looks for performance improvements in the way of working, in the application and in its organisation.

3. Risk and refactoring

A DevOps team will do risk analysis, refactoring and supports secure coding and operation. The team is on top of its game when it comes to security and uses tools to measure the static code and does penetration testing on the running application. It refactors code, rewriting code blocks for better performance, improving code quality and readability. 

4. Automation

A DevOps team will strive for full automation of changes from testing, building, deploying to maintaining. Full automation is achieved by coding a pipeline, using gates to test for quality and automate deployment. They get rid of all manual actions in the process. They try to achieve a self healing system when production falters.

5. Transparency

A DevOps team is always transparent and open in what work and when they perform it. Visual management is available for all who want to see it, that is the team, but also stakeholders and leaders. Opening up the ability for them to help and improve.

6. Vision

A DevOps team has a vision and strategy for each product they support. That vision is derived from the company vision. Strategic goals are the lighthouse on the horizon for the teams, so they can create focus on what needs to be done. Vision created by leaders must be simple and clear for everybody to understand.

7. Mixed roles

Members of DevOps teams work together mixed in multiple roles. Not everybody needs to be able to do everything, but the team should have the capabilities to do everything. No outside support should be needed. With pairing knowledge is shared so there is no local hero or one weak spot.

8. Dependencies

A DevOps team keeps track of all life cycles, versions, licenses and dependencies it uses. By actively managing dependencies a lot of misery is avoided. Understanding versioning and deprecation is mandatory for good life cycle management on dependencies, but also for the application that is built.

9. Autonomy

A DevOps teams strives for full autonomy and loose coupling in the organisation, processes and technology. Hard coupling makes a team dependent on other parts of the organisation or on a certain technology. By trying to interface with dependent things, dependencies are loosened, which makes the team and application more flexible.

10. Responsibility

A DevOps team is solely responsible and in full control for the product they work on. This must be supported by leaders. Leaders are stakeholders and impediment removers, they support the team in improving performance, they should not interfere with the work that needs to be done. If they need to interfere it is via the vision, mission and strategic goals they develop for the team.

Disclaimer: A team practicing DevOps does what's on this list, but a team that does what is on this list is not per se practicing DevOps.

Good is just not good enough

You have tried as hard as you could, only to find out you have been beaten. Sometimes doing your best just isn't good enough. This doesn't mean you didn't try. It just means that someone or something else was better than you. High performance teams want to deliver fantastic products for their customers and they need to work hard for it.

Fantastic products
In order to create great or fantastic products for your customer you need to create quality. You need to deliver your best performance and try for even more. Most customers don't precisely know what they want, but they have a fair understanding of the problem they are facing. They should name their wishes but not the solution. You have a fair understanding of all the possibilities and are in a position to come up with even more after a couple of hours of digging.

In order to create the best solution for a customers problem, find out the problem behind the question they are asking. Try and create a solution to the best of your abilities and include the customer. While you are in the solution process you and the customer are finding even more solutions to the problem you are facing. Fantastic products are fantastic because they seem simple. This often means that the process of coming to that solution is hard. Performance is key to simple solutions. Not text book solutions, but solutions that are the result of a creative process between you, your team and the customer.

What is good, what do our customers think is good
A right solution for the customer doesn't mean it is good enough for us. Do we want to deliver what the customer wants or do we want to deliver solutions that make us proud? Sometimes they match, most of the time they don't. Push your team to the best solution, the one that looks simple but is most of the time hard to obtain. A seemingly simple solution will make the customer happy, make the team better and makes the product easier to maintain.

How do we find the sweet spot
In order to find the solution that fits our customer and our needs we need to find the sweet spot. We cannot achieve victory without making choices. And sometimes we need to make sacrifices. Sacrifices in product creation are abandoning a solution you worked hard on but doesn't do it for you or the customer. It is better to let go and take the loss than to keep on going with a bad solution. Pivot if you need. Our sacrifices can include: putting more hours in, moving a deadline, getting rid of a chosen technology or process, switch people and so on.

Inspect and adapt
View your solution from the eyes of the customer, is it simple enough to understand? Can we use the product without reading an extensive manual? Do we need all the features in order to reach our goal? Is the design or layout correct and intuitive? Have we made a safe or secure product? Can we break it easily?

All these and more questions need to be asked, reviewed and improved upon. Only through regular inspection of the product and the team can we improve.

Do we know better than our customers
Yes and no. We don't know exactly what our customers want, but we know the processes and technology that we need to use in order to make a great product (or we know how to learn it). As a team we know how to work together and get all the important information from the customer. We are ready to change everything we do in order to come up with the right solution. We understand that nothing is written in stone when it comes to delivering the best product to our customers.
Our customer probably know the problem best and needs us to extract it, understand it and solve it. We can do that when we have a high performance team that is capable of customer interaction, that has extended knowledge about the processes and technology involved.

So if you want to be good, if you want to be a winner, if you want to be a high performance team, be ready to inspect and adopt as much as possible. Aim high with the team and the customer. We are not looking for mediocre results, we are not looking for something that just works, we are looking for the creation of seemingly easy to use product, with the highest quality that satisfy our customers more than they expected.