I understand that managers who have invested effort and money in training teams in Agile methods may want to see how much those teams are improving. There are a handful of reasonable measures to look at to see whether the organization is improving over all (which I’ve written about here and here).
You can apply some of those measures to team improvement. Are defects trending down? Is the ratio of value work to fixing work improving? Are teams improving their practices?
But, teams don’t exist in a vacuum.
Part of team improvement comes from the way a team works together, their approaches, and skills. Another part comes from how well the environment supports their efforts:
P=f(p,e) where P= performance, p=people, e=environment.
Teams can only improve so much, unless the environment also improves.
So, rather than look only at team results, also evaluate whether the environment that supports the team’s work is improving. When teams aren’t improving as hoped, this is where I start looking.
Team composition and stability. Are the teams appropriately cross-functional? What is the frequency of membership changes? If the team isn’t well designed, or isn’t a really a team, don’t expect team-level improvement.
How work flows into teams. Are teams pulling work, or is management pushing? Are stories/features well-formed and customer facing? How much new work gets added during a sprint?
Trends in dependencies between teams. Are POs working to reduce dependencies in the way they shape stories and order the backlog? Are the teams organized to reduce hand-offs and dependencies?
Clarity of the product visions and team mission. Is it clear what problem they are solving/benefit they are creating for which people? Are team missions articulated and independent?
Adaptive planning. Are POs and Management adjusting their expectations based on team capacity?
I expect team performance to improve with agile methods. But if you really want high-performance you need to improve the entire system–and that is management work.
Someone I don’t know offered to teach me Agile Best Practices recently.
I tend to think there are “generally good practices,” some of which are broadly applicable. In my experience, the search for Best Practices is often a search for Silver Bullets, and a reflect a desire for easy solutions to complex problems. It would be nice to short circuit the difficult work of seeing and evolving a system, building capacity–but I seldom see it succeed.
And, one of my practices is to challenge assumptions. So I challenged my assumptions that there are no best practices. And I came up with some, which I suspect are not what the dear fellow who offered to school me had in mind.#1 Think deeply about the problem you are trying to solve.
First, understand which problem you are trying to solve, for which people, to create which benefit. If you don’t understand this, you are relying on luck for your chosen “solution” to work.#2 Question your assumptions about the causes of the problem.
Assumptions about how work works and how people work will determine the solution space you explore. For example, if someone assumes people aren’t finishing stories by the end of sprint is because they are not sufficiently accountable, he or she will probably not consider the way work flows into the teams, or dependencies between teams.
Notice that I wrote the causes, not the cause. In a complex system, there are likely multiple, entangled influences that result in the problem you observe. Everything touches everything, change one thing and you’ll change many. You can’t anticipate all, but you can predict some, which may change your choice of action.#3 Understand your current system and how it contributes toward the problem, and in what ways it might contribute to solving the problem.
Systems drive behavior. The patterns you observe emerge from the system you have. Sketch what you know about the system, using CDE, DOE, influence maps, reward maps, value stream maps… what ever set of diagrams will help you reason about the system. Use these diagrams to consider which which factors you can change, and what effects they might have.#4 Research at least three candidate actions to improve the situation. Don’t rely on claims by people who are selling “solutions.”
If you can’t think of at least three different possible approaches, you haven’t thought enough. Identifying more candidate approaches almost always improves your understanding of the situation.
Look at how you could influence different factors that contribute to the pattern. Don’t limit your self to comparisons of three similar approaches (should we use Tool A, Tool B, or Tool C?).
Learn from what has worked for other people, but don’t follow slavishly. You need to understand enough that you know where you can modify, and where you need to follow strictly. This sort of learning comes from studying theory, and practicing theory.
There are no silver bullets.#5 Develop experiments to move towards a more effective way of working and improved outcomes.
Big changes feel like existential threats. Small changes support learning.#6 Run experiments, and examine the results. Adjust based on what you observe.
When I took chemistry classes in high school and at university, our “experiments” had an expected correct outcome. Real experiments are about learning. You may learn that you need to increase some skill or create a different level of understanding in order to apply a particular technical practice effectively. You may learn that your architecture is preventing your from benefiting from autonomous teams. What ever you learn, it will help you refine your approach.
Look confirming data, and disconfirming data. Consider what you’ll do to amplify results if things are headed in a good direction, and how you’ll dampen the effect if it reduces function.#7 Work incrementally and iteratively to solve the problem(s).
It’s really not very agile to choose one big bang solution and then roll it out. Try something, learn from it, see how the system changes. You’ll learn more about the issue, have a chance to observe side-effects. Be open to the different possibilities and opportunities that emerge.
These best practices are likely to lead you to an approach that fits your context, your organization, your people. Which will be the best practice for you, not something that worked for some other group in some other context, to solve some other problem. And, since you and your people refined the approach it will be theirs, and they will support it.