How to set up a successful review

The review is a scrum event that takes place at the end of a sprint. Its purpose is to inspect what has been done and what is going to be done with the team and the stakeholders. During this event there might be a demo to show what kind of stuff has been created. In the review a new plan is made to tackle the upcoming work, to check if we are still on the path to the intended long time result. Participants in a review should consist of stakeholders and leaders. They can relay their needs and strategic goals for the product that is being build.

Sprint goal

In the review the sprint goal of the next sprint is discussed. This goal can be seen as a mission statement; what are we going to do the next sprint. A sprint goal is typically a sentence describing the desired outcome. For example: after this sprint component X will be live. Or application Y will comply to all security demands. A sprint goal creates focus for the team, with a defined goal they understand what needs to be done. A sprint goal should be derived from strategic planning by leaders, so the purpose of the sprint becomes clear. All sprint goals should be achievable in the allotted time frame of a sprint.

Planning

During review the team and stakeholders should gather those stories that are needed to complete the sprint goal for the next sprint. They need to formulate which tasks needs to be done to achieve the goal. Leaders should express their strategic goals so the team can understand what operational goals are needed to achieve those. Stakeholders should do the same, they have needs that the product fulfils, and therefor they need to be clear on what they need. This planning part is not putting stuff on an agenda, it's about setting out lines how to approach the next sprint and to find out what is important.

Demo

During a review there is room for a demo, a moment to check if what the team has build lives up to what was expected. It is like a debrief of a mission. The team should present their accomplishments and check with stakeholders if they are satisfied. During the demo, stakeholders can be invited to work with the product so they will get more involved and are able to give direct feedback.

Dependencies

During the review all the stakeholders are present. This is an excellent setting to find out dependencies and talk about them. There are technical dependencies; like machinery that is needed to make the product. There are process dependencies; like other departments delivering a piece of the puzzle (like a service that is needed for this product). And there are people dependencies; people are needed, or knowledge is needed to make a successful increment on the product. All these dependencies should be mapped, to mitigate risk and to make the team able to make a proper planning during the planning event.

At the end of the review event there should be a sound sprint goal with a description of what to do. It should be clear who and what the team needs to be successful. And last but not least, the team ought to have obtained feedback so they can improve in the next iteration. All in all it is imperative that stakeholders and leaders are present during a demo to improve performance of the team. They need to share vision and their strategic goals. And they need to let themselves be heard so the team can collect feedback and improve.

Team skills for cloud solutions

If you want to go to the cloud, you need to learn how to fly. In order to prevent castles in the air, teams need to have a fair understanding of the risks and capabilities that are needed to successfully move to the cloud. Whether internal or public, any team needs to obtain knowledge to prevent screw-ups. A cloud environment is a hostile environment, without proper knowledge or experience any team moving to the cloud is bound to fail if they don't educate themselves.

The main risks of cloud are complexity and costs. Both can be managed if a team understands them well. Let's start with costs. In the cloud, we are talking container platforms here, billing is done by compute. Compute means usage of system resources. Containers with apps that are switched off don't cost a thing, containers with apps that are running are billed by the second. Traditionally apps ran on (virtual) machines, which were always on. So a monthly bill about the costs of the VM was about it, there was a fair understanding of how much the app would cost upfront. With cloud this is a bit harder to predict. If your app isn't very much used and is always available, the bill might be high. If it is not used and switched off (ready to start when a request to the app is made) the bill might be much lower. And if your app is populair and scales up, thus using more compute, it will costs you a lot more than perhaps anticipated. 

To take advantage of the cloud model, up- and out scaling is important to understand. Breaking your application down into micro or macro services is paramount for a successful scaling model. This model can be used to take advantages of the cloud in shutting down low used services, limiting costs, or scaling up much used services to improve revenue.

A team building and maintaining the app in the cloud needs have some capabilities to support this cloud model. They need to be autonomous, command themselves, be able to take action without approval (or with implicit approval). To facilitate this an agile way of working is required. It doesn't have to be a particulair practice, method or framework. The agile concepts need to be understood and implemented. 

