Agile, Scrum and SAFe! Oh my!
So agile working is getting embraced and the de-facto standard is Scrum, which is a pretty good starting point for any agile team. With simple rules, core values, select but clearly defined processes and artifacts, it helps any team to get started. Although there are many more ways to work in an agile way, the simplicity of the rules, the clearly defined way of how to do things and above all the fact that around the world millions have embraced it made Scrum what it is today. If you post a job vacancy for a Scrum Master, you know what to expect. There are even certifications.
And it doesn't stop there. It isn't just Scrum for developers, no, this needs to flow through the whole organization (although then it is usually limited to the part that has to do with IT). This is where SAFe comes in, the scalable framework that makes it possible to work on higher aggregation levels and on enterprise level enable target and transition architectures. Just like Scrum, SAFe has clearly defined roles and artifacts that support the processes it describes. It even has core values. There are other frameworks, but just like Scrum became the standard way of working for teams, SAFe seems well on its way to do the same at scale.
Mastering Agile
For those of us that did a Scrum Master training, we are all familiar with the Shu-Ha-Ri principle. Scrum is there for the Shu phase and to help you into the Ha phase. Though when, as a team, you have mastered agile working (Ri), your process will likely no longer look like textbook Scrum. And it is in this process of Shu-Ha-Ri that I see many organizations struggling.
One of the pitfalls of Scrum is that it is easy to start. After all, the Scrum Guide is only 14 pages and very readable. But if you are just going through the motions, you are not really getting the benefit. Agile coaching will help here. After all, it is easier to learn from a master than from a book. However, this takes time. And the true value of Scrum is not in the way of doing but in the way of thinking. As they say, Scrum is easy to start, but hard to master.
Unfortunately, this is often the point where SAFe is introduced. Paraphrased, what I hear is: 'We started with Scrum, we've been doing that for almost a year, but we need to stay in control. Our productivity hasn't skyrocketed and planning has become fuzzy.' Where Scrum promises a new way of working, SAFe promises a new way of control. It is very easy to see if we look at the core values.
Scrum has the following five:
Commitment, Focus, Openness, Respect, and Courage
These are clearly driving a team towards results, but also towards becoming closer and more effective. The focus here is on both the individual as well as the group.
These are four that SAFe has:
Alignment, Built-in quality, Transparency, and Program execution
Notice the difference? Where Scrum is talking about individuals and teams, about team building and having success as a result, these are all about productivity and control.
Failing change
Perhaps at this point, I should make clear that I am not against scaling out the agile process.
However, the problem I see popping up time and time again (in many organizations) is that teams have not even gotten past the Shu phase of Scrum before SAFe gets introduced. Instead of giving a team time to find their way past the rules as written in Scrum, new changes are introduced. So once more, the team is doing things by the textbook. This time SAFe. And when talking to individuals in the team, I find that instead of embracing the way of working, they are now just going through the motions. Instead of getting the chance to experience the benefits of adaptability, it turns into 'another fad that comes from upper management'.
This is where change is failing. If your teams think this is just about the rituals and artifacts, about jumping through the right hoops and performing the right tricks, you missed your goal completely. I can tell you from experience that agile working is about why we do things much more than how. It is about enabling people to excel in what they do, not finding a different way to monitor them.
At this point it might be good to take a look back at one of the things that started this all off, the Agile Manifesto:
"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more."
Final note
My personal conclusion is that, where Scrum will tell you how to do things, it is important to look back at the Agile Manifest to see why we do these things. Be sure to also take a look at the 12 principles behind the manifesto, they might seem very self obvious when you read them, but then ask yourself if these principles are actually being kept by you, your team and your organization. It is only by understanding why we do the things we do, what drives and motivates us, that we can improve. It also makes for great retrospectives. ;)
And don't start scaling up the way of working before it has had a chance to succeed. Because I have had the privilege to work for brilliantly agile organizations, where everyone at every level worked in an agile team. But sadly I have seen many more where disillusioned people were going through the motions, keeping their heads down.
So take your time to change your organization, because contrary to technology, people do not change overnight.
Comments
Post a Comment