How I discovered Agile is about Ownership
By helping a Management Team embrace Scrum
I often notice how Scrum Teams get caught up in endless discussions about how Scrum should be done. These are often not about solving the problem at hand, but about fitting some theoretical interpretation of Scrum. Discussions can become quite dogmatic and polarising. The passion is encouraging but the resulting confusion is not.
Thinking about this strange contradiction, I often wonder whether theory actually makes implementing Agile more difficult. Recently, I had a perfect opportunity to test this idea.
I was invited to help a management team better understand what Agile is. They were having trouble achieving their business goals and were curious about whether Agile would help them. They had a 2-day retreat planned and gave me a full day to tell them about Agile.
I decided to organise 3 activities for them, deliberately avoiding theory as much as possible and just focusing on the practice.
We started the day with a short discussion about Agile being more about a way of thinking and being open-minded than it is about frameworks and difficult words. From there we jumped right into the first activity, the Ball Point Game.
The Ball Point Game is a great activity because it allows a group of people to experience the essence of an Agile approach by playing a very simple game. The goal is very clear, and the rules too, leaving the group to focus on the game. Often I see people get very competitive and enthusiastic — they get fully immersed in the experience.
It is therefore no surprise that it is only in the debrief that people actually realise what they have just experienced. And the same happened here, with the group having a great discussion during the debrief about all kinds of subjects such as working in short iterations, teamwork, experimenting, organic leadership and losing themselves in flow. They even talked about how things like competitiveness and a clear goal can make even the most boring routine work into something fun.
After a break, we worked on visualising the workflow: the flow of value. It was clear they had thought about this before, as they had a pretty clear idea of how they wanted to work. Interestingly, this exercise triggered the conclusion that their main challenge was sticking to their desired way of working, leading to a lively discussion about the need for discipline and focus.
In the last activity, we looked at their list of long-term goals. First, I showed them how to dot-vote the list. We then selected the top 3 and split up into 3 groups to break those down, guided by one question: “what do we need to do to get this done?”. In 30 mins we created a backlog for these top three goals. I could sense the relief in the room as they discovered how easy it was to structure the work and get an overview of the whole.
In the debrief we had another great discussion, this time about clarifying objectives. Prioritising the tasks. Managing dependencies. How to determine when a task is small enough to be carried out.
By the end of the day, I could see the eagerness in their eyes. I could feel the self-confidence in the room, the enthusiasm. They just wanted to go off and get started.
Getting started with Scrum
A few months later they got back to me and asked me if I would be willing to help them take the next step. They had been exploring the possibilities themselves but were a bit confused about Scrum and other frameworks.
So I organised a short online meeting in which I showed them the Stacey matrix and Cynefin and told them a bit about Scrum and Kanban, again keeping it very simple and practical. I was fully expecting them to go for Kanban (their work was definitely not complex), but to my surprise they chose Scrum. They saw it as an ideal way to give themselves a clear structure and to help them improve their discipline.
Just like in the retreat, I took them step by step, sticking to what they needed and avoiding theory. The person who had taken the lead in preparing and managing their long-term goals was unanimously selected as their Product Owner. We chose a sprint length and chose Jira to manage the process. We started with a refinement, carrying on from their retreat. And then headed in to their first Sprint Planning. For all the events I gave them just the basics but only at the beginning of the event itself. So for example with the Sprint Planning I just asked them 3 questions:
looking at your backlog, what do you want to do? What is most important?
how are you going to do it? What needs to be done to achieve it?
All that? Are you sure you can get it all done?
And before I knew it they were sprinting!
Sure, we had discussions and experimented. Whenever I felt it would help them, I shared specific Agile ideas with them. Why focus is important. How estimation helps in planning. How it is handy to have a shared understanding of when something is Done. But I did it only when it was needed — when they ran into it or brought it up themselves — and I tried to avoid any jargon and theory. I constantly tried to imagine myself explaining it all to my 7-year-old daughter.
It wasn’t perfect, but I think what really helped us was the shared understanding it was all about discovering it together. It took no time for a couple of people to volunteer for the Scrum Master role, and within a couple of months, they didn’t need me anymore.
The effect of Theory
The whole experience confirmed for me that maybe with Agile we focus too much on the theory. And that it gets in the way of learning. It’s a bit like explaining to someone how to drive a car and then expecting them to drive off flawlessly. It’s unrealistic. You need to practice, you need to let your body, your brain muscle, figure out how it works.
I find that the same applies to Scrum too, even with its very short 13-page guide. Scrum introduces quite a lot of new words and ideas, many of which need a certain understanding of Agile to be interpreted. Proof are the many strange Scrum implementations put together with the best intentions by people with insufficient knowledge, something which I’m sure we have all come across at one time or another.
The result is that people end up with different interpretations of complex subjects, and a lot of fear. Fear born from confusion, from misunderstandings and stuff forgotten. It is simply too much information to visualise, to control. It over-complicates Agile to such an extent that we lose touch with how simple and obvious Agile actually is. Knowing the theory is not the same as understanding how to use it.
“Learning is a matter of gathering knowledge; wisdom is applying that knowledge.”
― Dr Roopleen —
In fact, I find it rather ironic that we fail to apply the Agile approach at this most basic level, that of teaching others. Agile is designed to deal with complexity by accepting we cannot understand everything in advance, and that we just have to get started and figure it out empirically along the way. And instead of facilitating this process, we send people on a 2-day training and expect them to apply Scrum.
So, getting back to the management team, for me they were the perfect experiment to test the idea that maybe knowing what Agile is, is not so important: A bunch of motivated people with a clear problem but eager to achieve their goals. And at the same time people with limited knowledge about Agile, software and processes.
From the way I experienced the whole endeavour, I feel that ownership played an important role. By focusing on the practice, addressing problems the group was struggling with one at a time, the team focused on the learning, taking ownership of the tools and techniques to solve their problem. The theory we did discuss was not much more than an explanation for the insights and understanding they developed themselves. In other words, the experience was intimately theirs, with the Agile theory just a label to discuss those shared ideas.
But the effect of ownership went even further. Subjects I always struggle to get developers to adopt were easy with these guys. Stakeholders? In minutes they figured out that their own staff were the stakeholders and decided to involve them in the Sprint Reviews. Too many meetings? Events too long? These guys would actively remind each other of their importance and the need to invest time in them.
And of course, the fact that they chose to adopt Scrum because for them it gave them two things:
focus and a structure to get the work done, a self-enforced booster of discipline,
and transparency, by giving them an effective way to structure and manage their work.
They were immune to the usual shortcuts and excuses, even when it was hard.
Even more surprising, they seemed to be living the Scrum Values. Not as a conscious effort, but as a result of ownership. The courage and openness to embrace the uncertainty of their approach and to accept feedback. Commitment to their goals but especially to each other. An atmosphere of respect, making safety implicit. As their Scrum Master for the first few weeks, I noticed how easy it made it for me to earn their trust. They trusted me to help them find solutions and they trusted me even more to keep my mouth shut most of the time.
Tell anyone to do something and they will often find ways to take shortcuts and make it easier on themselves. It’s human nature. I know I’m terrible at being told what to do, just ask my wife. Instead, help them discover it for themselves, make it their goal, and you will struggle to stop them from doing what is necessary.
Ownership leads to self-confidence and therefore to common sense. Common sense to use knowledge frameworks, techniques and other tools, appropriately. And get it into your muscle memory.