Implementing Scrum techniques as a project methodology (or really a framework) represents a major culture change in a traditional organization. In the beginning, the change agent, Scrum Master or Scrum champion may encounter resistance from C-Level managers because they hear the words used to describe Scrum through a different filter than developers. This difference in perception becomes greater as the size of the organization and the distance from project execution increase.
What C-Level Manager May Think
|Self-directed team||No management or controls|
|Daily Scrum meetings||No work will get done if the team is constantly having meetings|
|Product and Sprint backlog priorities determine the next set of tasks||There is no over-all plan, design or Gantt schedule – will they ever be done?|
|Scrum team members do not have job descriptions||How can individual performance be evaluated (and raises distributed) if I do not know what each individual is expected to do and how well they do it?|
|The Scrum team decides how much work can be completed during a sprint||We bill the customer based on completion of Contract Line Item Numbers accepted — how can I predict income?|
|Only the product owner can change the backlog||Does that mean I cannot go to “good ‘ol Paul” and get him to add a little-bitty new feature over the weekend?|
In my experience there are techniques to lessen C-Level concerns about Scrum. For example, I recommend scheduling an orientation meeting for senior managers with several objectives in mind:
- Identify the problems and challenges that drive the decision to try Scrum
- Use numbers — how many projects deliver on time, how many complaints from customers, how often requirements change after the original contract is signed.
- Tie problems and challenges to the cost of maintaining and upgrading
- Demystify Scrum terms by mapping them to more commonly used concepts such as (“Scrum as Project Management” Kevin Thompson from CPrime):
- Schedule = Sprint (or Release)
- Scope = Sprint Backlog
- Work Breakdown Structure = Task Breakdown
- Productivity = Velocity
- Estimate to Complete = Burndown Chart
- Explain the Scrum process and framework. Show how Scrum is designed to remove some of the conditions that lead to problems in traditional or waterfall developments.
- Reassure them about the transparency of Scrum projects and the rapidity by which problems are identified or changes accommodated.
- Have a game plan to implement Scrum that reduces perceived risks, such as starting with a small project or prototype.
Once permission to “try it” is given, setup conditions to maximize success including:
- Select the team, product owner and Scrum master. Send the product owner and team to Scrum classes – Like Professional Scrum Master (PSM) training. This training needs to be more than reading a book or attending a one-hour seminar — although these are a good place to start. Follow up the introduction with a formal class — usually about two days of instruction from a Scrum Trainer.
- Provide senior management with a brief report about the training. Your goals are to provide information, reassurance and keep the interest alive.
- Ensure that business analysts, marketing or systems people work with the product owner in the beginning to establish the vision and the stories.
- Engage a coach to assist in the first few weeks or months who is an experienced PSM or scrum practitioner.
- When the team understands the vision and the product backlog, allow them to self-organize including setting up work space, planning sprints and conducting daily Scrums.
- Use the Scrum master to facilitate interaction, ensure Scrum procedures are followed and remove barriers to performance.
Give them closure
This is not a task that needs to be done every time – just during the Scrum demystification and selling phase. Either in a report or preferably a short meeting:
- Review the reasons Scrum was assessed as an approved framework and methodology.
- Review the Scrum terminology and the framework (events, artifacts, and roles).
- Describe the process used. Emphasize business value of the process and the deliverables.
- Do a demo (we call this a Sprint Review).
- (Here’s a key item) Provide two or three, articulate testimonials from the team and the product owner / customer. What did they like. How did they feel working under a Scrum framework?
- Have a plan that shows a progressive increase in number of Scrum projects, gaining Scrum master status for knowledgeable professionals, and ongoing staff training.
- Ask for questions and concerns: then address those immediately, either during the meeting or within 24 hours.
For those of you who have instituted Scrum in a tradition-based organization, your observations and suggestions are appreciated.
(On a personal note – several of you had asked me to report on my certification and I passed my Professional Scrum Master test this week!)
“How not to do Scrum”; New York City Scrum User’s Group