“The key to change is to let go of fear” – Rosanne Cash
Changing anything often invokes fear in people; it is something new and, as such, we don’t know what is involved. We are naturally skeptical of the unknown and, of course, there is always a chance we might not be very good at it, or even worse, might look silly while trying. While a team can grab on to something as simple and effective as Scrum quite quickly, all the associated changes that spring up as a result can cause significant worries. There are some very common broad issues that I warn people to look out for when adopting Scrum in an organization as well as a whole host of nuances that will almost inevitably crop up at some time as well.
I share a few of them in this article so that you can be prepared for them or, perhaps, not feel too bad that you are experiencing them yourself – they are common.
That’s Not The Way We Do Things Around Here
“Change is like heaven: Everyone wants to go there, but nobody wants to die” – Carly Fiorina
When I heard Carly use this phrase she accompanied it with the statement that when most people think of change they think that everyone else needs to change to be a little bit more like them. When using Scrum properly in an organization, it requires pretty much everyone to change the way they work.
There are a lot more opportunities to hide in a waterfall project and this can be attractive. The good news is that, from a business perspective, we are less concerned with what each individual contributes and more interested in the effectiveness of the team.
The team will naturally be interested in what the individuals are contributing and I have to say I was expecting a “Survivor” style trend with teams “voting off” the weaker members so the team doesn’t get dragged down. I have, however, been pleasantly surprised with what I have seen in practice over the last 10 years. The vast majority of Scrum teams that I have seen have favored a supportive approach to lift up the weaker team members rather than boot them off the team. Now of course, if there are other agendas present this will have a major influence on the team.
A common fear I see is that of the super-specialist. The “hero developers” are often fearful of Scrum because it is much more important for the team to succeed rather than the individual. A Scrum team realizes that by having super-specialists in any particular discipline, we are increasing risks in the project and, longer term, in the organization. In Scrum, we would much rather deliver something that the business or our customers need rather than what the people and skills we have enable us to deliver.
This doesn’t mean, however, that we want all Scrum team members to become homogeneous, interchangeable resources (a terrible word to describe people anyway); far from it. We still want people to follow their passions and develop their interest areas and skill levels; the difference being we want more generalizing specialists that allow us to be more cross-functional. When they realize this, most people acknowledge they cannot be quite so self-indulgent and grasp the opportunity to broaden their skill set.
Bringing in HR early (in the initial training sessions is a good idea) can help with this fear as they can assist in re-structuring policies to better support the change while reassuring people of their importance and incorporating their personal desires. HR should also be included to help conquer team fear, and issues with Scrum’s demands for greater communication, feedback and interaction. Often people in an organization haven’t received any training in simple things like giving and receiving feedback or dealing with conflict – both essential ingredients in a successful, high-performing, self-organizing team.
From a Product Owner perspective, Scrum requires them to make early and regular difficult decisions on priorities – what items from the Product Backlog should we do now and later? In a traditional project environment, these decisions can be deferred and not judged until very late as they only come together near the end of the project. In Scrum, we are asking Product Owners to make these calls every Sprint which is scary but actually, in practice, makes these decisions a lot easier as the worst that can happen is they make the wrong decision for a Sprint – they can change it in a month.
Strangely enough, relatively few people are fearful of being ScrumMasters, despite it being a role that combines a lot of responsibility with no authority. People are most fearful of this role when they are selected for it and either have a poor understanding of what is involved or are not clear on how it is different to their previous role.
What About The Project Managers?
This question comes up time and again and is met with great puzzlement by many – how does Scrum work without a project manager? Someone to take charge, look at the bigger picture, act as the translator/middle man. It is true there is no project manager role in Scrum; this doesn’t mean, however, that there is no project management. The traditional responsibilities of the project manager are shared across the three Scrum roles (and some of them are no longer necessary). I have seen companies deal with this in many ways and at the two extremes are:
- Call your project managers ScrumMasters.
- Fire all of your project managers.
I would recommend neither of these. Of course, some project managers will make excellent ScrumMasters (read Stacia Broderick’s lightbulb moment for a great example of the transition process) but, of course, some will make terrible ScrumMasters. Those that are unable to let go of their illusion of control over a team will never allow the team to flourish and realize its potential. However, although you should probably expect some people to walk away from a Scrum organization, project managers are still valuable in most organizations and great change agents and impediment removers. Some even make great Product Owners. Project managers should not fear Scrum although it is entirely understandable at first. Indeed, when I changed role from Project Manager to ScrumMaster my initial feeling was that I was not needed but that was not the case; I was just needed in a different way. I cannot recommend strongly enough to any project managers out there to try and do themselves out of a job by building up a self-organizing Scrum team.
What About My Plan?
“Fear has a large shadow, but he himself is small” – Ruth Gendler
Another big barrier to teams making the jump to agile is the lack of the comforting predictive plan whereby we plan out the uncertainty in a project, plot the path, determine the end date and the cost then produce the nice reports along the way. Funnily enough whenever I ask the question “but are those plans ever right?” I always get a negative response. Yet we place so much faith in them and they absolutely have to be there because it would be too scary to proceed without one.
The good news is that a Scrum project will come up with a baseline view of how much the project will cost and when it is likely to be finished. The only difference is that we are very explicit right from the start that this is wrong and we will make it better as soon as we start working on it. There is an amazing feeling of relief when we can become comfortable with uncertainty and a freedom to actually discover what is needed at the appropriate time. We can also avoid the many technical successes of the past – a project that has “met the requirements” but doesn’t do what we need – because, instead of relentlessly following the pre-defined plan we will adapt our projects to the inevitably changing conditions.
Progress reports are a lot easier to deal with on a Scrum project as well because we can see, tangibly, what we have produced every Sprint. Most of the reporting structure we have in projects is to deal with the uncertainty of the plan and the fact that so much time will elapse before we can objectively assess progress that we need regular reports to keep our comfort factor.
Get some help
Doug Shimp recently tweeted “if you think it is expensive to hire a professional to do the job, wait until you hire an amateur…get a trainer/coach” and he has a point. Getting somebody in who has been there and seen it before not only helps you avoid some pretty costly mistakes but also provides a great deal of confidence for your teams – it’s suddenly not quite so scary for them. Again, a good coach will do themselves out of a job as quickly as possible by sharing their knowledge and helping people learn from their own mistakes and the coaches experiences. There is sometimes a fear that we don’t want other people (especially outsiders) to see our dirty laundry but it’s OK to ask for help and, the chances are the coaches have made the same mistakes you are making right now.
Take your time
There is almost never an absolute drop-dead timeframe by which a Scrum change must be successfully embedded and, depending on the size and culture of your organization, this is likely to take years (seriously…years!) so be prepared to take your time. Don’t rush it but equally keeping a change going for that long takes dedication as momentum can easily drop off after the early enthusiasm wears off. Keep celebrating successes and setting yourself new challenges, explicitly stating the benefits of achieving them. This is the best way to keep it going along with planning for succession. The management who initially sponsor the change to Scrum will likely be gone or in a different role by the time it finishes so plan for succession before it is needed; make sure there is a seamless handover so no momentum is lost.
Summary
Scrum is a massive change for everyone in the team and, eventually, the organization. All change invokes fear and recognizing and then discussing those fears goes a long way to mitigating and removing them. Sometimes having an experienced coach there who has seen it all before can make a big difference. The only way you can get anyone to change is to explain how this change will be beneficial for them – you cannot buy commitment, only compliance – but the good news is there are benefits from Scrum for everyone and it is absolutely OK to take your time on the journey.