A common beginner's mistake in agile is when we believe that the agile methods will fix our underlying dysfunctions.
Many other methods and processes work that way: they accept that we lack psychological safety, that we as an organization can't decide what's important, that we don't really collaborate even when we should.
So processes and methods are often used that make it possible to create at least something amid our dysfunction. Doing stuff without having to communicate about value, or having to collaborate deeply, or having to collaborate or communicate at all.
Our collaboration is totally dysfunctional, but the method tries to compensate for that. And succeeds a little bit too.
The agile methods do the opposite: They point out exactly where and why we can't work together. Where we don't see what's going on. What decisions we are not equipped to make.
And they make that painfully clear so that we become incentivized to start to improve. Fix our underlying dysfunction.
There is a lot of fuzz in agile regarding team's self-management. The discussion is often about if and how to transfer authority to the team. What decision-making powers they should have.
But people seldom talk about how to grow the decision-making ability in the team. It seems like we take that ability for granted. That power is only a matter of delegating mandates.
But without the ability to make good decisions, no one has actual power over anything. So what is the ability to make good decisions? The agile methods have a way here:
Agility means fast and smooth adaptability to the current circumstances. And this means that we must quickly see and understand the circumstances, as they change.
Agility calls for empiricism: that our decisions at any time is always grounded in reality. So we need to be experts in inspecting the actual situation.
Almost all practices in Scrum can and should be used to improve transparency and everybody's ability to see and understand.
We plan in "sprints", periods of just a couple of weeks or less, to see if we can slice down the improvement of our services into very small steps. If we have unfinisihed changes left after the sprint is completed, we understand that we lack the ability to narrow the scope.
We meet every day to see if our plan needs to change when we try to fulfill our goal. The fact that we have goals for the sprint and the product also brings visualization to our idea about value. We have a visual plan for the sprint and update it as we understand more. And we know when it is time to talk to different stakeholders about our findings.
We have a common idea of what "a change ready for being planned into a sprint" means. This brings visibility to our idea of what a small, clear, and valuable change is. And will visualize what we need to investigate further.
Similarly we have a common idea of what "a completed change ready for being released into the service" means. That brings visibility to our idea of what quality and "production-ready" is.
And by inviting people from the outside to look at what we have done during the sprint, we create visibility about what we do, and they can be transparent about how they feel about it. Which makes us co-creators of the service.
And when all these practices have shown us where we lack and can improve, we have an improvement meeting known as the "retrospective" where we bring all these things up. And we analyze the underlying root-causes and come up with improvements to our ways of working.
Which are also visible and transparent.
Transparency, inspection, and adaption are Scrum's pillars for empiricism. Agility means being great at inspecting the current situation, adapting accordingly, inspecting again, adapting, and so on.
The act of inspection requires transparency and openness. It takes some courage to be open, which is why courage is one of Scrum's core values along with openness.
And it helps if everybody respects each other, so that we can build psychological safety among us. Respect is also a Scrum value.
But this requires that we grow the ability to be transparent. That we become good at making important things visible together. This is a skill that very much determines how good an organization will be in becoming more agile.
Because without transparency, you can't make effective adaptive decisions. Agility requires it.
The new Scrum Guide, released in November 2020, adds some more words compared to the last version of 2017, when it comes to stress the importance of transparency. And it adds the concept of working towards an explicit product goal. But aside from that, the guide doesn't really say anything new. Transparency is just as important as always.
But what the authors point out, more in this version than in the previous, is that the Scrum team really really is self-managed. The Scrum Team make the product decisions. And here is where I suspect there can be some discussions in the organizations.
People will ask themselves how much authority they want to delegate. What kind of decisions should the Scrum team make? What kind of authority am I willing to give up?
But what I have learned through the years, is that discussions on delegation are almost always hidden discussions about what transparency we need.
Why can't you trust me making the decisions here? Because you can't see what I see, and can't see the consequences?
Why does this decision feel risky? Because we don't see what we base it on?
Pause any discussions on who should make what decisions. Talk more about what we need to know to decide. And how to visualize the things we don't see yet.
If you want to get some help around delegation and transparency, just let me know!
Be it through workshops, trainings, self-study material, me being present coaching you, or something else.Did you give trainings as well?