Principles Part 1 - Teams, Visions and Values
Last post I put forward 7 principles that I think every agile methodology should have. In this post, I'll be explaining (hopefully) what each of those principles means and why I think it is important. To recap, the six principles for a successful methodology are -
They are built around small, self-organising teams
The team has a clear vision of what they are doing and where they fit into the bigger picture
The team delivers a regular flow of value via a well defined backlog of work
There is a content authority responsible for making sure decisions are made quickly
There is a clear bidirectional service agreement between the team and the rest of the organisation
There is a fast feedback loop that allows the team and organisation to optimise both the process and the product.
The methodology is self-similar at scale.
So, let's start looking at these in more detail.
The first principle is that any methodology should be based around teams. Not just any team, but a small, empowered, self-organising, cross functional team. Why? Because they get things done. The whole point of any agile methodology (actually, any methodology, agile or not) is to get something done. There is no point having a methodology that doesn't have something useful as an end product. If you want something useful done, give it to a team. A good team is like a powerful sports car (or a fully stocked kitchen if we want to continue with our cooking analogy). It is capable of amazing things...if you use it correctly. As I have written before, it's all down to the team being the smallest entity that can make all the decisions that are needed in order to get things done. The more empowered your teams, and the more decisions they can make themselves, the more effective they will be.
The team can't just make decisions in isolation though (well they can, but they probably won't be the right decisions), they need context. They need to know where they fit into the larger organisation and how the things they are doing will benefit the organisation. So the second principle is that the team has a clear vision of what they are doing and how that fits into the larger organisation. I have written about what makes for a good vision before. The team's vision should provide enough context for them to make the right decisions. It may be a simple statement of what the team is doing and its value to the organisation, or it might be something more complex with success sliders, metrics around the desired outcomes and other artifacts to help the team make the right trade-offs.
If we are going to look at the team as a sports car, then the vision is like the map that tells the team where it is going. Using the map, they can make trade-offs - take the scenic route and arrive later, or go direct and save some time but at the expense of that view? The vision should also be continually revised to make sure it is still relevant. No point setting out with a map that is years out of date.
The other thing a team needs to be effective is something important to do. It doesn't matter how good your team is, if they aren't working on anything, or are working on things that have low value, then they will not be effective. A good team with nothing important to do is like having our sports car sitting in the garage with an empty tank and nowhere to go. It could be barreling down the highway towards your destination (as plotted via your vision) but instead it's just sitting idle. So the third principle is that the team must deliver a regular flow of value via a well defined backlog of work.
Both parts of this are important. The team needs to deliver a regular flow of value. Frequent delivery is one of the key benefits of agile. If the team produces a lot of valuable stuff but never releases it, then the organisation can never benefit from it. On the other hand, if the team releases lots of stuff frequently but it's low value stuff, the organisation won't deprive much benefit either, so the two parts of this principle go hand in hand - they must deliver high value stuff frequently.
The best way to ensure that the team is delivering the right stuff is to organise its work into a well maintained backlog. If the team is the car and the vision is the map, then the backlog is the route towards the destination that the team determines using the map. The team will use the information from its vision to determine the relative importance of the things they need to do and order their backlog so that the important things get done first.
The key thing about a backlog compared to a requirements list or to do list is that the backlog is ordered and that ordering must be by value. This ordering can be by gut feel or via a full economic analysis of perfect vs cost of delay. Whatever the method, some effort must be made to ensure that the team is delivering maximum value. This could be direct customer value (new features) or indirect value (pay-off of tech debt, learning, enable other work etc).
So, we have a team, a vision to tell the team what it needs to build and why, and a backlog that is prioritised by value so that the team delivers the maximum possible value. All set? Not quite. There are some other things the team (and organisation) needs before they can be really successful. The team needs a decision maker for those times when their vision isn't enough to make the tradeoffs, they need support from the organisation's leadership, and there need to be feedback mechanisms in place so the team can correct course if they go off in the wrong direction or if conditions change. These are the next 3 principles and we will look at them next time.