End the Scrum Revolution, Begin the Scrum Evolution
End the Scrum Revolution, Begin the Scrum Evolution
An organization is a network of complex dependencies. Because of this complexity, any change in any direction will face some resistance. The major difference between a waterfall project and a Scrum project is that the latter encourages and even welcomes change. How do you introduce Scrum to a non-agile organization without facing major resistance?
Unfortunately, in their efforts to apply Scrum, companies often take the head-first approach, seeking a revolution. They look at the ideal world of how a fully agile company is run, take parts of it and stick them on their own organization. This is like putting wings on a dog and shouting at it:
And, lo and behold, the dog will just sit there and look bewildered. Consequently, Scrum gets the blame and the chapter of agility is either closed or “adapted,” with the company running Scrum in name only.
How can you teach your organization to “fly”?
Managing Your Employees vs. Providing a Vision
Change can be taught by one of two methods:
- You demand that the student follow your exact instructions. It will hurt, and it will cause muscle ache, frustration and exhaustion. Yet, sooner or later, the student will learn the right technique and will favor it over other techniques, feeling the difference. This method is often used in sports, especially because the wrong moves can cause serious injuries.
- You start with what the student already does and offer a path of small improvements. This method is preferred if the student simply cannot perform the optimal technique at that time. Singing is a prime example: if you demand perfection, the student will never finish his or her first song; the learning curve is simply too steep.
Having played chess for many years, I prefer the second method and tend to approach problems as I would approach a game. When looking at a company’s agile transformation, I see the current situation as the starting position and the agile ideal as an approach to “win.”
Many preparatory moves are required to get to the finishing move, which in this case would be the implementation of the solutions that Scrum offers. It is like walking through a labyrinth where you are sometimes moving away from your actual goal, having to take one step back to move two steps forward.
Encouraging your organization to “fly” is not necessarily a bad idea. But this should be done by providing a vision and leading your coworkers through the process of change. In this way, they can deal with the actual implementation through evolutionary change instead of having management trying to give exact instructions or ignoring the knowledge and abilities within the teams.
How Should You Navigate the Maze of Agile Transformation?
When I first read about introducing Scrum in a company, I found it excessive, or maybe a type of “showing off” that the literature proposes to have the team executing the transformation use agile themselves as their project management methodology. It sounded like a salesperson proclaiming that their product can be used anytime, anywhere. Yet, after some experience in the industry, my view on this has changed.
The point is that the significant challenge of the agile transformation is that the requirements are not fully defined. Every single organization is different, so there is no standard way of introducing Scrum to a company. This makes it a perfect candidate for evolutionary change--- navigating through these unknowns in small but steady steps.
The First Rule of Teaching Scrum Is to Not Talk About Scrum
The first thing I tell people I coach about Scrum is to forget everything they have previously heard about Scrum. I am in no position to know better than they do what their problems are, or to think that “my” methodology would help them. Scrum is not a magical cure. Management gets too quickly enamored with the idea that there is a method that, once it’s been introduced, will solve their problems. Since this simply isn’t the case, the question remains, how can organizations achieve real change?
In my opinion, change can be achieved only by means of mutual trade. You can win over the other side if you offer an advantage. The simplest way to connect your team with the idea of Scrum is to give them a helping hand. Do nothing else but have them start by writing down impediments, and set up regular meetings where you offer solutions to their problems.
If your team is not yet very experienced with recognizing impediments, you can lead them cautiously by asking direct questions and engaging them in discussions about why some work shows no progress. The more impediments you gather, even small ones, the easier your job will be in the next step. This list of impediments will become the golden key you need to---step by step---warm the team up to the idea of agile thinking.
Next, conduct interviews in the company to evaluate its current status in terms of agile maturity. There are many checklists available online; personally, I find the 50 points from Atlassian very helpful.
After this initial evaluation, categorize the gathered impediments according to the list. If needed, add additional categories for the remaining impediments that do not fit. For example, you might also want to evaluate the agile maturity of external suppliers which need to be integrated into your process.
Once this categorization is done, you can skip all points for which your team has not encountered any impediments. Without empirical evidence to support a certain change in your organization, there is no reason to “improve” the agile maturity in these other categories.
Obviously, the other points impede your team as well. But if there is nothing directly visible for the team, there is nothing you can do about it for now. Remember, you are implementing Scrum to solve actual problems of the team, not to create a PowerPoint presentation for management!
Not only will this give you an invaluable compass in the sea of possibilities of what you can change, but it will also provide you with empirical evidence to support any decision you are making.
We have established our current position by evaluating the status of the agile transformation in your company. We have also established a goal and have identified which of the points we should work on. Now, the real strength of the list comes into place: intermediary stages. Instead of just listing ideal situations, it shows the steps leading there. They represent small stories that can be worked on in individual sprints and thus can serve as a metric for your agile transformation process.
- The agile transformation is a complex project itself.
- The ideal approach to a complex project is agile and evolutionary.
- Analyzing the current situation and tracking progress with a good metric is key.
How do you navigate through the process of agile transformation? What metrics do you use to track progress? Let me know in the comments below!
comments powered by Disqus