What they need to do next is to automate the development pipeline. Everything from check-in of a change to deployment should be automated. There cannot be any manual steps in this process. This requires rethinking of testing, approval and deployment. Another part of automation is monitoring. The app needs to be monitored, the business process needs to be monitored and the team should monitor its own performance. All these metrics should be easily available in a transparent manner. This enforces interaction and trust with the stakeholders. 

This was all about mitigation, but what if the shit hits the fan and there is a disruption in the service provided by the app? Think of break ins or outages. The first thing is security. This is a discipline that should be practiced by all members of the team. It's just like locking your house or car, or providing a good lock on your bike. A team should understand security risks by applying some form of thread modeling (STRIDE) and they should practice outages on a regular bases. The last one can even be automated by the use of a Simian Army. 

Also think about when there is actually a compromised situation or an outage. No one else is going to be called upon then the team. So they need to organise themselves to be available at all times. 

Moving to a cloud solution might sound easy, but it's much more complicated. Teams need to learn a lot of new practices to be able to safely navigate the complex cloud world. They need to feel responsible, they need to inspect their performance constantly and they need to learn new things each day.

How to start a DevOps team

DevOps is about the removal of silos. Breaking down barriers between different parts of the organisation. It is about getting everybody on the same team and be more effective. Teams focus on one product and making sure it works for the customer. It is like moving along a makeline with the complete team to build a car. Everybody has their own specialty at different stations in the process and instructs the team how to operate that station. The whole team works together to pass the quality standards of that station. This ensures the team owns that build, and be proud of it. It ensures sharing of knowledge of that particular station to all team members. 

For (team)leaders it becomes most important to lay out the goals, to work on a strategic level instead of an operational one. They need to work on resolving dependencies. If for instance a supply line to a certain station stagnates (they are running out of bolts for instance) they need to go over to the supply line and find out how to help that line speed up production.

The operational level is covered by the people working on the product, they are skilled and trained to work on those stations. No leader is needed to tell them what to do. The team therefor needs a fair understanding of what they can and cannot do. For the latter one, they also need to know what they need to fix the impediment of not being able to perform a certain task to the level they need to. They need to understand their short comings so a leader can help them overcome that. This often means injection of knowledge. This knowledge can only be obtained from an external source, either a specialist that runs with the team for a while or a training course. For the specialist the most important task is not to fix the knowledge gap, but to inject their knowledge into the team, so they can leave safely after a while.

A typical DevOps team incorporates different disciplines. In software engineering this means that there are at least developers, testers and operators in the team. While they have a certain job, working in a DevOps team also means taking interest in the other disciplines as well. Pairing up to fix stuff is one of the major aspects of an effective DevOps team. Therefore I prefer to call all team members in a DevOps team engineers. It doesn't matter which profession somebody has, if they are not able to switch roles and help the team perform better, there should be no place for them in a DevOps team. DevOps teams are about performance and delivering stuff to customers they need. 

When you want to start with a high performance team, make sure all the disciplines needed to build a product from concept to grave are in the team. Not all disciplines are roles, some people can perform more than one role. But do try to avoid a local hero, one person that can do everything, this can prevent knowledge sharing. As a leader find out how you can best help the team, remove impediments and resolve dependencies. Start with forming a small team (3-5 members) and formulate the goal of the product. Use an agile work method to create small iterations with a lot of room for inspection and improvement. Keep stakeholders close and get them involved. Take small steps and keep things as simple as possible.

A DevOps team is a high performance team that will take responsibility and pride in their work as long as they can be autonomous and are supported by the leaders. Leaders that help them overcome impediments and resolve dependencies. With clear goals, a small team and a supporting leader, DevOps teams will outperform any other team all the time.

All about removing silos

