Get certified - Transform your world of work today


Implementing Scrum: 8 Questions to Answer Before You Begin

25 June 2008

For the past eighteen months, I have played a key role in my organisation’s Scrum implementation. Fortunately, I have been coaching people and practising Scrum in an environment where people are keen to learn new practices and are open to making changes. I have based most of my ideas on that of Ken Schwaber and Jeff Sutherland. Ken and Jeff emphasize the fact that Scrum is a framework and not a methodology. As I considered this after my ScrumMaster course, I decided to implement and coach the team on Scrum as if it were a natural evolution from our current process. To do this, I listed eight questions that I felt must be answered correctly in order for us to make a successful transition. I firmly believe these are questions every new ScrumMaster/Coach should ask prior to implementing Scrum because the answers determine whether your team can succeed with Scrum.

1. Does Scrum fit the bill?

The ScrumMaster should understand, and more importantly be able to visualise, how Scrum aligns with their organisation. The ScrumMaster will need to work with management to identify existing problems and brainstorm ways in which Scrum will help them find solutions.

2. Does management believe in Scrum?

Once the ScrumMaster and management have identified how Scrum will work for their organisation, the ScrumMaster must himself believe, and also convince management to believe, the following key tenets:

  • Software development is best implemented via an empirical rather than planned process.
  • Once organizational impediments are removed, a self organizing team will naturally deliver better software.
  • You can deliver valuable software within a prescribed time and budget.
3. What functional specialists does the development team have?

Once management has been convinced, the ScrumMaster needs to identify the functional specialists in the development process, such as developers, testers, analysts and managers. (You could identify more; I have just named a few).

4. How can I cater my coaching to the specific needs of each functional group?

The ScrumMaster is responsible for coaching each functional group by concentrating on how each functional group will fit into Scrum and benefit from it. The ScrumMaster should explain any changes that will arise from implementing Scrum. Each functional group needs to be educated on the benefits of using Scrum; no questions should be left unanswered. At the end of this process, functional groups should be convinced that Scrum will work for development. If a team member, in spite of exhaustive training, is unable to buy into Scrum, the problem should be escalated to management. Organisational behaviour is key to the success of Scrum.

5. Does the coaching recognise cross-functional teams and coordination?

Once all functional groups are able to comprehend and understand their role in Scrum, the ScrumMaster must bring the functional groups together and coach them on how they will work as a cross-functional team.

6. Does the team understand the difference between a leader and a manager?

It is important that the team understands the difference between a leader and a manager. The team should not report to the ScrumMaster; the ScrumMaster is a leader who guides the team, not a lead in the management sense.

7. Does management understand the difference between team roles and management roles?

Scrum roles are functional job descriptions; they are not part of the organisational hierarchy. Management needs to clearly isolate hierarchy and any decisions relating to these from the team. Teams need to understand that management reserves the right to manage the organisational structure and that scrum roles are for functional purposes only. Perceptions of ScrumMasters as team leaders or development managers could create a bottleneck right at the start for the ScrumMaster. In these cases, management needs to step in to more clearly differentiate between an orgainzational title and a team role.

8. Does the team know what kind of engineering processes are required?

Once the functional groups have been transformed into cross-functional teams, the teams should be able to brainstorm on the engineering processes required for iterative software development. Processes might include continous integration, automated testing, process templates, and so on.

Once a ScrumMaster has coached his team to this extent, the real execution of Scrum can begin.

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.

Article Rating

Current rating: 0 (0 ratings)


David Barker, CSM, 7/21/2008 5:49:08 PM
How do you educate individuals in your organization about SCRUM? Do you get them into a conference room and train them? Do you pass out literature on the SCRUM framework? Exactly how did you approach the role of 'Coaching'?
Srinivas Suravarapu, CSM, 8/1/2008 8:35:39 PM
Sorry about the delay, hadnt logged on for a while, to answer your question..

If your audience is the management, your idea of a conference room sounds good, but do the talking about management and its relation to strategy and then to Scrum and how it adds value, dont dwelve into Roles/ Backlog items and details of Scrum. You should be able to identify how this would help ur organisation. Use examples of other organisation, some of ken and jeff's books have these available.

If your audience is the development team, do it differently, (you should have management convinced on implementing scrum and awareness of this decision in the development team)
We started with daily scrums , and at the end of these daily scrums, for a minute or 2, i used to observe and advice the team on scrum based on some training i underwent and books i read, you could say its like a nugget based on problems identified in the daily scrum. Experiment a sprint or two trying to put your tasks on index cards on a board, it will be difficult initially to handle backlog items which are in the nature of a task.

After experimenting a sprint or two in this way, observe and record issues which need to be addressed by scrum, this could change based on your organisational behaviour and environment, hence i said try a sprint or two and observe. Make sure you dont miss out on impact of problems observed, on the business, try to link every problem to the end sale or the way business is conducted or value added and you should be able to see why the change is needed.

Doing this will ensure your team does not sit in a room with a power point being presented to them and forgotten.

Now as a scrum coach you have to read up books may be and try to align the concepts of scrum to the issues you have recorded
In the first coaching session , generally giving a bit of history on lean management and traditional management helps lay the playground for your coaching, explain may be about roles and scrum terminology. Do this more than once , as i mentioned in my article now target functional groups in the second round, then have a consolidated third round , each time coaching on more topics, this way you make sure you conciously atleast follow scrum
do these three rounds across three sprints not consecutive days. At the end of each sprint have a retrospective session which will feed back into your coaching requirements

Hope this helps, I have more to say but this as concise as i can be :)
David Barker, CSM, 8/4/2008 2:40:04 PM
Thanks Srinivas for your response to my question. Yes, I was speaking about project management specifically because many PM's have experience only with Waterfall development methodologies when scheduling projects. These methodologies draw heavily on the principles from engineering such as construction management. As a result, they stressed predictability (one has to plan every last detail of a bridge or building before it is built), and linear development cycles ΓÇô requirements led to analysis which led to design which in turn led to development.

So it is sometime difficult to convince them that there are new incremental approaches to performing software development. And there is difficulty in conveying the concepts and the rational to the management groups.
James Peckham, CSM,CSPO, 8/24/2008 12:32:18 PM
David: Scrum is more than just the iterative and incremental frameworks. It's about self management and lean/flow based process improvement. As it relates to waterfall, it's basically like a waterfall every day :) analyze a little in the morning, design a little, code a little, test all of that, commit to source control. Repeat this at least once per day maybe twice. That's how i sell it to my PMs. Another thing to explain to PMs is that they're not managing business value metrics not task level metrics. It took me a while to get our PM to understand the difference between backlog items and tasks. Tasks are for and ONLY for the team. Backlog items are how you manage the team, by prioritizing them and breaking them down smaller and smaller so sprints can be met with working software at the end.
Prashant Deshmukh, CSM, 11/25/2008 1:03:02 AM
Based on your experience, do you recommend that to keep provision for cross functional trainings during initial sprints?
Srinivas Suravarapu, CSM, 11/28/2008 5:21:49 AM
Its ideal if you can do this before you start your sprints, especially for functional groups not actively participating in Scrum on a daily basis, but seems fine to have a provision in your initial sprint.. Note that educating teams during sprint is to be factored into the time spent on Scrum activities, and this time spent should have been factored into your capacity planning for a sprint..

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up