lördag 19 november 2016

When "doing agile": focus on effect!

So, we have an organization that works somewhat agile in places, maybe having a pretty decent level of agility in certain teams. We have a wish for more agility for the whole. Someone or something has led us to look at frameworks of methods that seem to be designed for creating agility in collaborations involving many persons, such as SAFe. Should we blindly progress and implement the collaboration techniques from the framework?

I suggest that we don't. While the techniques from SAFe or any other of the more known frameworks are all tested and tried ways of working that can do wonders, they are often presented as prescriptions with a general applicability, making silent assumptions about preconditions that might not hold true in our particular situation.

Each collaboration technique has a purpose. You want to see an organizational effect when doing things like a two days collaborative planning of 8-12 weeks of work for a group of teams (called "PI planning" in SAFe), or enforcing forecasting based on relative-size estimation with "ideal days" as the common unit, or any other technique. The thing is that it is the effect that in the end will give you more or less agility, not the behavior.

Think about it: is it possible for a group of people to behave in a certain way without achieving the effect? Absolutely. There may be situational factors that makes the behavior lead to other effects than what is anticipated.

Is it possible to attain the effect in more ways than through a certain behavior? Absolutely. And for certain situations, the current behavior may be a better way to achieve the effect than any other proposed alternative.

So it is possible to destroy something that works by enforcing a new behavior? Yes, and if the effect is already present it is unnecessary. We want organizational agility, not compliance.

So what I very much would like to see from any writer of material that tries to collect agile collaboration methods (myself included) is a lot more focus on what organizational effects you would like to see, what the preconditions are for the techniques to work as intended, how to assess the current situation, and how to apply the techniques in a safe way that don't break what is already working.

Basically, this is what we agile coaches do. And when talking to the people behind the frameworks you often notice that they have a very sensible approach to their own frameworks, both in terms of limitations and preconditions.

But that attitude isn't helpful when the specific wording of the framework is commanding and unconditional. The creator of the framework has the knowledge and expertise. People in organizations that need improvement in their collaborations are on the other hand insecure. There will be a bias towards doing exactly as it is written, and pointing out that there might be reasons to be careful with a certain technique in a certain situation will be met with suspicion. "The framework clearly states that it is necessary that we..."

The book Extreme Programming Explained is the star here. Kent Beck reasons about how and when the different techniques work, and gives a lot of examples on how to apply them in order to achieve the desired effect.

I believe that we would gain more from all frameworks and techniques if they presented themselves using that approach.

Inga kommentarer:

Skicka en kommentar