Organisations are optimised in silos. This makes work efficient. Costs can be reduced by economise work done in a particular field. This has been the way of working since Taylor died. It does optimise work in factories for people working in a particular order on an assembly line. In a modern world where we build software, saving money on one silo can result in extra costs in the other. The taylorism way of working is therefor no longer rewarding. Taylor had some ideas of improving efficiency in production systems which we massively copied and still use. His idea was to improve the productivity by improving the efficiency of each process step; how would the world have looked if he had chosen effectively instead of efficiency?

What do we mean with silos? Silos are people of the same expertise put together. Put together in teams to build a small piece of the end product. Silos result in many handover moments. To reduce those moments factories implement assembly lines. Software development is a creative processes and it cannot be put into an assembly line model (no matter how hard we squeeze). How can we get rid of those silos and improve our effectiveness?

1. Product focus

Instead of focusing on process optimalisation we should focus on delivering a product that a customer is willing to buy. Our responsibility is to deliver that product with enough quality to satisfy the customer. A team should be focusing on the customer and only deliver what the customer needs.

2. Merge expertise

We merge expertise in a team, so one team is responsible for all the work done on a product. Including development, testing and maintenance. No single silo of experts remains, this is important. Of course there are experts, we just need to know where to find them. This will result in no handover and no waiting moments between teams, but it implies a lot! 

We need to know what work team members do, we need to learn, we don't have to ace it but we need an understanding how stuff works. In a DevOps team we need at least 10% time reserved to learn, just to keep up, learn and share.

3. Transparency

In order to find the right people for the job, we need to know from each other what we do. So instead of working silos, we have silos of knowledge sharing. We organise teams around products and customers, we gather to share knowledge.

4. Responsibility

With creating a team of mixed expertise around a product and its customers we are getting more responsibility. The teams makes promises, it needs to deliver, they are expected to keep up quality. Getting more responsibility means even more learning, the teams will be small companies inside the umbrella of a big one. The big one shares vision, mission and strategy. The team will follow the strategy, but gets its work from the customers. This also means that managers get less responsibility about the product, but more about developing team expertise.

5. Autonomy

All this results in autonomous teams that are capable of delivering quality and value to the customer through a product. 

By removing silos an organisation will change significantly. Work will shift and change. Teams will be in the lead to deliver customer value. DevOps has even a bigger impact on management comparing to teams. Teams know about software development, testing and operations. Management needs to learn to let go, to inspire, to share and to help removing impediments.

Do you still work in silos? What is the most difficult thing you are experiencing adopting DevOps?

Five capabilities of a successful DevOps team

So you have gathered developers and operations and put them in a team, voila DevOps! Or not? What kind of things does a DevOps team need to know to be successful? Are they developing safe software? Let's see.

Metrics

A DevOps team needs to measure everything, they are responsible for everything, so they need to know about performance. Performance of the application they are responsible for. Performance of the team to be able to improve. And performance of their delivery of value to the customer. Here are some basic metrics I think are important to measure.

• Lead time of a change: how long did the change live before it was put into production?
• Mean time to recover: how long do most outages take to be resolved and availability is restored
• How predictable is the team: prognosed work / delivered work (the closer the numbers, the better).

Security

A DevOps team owns the security aspects of the application, no one else is responsible. Things like static code analysis, OWASP Top 10, basic thread modeling and service accounts should be understood.

Testing

Testing is not the job of one person in a DevOps team. All disciplines must have a fair understanding and even an implementation of testing. Think about the testing pyramid and accompanying strategy. Think about unit testing on at least all new functionality. And least but not last; knowledge of disaster recovery or use of chaos engineering.

Transparency

Being transparent as a team means to show what you do and what you didn't do. It is about communication with all the stakeholders, including the DevOps team itself and management. A visible backlog and open review sessions are key to transparency.

Learning

In order for a DevOps team to be successful and stay successful they need to learn. While the world keeps moving, a team cannot stand still. Any lack of learning will result in a form of debt. New technologies appear, team members can change, the organisation will change and dependencies change, just to name a few. DevOps teams actively need to learn and develop their skills as they do their applications.

