So we have a recipy for the team. But this is just not enough. We need to make sure that management and everyone else is on board. The second part of the Scrum Shock Therapy presents a bootstrapping recipe on how you can do this.
The first part of this series can be found here: Scrum Shock Therapy, Part 1.
The Management Recipe
The checklist above is only a part of what it takes to go through Shock Therapy. I often find myself at new companies and need to work with a bigger picture than focusing solely on the team. As is evident from the polls and surveys above, we need to address management as well. The word shock is perhaps more applicable here. If it has learnt anything from the past it is that you have to “drive” development – delegate, follow up, check, adjust, hand out, recheck…
Telling them to trust the very group that has not delivered before is asking for a leap of faith.
Setting up a recipe for this group is tricky. You have to adapt to management style, the corporate culture and so forth and the things you ask for are softer. These can be very hard indeed to change! In plain English; The management has to take some more real tough decisions for a Scrum to work efficiently. If you need to kill a document standard or process step then do so! If this is impossible (for now) then go for “barely enough”.
The Management
- Attend the Scrum training session with everyone else
- Hands off during 3 iterations
- Attend:
- Some Daily Scrums – be quiet
- All Sprint Reviews
- Start to work on waste – now!
- Management by walking, asking and listening, i.e. practice facilitation.
- Make the first step easy for the team
- …
When learning something new you have to do it several times just to make sure you are not totally confused. I have found that three times a charm. Try your best to get management to abide by this “rule”. After the three iterations everyone has better picture to judge the value of the effort and Scrum.
Eliminating waste is vital on any type of project or endeavor. In a transition it makes even more sense, you have to make space to learn something new.
Finally, management has to ask the people that will perform these miracles what they need to do just this. Have they? Have you?
The Management Exit
- One successful team
- Removed impediments and studied results
- Change in perception at “ground level”
- A good agile reason to change the rule
Having one successful team is sort of self-evident. This takes patience when the ride is anything but smooth. Being a part of this process is important. Management will have the best ability to change ambition level, removing impediments etc. Get cracking and be that good example.
If there is a change at ground level on how they perceive management, then you’re probably on to something.
Is this recipe the final version – probably not? Your mileage will vary, adapt to your management.
The Organization Recipe
Many of our customers are just starting out doing Scrum. Therefore we typically come into play as an external effect. It is important for us to understand how the agile effort has started and its nature within our client’s organization. We can basically divide this efforts into to two major types – “bottom-up” and “top-down”. The typical traits for a bottom-up style is one where the programmers et al have decided to go agile. The management might be aware of this and even letting it run. Then again this might be a stealth and an under the cover job.
I have found the bottom-up approach to be the most common case. Programmers usually like to work in an agile way. In these type of setups my work usually revolves around questions like “How do we fit this to a waterfall context?” etcetera. This can be tough work, but I find it to be the more easy of the two – the people who do the day to day grinding are already on board.
The top-down effort of introducing Scrum comes with its own set of problems. Any methodology or decision that involves change tend to meet resistance from the organization. We need both experience and sideways effort to the transition.
The Top-Down Scrum Organization
- Get a Scrum Sensei
- Inject a Agile Senior Programmer into the teams
- Make sure there is organizational transparency
The Scrum Sensei is an experienced Scrum Master who’s been there before. Much in agile and Scrum is common sense, but there is no need in making the simple mistakes. With a battle-trained mentor the whole organization get a sounding board (Swedish: bollplank) helping out to implement Scrum. This part is important to the Shock Therapy where he or she will be the contract owner enforcing the startup and approving exit. In some sense this person could act as a “bad cop” in a good-bad ScrumMaster setup.
Or in the words of Nanny McPhee – a children’s movie where a nanny answers the seven ne’er-do-well children on how long she will stay:
– When you need me, but do not want me, then I will stay. When you want me, but do not need me, then I have to go.
The Scrum Sensei needs to work in similar way to bootstrap the team and management.
A top-down effort always risks resistance from the organization. My experience tells me that a side way force is needed for translation on the factory floor. Moreover, such a person has the experience on a technical level to do the hands on tools and practices that is a vital part of any agile projects. A seasoned programmer with agile experience knows what works and how to translate the management vision into bits and bytes.
“Self-evident” sometimes reads “evident to myself and no one else”. If we want to affect the organization we also have to make sure that practices, experiences and results are easy to come by. Walking down a corridor should yield interesting information about ongoing projects. If there is a pilot project doing Scrum then visibility is high on the wish list. Not only does it mean commitment for the Scrum team, but also a pull factor for other teams to get on board. Organizational transparency comes in many flavors. Apply liberally!
Summing it up
There is no denying that projects have problems getting started with Scrum. But more often than not I believe that we can do something about it. Why not try some nice Shock Therapy?
It might be the sweetest hard deal around!
/Björn Granvik, Jayway
MySpace Therapy:
http://jeffsutherland.com/scrum/2008/09/shock-therapy-bootstrapping.html
Scrum Poll on Nokia Test Practice:
http://tinyurl.com/68vapj
VersionOne Report: State of Agile Development Survey:
http://www.versionone.com/agilesurvey/
Situational Leadership:
http://en.wikipedia.org/wiki/Situational_leadership_theory
Nanny McPhee:
http://www.imdb.com/title/tt0396752/
Originally published at Jayway Team Blog.
Tags: scrum, shock therapy
Tumblelight 
June 24, 2009 at 09:03 |
Yup, it’s true that this mainly addresses the beginners – at least on team level. The management recipe is a bit different. Most of the companies I’ve seen has a longer way to go as far as understanding what it means/takes to be agile. For instance the “wait 3 iterations” advice could be administered several times with different teams. Most managers realize more, every time around. However, it is true that there is “wave” of problems that needs to dealt with – that’s for another blog 🙂
June 18, 2009 at 07:53 |
This therapy session invites the beginners. If you’ve been Agile for a while, you´re hit by the next wave of challenges and problems. These are not adressed above, but may get one to need the therapy session.