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 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 (Diagram of Effects, example of them here), influence maps, reward maps, value stream maps… whatever set of diagrams will help you reason about the system. Use these diagrams to consider 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 you from benefiting from autonomous teams.  What ever you learn, it will help you refine your approach.

Look for 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.