Take a Seat, Please
Commencing the Transition to Scrum
12 July 2013
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
OK, the decision has been made that you are moving to Agile/Scrum from a more traditional method, most likely Waterfall. Scrum has three clearly defined roles: product owner, ScrumMaster, and team. In this new framework, then, who gets to do what? It's natural to assume the PO is the product manager, the ScrumMaster is the project manager, and the team is, well, the team. Great; so now we are off and running.
Is it truly that easy? Are the attributes and qualities required for the existing roles an ideal match for the translated Scrum roles? And what about the guy that used to be in charge of everyone -- what is his place in this new world?
Let's explore each of these questions in a little more detail.
It is hard to argue that the qualities of a good product manager don't translate to being a good product owner. Having said this, product managers can often find themselves doing a myriad of other things that distract them from the necessary attention to the project. Remember that previously, they may have become accustomed to giving the development team a list of requirements and coming back six months later to see what's been delivered. It may be necessary to extend the product management/owner team to support strong PO involvement. This can be problematic if you aren't looking to increase head count. I had one recent experience where overnight the most senior developers were commissioned as POs. In a case like this, not only are you losing the skills of some of your best development resources but it's most likely that they have ingrained qualities that don't necessarily lend themselves to the PO role. The focus of the PO is the end user. For most developers, it is all about the code. I'm sure you can see the mismatch.
In Waterfall, project managers had a more supervisory role than exists in the ScrumMaster role in Scrum. The ScrumMaster is a coach and mentor who develops a much more intimate relationship with the team. Definitely, there is nothing excluding the project manager from making this transition, but there may be a need to consider the appropriateness of the particular individuals. Conversely, others should not be excluded from being ScrumMasters. It is possible that suitable candidates can be found among existing functional managers, for example.
Clearly, existing developers, testers, and writers form the Scrum team. There may be question marks about the willingness of certain team members to make the transition to Scrum. Some may not be easily swayed to adopting a new approach. They are less likely to be won over by PowerPoint slides extolling the virtues of Scrum but rather will base their opinions on personal experience. At the very least, there needs to be a degree of openness to trying the new model, otherwise they may be best left to work on projects that don't dictate the need for Scrum. Carrying forward a naysayer is unhealthy for the team and the project.
So, what about those who don't find themselves with a seat within the Scrum framework? These are most likely the various functional managers. Aside from the obvious people-management responsibilities that remain, they should have a clearly defined role of assisting in the removal of impediments for the team. They also become cheerleaders for the cause. For many, this may be a difficult transition.
The point of this article is not to suggest that the people fulfilling the various existing roles and titles are not suitable for the new roles in Scrum but rather to suggest that this should not be an automatic response. Maintaining the integrity of Agile/Scrum principles is paramount when making a successful transition and therefore warrants careful consideration as to those best placed to ensure that it is achieved.
Current rating: 4 (1 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.