I have been in the situation many times when you are helping an organisation experiment with Scrum (or agile more generally) and it gets to a point when you can sense people are uneasy with how its going, the environment can feel a little tense. Then, seemingly all of a sudden things start to get better and the woes evaporate. It wasn’t until I spent some time looking through Craig Larman’s Systems Models from his LeSS Practitioner course that I began to learn more about what could be happening by gaining a greater understanding of some of the underlying systemic behaviours. When I took this new understanding and looked at behaviour over time it clicked for me, what increases when you make a significant change is that the teams, managers, Scrum Masters, everyone (in my experience) spends an increasing amount of time doing one of two things:
- This could be about each other, the technology stack, the architecture, a new area of business, new users and so on
- Resolving issues (aka impediments)
- These could be technological such as environments or removing branches as well as organisational issues such as ‘performance management’ processes or overly complex structures that slow down the teams and impediment resolution
The inevitable passing of time
Now as the time since we made the big change increases the number of issues and time spent learning often increase too. All the time these are increasing so is your cycle time as the teams are spending increasingly less time delivering.
They carry on in this manner until we, from my experience one of two things will happen:
- Someone somewhere says “all these changes are making us go slower and generate loads of problems”
- The balance between earning (creating direct value) and learning is tipped too heavily towards learning and the teams begin to get agitated.
What is happening is this
Scrum is showing me the effectiveness of the way we have been delivering our product relative to how we were doing it before
Then we reach the magic point where some say enough is enough, I have labelled this below
After this point we will probably with stop with this Scrum/Agile thing altogether or begin snapping back to old, more comfortable and familiar ways.
How much can the system handle?
So I see the challenge is to get as close to this point as possible as this will mean we have pushed about as much change as our organisational system can handle before we get over the tipping point and things start getting better and better.You can see below that the FIP has not been breached
Or to put it another way
Now we have some valuable learning to do and interesting problems to look into, all of which will cause the time spent learning and resolving issues to increase, sadly this is the trade off we will usually have to make but this time we are better than we were before so it will be a little less painful. So our options are:
- Increase the definition of Done?
- Do nothing (always an option)
- Increase the breadth of the Product by including a technical component we are dependent upon
- Go on holiday
I am not saying that this is fool proof method
I am almost certain there is not one. What this approach has brought me is a slightly more skilful approach (with a reasonably low cost leading measures) compared to before. It also helped me learn
- When working with multiple teams who have not owned end to end feature delivery before there will most likely a lot of learning and a fair few issues to resolve
- To make change in small batches, the batch depends upon how much disruption your organisation can stomach.
- That balancing the short term pain with the longer term gain is integral to succeeding
- And as a result of this balancing act patience is mandatory
So what is the FIP? I would love to hear what you think this three letter acronym stands for…