Processes and Tools over Individuals and Interactions?

Lately, I’ve seen a lot of people and teams that experience ‘agile’ and ‘scrum’ as instrumental and full of rules and restrictions. Leading to results that are not getting the teams in the direction that are intended and giving an experience that is kind of reaching the opposite of what agile frameworks set out to do. I firmly believe that Scrum Masters – and any kind of coaches for that matter – need to focus and turn the attention of their efforts back on the empiricism: making sense of ‘agile’ by experimenting, learning and giving and receiving feedback constantly. I’ve been struggling with this as well, because your first intentions are to help teams on how they do their work, but usually this gives the opposite effect. They will not experiment and learn by themselves.

The first sentence of the Manifesto for Agile Software Development is ‘We are uncovering better ways of developing software by DOING IT and helping others DO IT.’ In my opinion this reflects the empiricism that is needed and the focus on learning and adapting constantly, which might differ – and will differ – a lot in different situations, teams, companies, products etc. (Side note: what surprises me is that in most posters and visuals of the Manifesto for Agile Software Development this first sentence isn’t even shown) The three pillars of Scrum – Transparency, Inspection & Adaption – also reflect the empiricism and are therefore not focused on the rules, events, processes and tools, but on how you – as a team – are going to use them and learn what works for you.

In practice, people and teams often use the rules, events, artifacts, processes when they start – because it feels like a safe bet. If you go by the book, you cannot really go wrong, right? While forgetting that empiricism, experimenting and learning are just as crucial parts of the way of working – taking insights from what happens in reality and what works in their situation. You should focus on helping them by telling that it is alright – and even encouraged – to experiment and learn, when necessary giving them permission to make mistakes. Every company is different, nothing in ‘agile’ says ‘set in stone’ and therefore each practice needs to be constantly evolving reflecting the individual situation, its challenges and context. There is a reason that companies like Toyota and Spotify (which are both quite successful) always try to improve and never set their way of working in stone.

Two examples I’ve seen (more than once). Daily Scrums that take a lot of time, talking a lot about the content of the items, but not really discussing on the goal they have and whether the progress towards the goal is sufficient and whether they need to adjust. These teams blame the Daily Scrum, but do not understand the root cause (e.g. that they divide their work and do not really collaborate) and do not learn from this and experiment with other ways of doing the Daily Scrum and e.g. doing more items together instead of separately. Another example is taking on too much items in their Sprints and blaming the timebox, while the refinement of the items isn’t done properly. While if they experiment e.g. with a different way of refining, taking on less work, collaborate more, they might improve. Of course, these examples are quite trivial, but therefore easy to understand.

As a Scrum Master – or other kind of coach – there are different ways to help these teams. First, you should repeat the purpose that is behind the way of working and repeat the empiricism. You might even give examples of experiments that others did, they might be working in their situation as well. Preferably more than one example, because it encourages thinking about it themselves and could otherwise lead to copy-paste behaviour. Second, you can ‘lay back’ and encourage them to think about their way of working. What I often do is asking (a lot of) questions about what they would like to DO, how they want to DO it and what experiments they would like to try. And in this, stimulate them to try and reflect on that often, so it becomes more and more a part of THEIR way of working. Make sure you reflect on that often, so it becomes a natural heartbeat of them. Eventually, they will do it themselves, but in the beginning of this mindset you can help them by this. When they learn to experiment, reflect themselves and implement changes through learnings, you know you are in the right direction. And keep repeating: ‘you can always go back if it doesn’t work’, that’s where e.g. retrospectives and inspect & adapt are for.

Of course, you should always try to prevent this ‘fixed mindset’, maybe an item for another blog.