Why C-Level Managers May Fear Scrum and Agile

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.

Scrum Words

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


Learning Scrum – Staying up with the latest project techniques

The more I work within the Scrum project framework, the more I appreciate its practical and simple concepts. I am also interested in the expertise required to be a Scrum master. Like any skill you seek to master, the path may be harder than you want and take longer than you want. I am convinced however that applying a Scrum framework during project execution saves time, more actively engages the development team and helps avoid the problems that come from inevitable requirements changes.  Many of you project managers have probably been exposed to or are working with agile methodologies in your organizations.  Some of you may be like myself and are seeking to become a scrum master.

Gaining skill at any task, whether making cheese, playing golf or using Scrum requires learning basic principles and developing judgment based on experience. In the olden days, people learned a profession through three levels of increasing competence — apprentice, journeyman and master. To be accepted as an apprentice, a person needed to demonstrate basic understanding and possess a willingness to work hard to improve their skills. Apprentices worked on many types of tasks and projects under the supervision of journeyman. Projects were managed by masters. The masters provided a vision of the final product, developed plans to achieve goals and offered mentoring and training to the team.

Becoming a Scrum master requires the same type of disciplined learning and practice. So, how can you learn Scrum? My advice is to first become familiar with Scrum principles. Scrum.org provides an excellent, short overview called, The Scrum Guide, to get you started.

The Scrum Guide introduces you to the three pillars of the Scrum framework — transparency, inspection and adaptation. You will also be introduced to the titles or roles of the Scrum team. For example, there is the product owner who managers the product backlog such as setting task priorities, the development team and the scrum master. The Scrum world operates within very short time frames — usually two weeks to no more than one month to complete tasks. These one month windows are called Sprints.

After scanning the Scrum Guide, I suggest reading about the experiences of Scrum practitioners. There are many good books and articles about the process, including “Agile Software Development with Scrum” by Ken Schwaber and Mike Beedle and “Agile Project Management with Scrum” by Ken Schwaber. The series of Agile/Scrum books by Mike Cohn has received favorable reviews.

After you have developed general familiarity with the Scrum terminology and philosophy, I recommend talking or listening to professionals with real world experience. A local professional organization or university may offer invited talks on Scrum. Alternatively, conferences often have workshops or presentations about Scrum. You can also use the social interaction during these professional meetings to talk with masters and project managers about their experiences.

The next thing you should do is to look for opportunities within your organization to become part of a Scrum team. After a couple projects, I think you will appreciate the flexibility and freedom of working within a Scrum framework.  Identify and work under a Scrum master. Use your training experience to ask questions about how and why.

As part of your apprenticeship, I suggest you take a class taught by a Scrum master and certified trainer— usually a two day class that focuses on fundamentals, theory and practical examples of applying Scrum across a variety of development endeavors.  I have just completed the Professional Scrum Master Training course myself which was led by an excellent coach/trainer, Don McGreal.

Continue to work on skills and practice techniques. Over time, I have found that experienced Scrum teams are some of the most productive professionals I have had the opportunity to work with.

If you have worked in a Scrum environment, sharing your experience and observations will help newbies become contributors more quickly.

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts


Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another WordPress.com site