This is just the tip of the iceberg about what a DevOps team needs to be able to do, there are many more. But on a basic level you need to understand and own the above. With an increases autonomy that comes with being a DevOps team also comes more responsibility of doing the right things right.

What are the most important capabilities for your team?

Kano vs WSJF

How do we decide what to put on the top of the backlog? How can we prioritise one story over another? I have seen many different ways, here are a couple:

1. low hanging fruit: pick the easiest items that can be solved fast. These are not always the most important ones and can lead to technical debt or dissatisfaction of the customer.
2. The loudest yeller: in a group, there is one stakeholder that yells the loudest about their item, silencing the other stakeholders. This leads to a dishonest balloting of items and doesn't put the most important items first. 
3. The managers priorities: in traditional or hybrid organisations that are adopting scrum, managers are about people and projects. This can lead to managers making priorities instead of the stakeholders or customers and thus not delivering the most important items first.

So how can we do a better job? I want to mention two: the kano-model and WSFJ.

Kano

The Kano model is an approach that prioritises stories based on customer satisfaction plotted against functionality.

• In the left top customers is the functionality that brings excitement to our customers. If you invest in those, your customers will be delighted. Mind that not implementing these doesn't lead to customer dissatisfaction. A minimal viable product will not include these functionalities.
• On the right bottom are the basics for the service to work. These are basic functions which are taken for granted. Customers won't be satisfied by these functions, but will become very dissatisfied if they are not implemented.
• And on the top right are the performance functions. The more you invest in these functionalities the more the customers like it. The better the performance the happier the customer.

You can read more about the Kano model on the website of ProductPlan: https://www.productplan.com/glossary/kano-model/

WSJF

WSJF is an abbreviation for Weighted Shortest Job First. I came upon it during a SAFe course. It is based on the idea that we can weigh stories on importance and work and get the most economic benefits. For WSJF we need a bit of simple math. First we need to find out what our CoD (Cost of Delay) is. So how much money will we loose when we don't implement this functionality? We plot that against the job size with the formula: WSJF = CoD / Job size.

It is easiest to make a table with all the functionalities or stories or stuff you want to make, add a column for size, CoD and weight (which is CoD / Job size). After plotting this in the table, the item with the most weight is the most important to implement.

You can read more about WSJF on the SAFe website: https://www.scaledagileframework.com/wsjf/

How do you do your estimations? Which model do you prefer and why?

Five signs you know you are working in an agile team

Working agile is more than just a daily standup, but you knew that already. What are more distinct features of working in an agile team? Here are a few of them.

One: everybody is a developer

Everybody in the team has the same goal: getting stuff done. The distinction between your job and that of you peer is fading as you progress to developing stuff that works for your client. Everybody in the team shares the same responsibility. You do refinement together, work together in a peer setting most of the time. You share knowledge and you even take over from other disciplines in the team.

Two: you are the A-team

The team is more important than its individual members. You avoid local heroism with people that know it all. The best hero is the one that shares the way stuff is done. A hero is the one who shares most and educates the team on development principles. A hero helps all team members in getting a better performance so that all members become hero's. 

Three: reflection together

Reflection is done with the team. Together you reflect on what has been done in the review, feeling proud of what you, as a team, have achieved. You inspect what you failed to deliver and know what you need to change to do an even better job next time around. With the team you inspect how you are working and come up with things that increase your performance as a team and as an individual. You do peer reviews to inspect each other in an honest way so you learn and are able to improve. This implies no functional reviews by managers as well.

Four: dashboarding

As a team you use dashboards to make performance visible. Just like you use a dashboard in the car to read out speed, fuel and overall car performance. You have stopped sharing status in the form of reports or meetings. Reporting the old fashioned way has no added value to the customer. If anyone in the company wants to know how your team is performing they come to reviews and ask.

Five: working on products

The most important indicator of working in an agile fashion is perhaps that it is focused on products instead of projects. Your team works on a product with a distinct customer base. You and your team are solely responsible for the product and its success. A project is timebound while a product is customer bound.

What are the most important indicators for you? Please write them down in the comments.