One of the greatest misunderstandings of “Agile frameworks” is that you can choose which processes and tools to use and which to ignore. Well, it’s a free world and there is no universal process police so in a way it is correct, but then: Is it a good idea?
In my experience, teams typically start talking about processes and tools when we have realised that our current way of working isn’t very good. This is often after some sort of crisis has happened.
A repeating pattern
The argument then goes that we want a light process as we are busy doing real work. As a consequence we spend only a minimal effort to align and agree on a new way of working. So you outline a few options, let people chip in with personal preferences, and then go-go-go. Agile means moving fast and adopting to change as we go, right?
It might work, but you will most likely end up in another crisis with an even more frustrated team. Deciding on a few more adjustments to tools and processes and off you go again. Very agile. But not very effective.
Changing personal habits is painful. Agreeing in a team on a common way of working is the territory of horror movies. Passive aggressive statements, conflicting motives, unresolved tensions from the past. And now you want to do it at a time where people are exhausted from a recent crisis?
People in IT are smart. They want to deliver great work, work that they can be proud of. And still we end up here, time and again?
You need a baseline
But isn’t it true that the retrospective, a very formal and fundamental part of e.g. Scrum, asks the team to review the process and decide on changes to implement at regular intervals?
Yes it is. So where is the disconnect? The answer to this enigma was a personal take-away back when I did Henrik Kniberg’s Scrum master course in 2018. Henrik explained it with Shu-Ha-Ri, a concept that originates from the Japanese martial art Aikido. I will explain it in plain English:
Only when you have a team with a well established way of working does it make sense to start optimising processes and tools by experimenting with making (small) changes. Otherwise you are just fooling yourself and wasting everyone’s time.
When your team is still forming and norming there are so many other things going on that any discussion about process will die in the land of mediocre consensus. You need leadership, someone to take the lead on establishing a single shared way of working. In Scrum, this is what the Scrum Master does. The first incarnation will very likely not be optimal. But it needs to be well defined, accepted by the team — and be what the team actually does. Then when the team has a baseline for talking about process, then we can start discussing changes. But until you reach that point, trust in the Scrum Guide and do what it says.