Why C-Level Managers May Fear Scrum and Agile

February 16, 2012 — Bruce McGraw

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!)

_____________________________________________________________

Resource:

“How not to do Scrum”; New York City Scrum User’s Group

http://www.qualytic.com/sitebuildercontent/sitebuilderfiles/how_not_to_do_scrum_v4.7.1.pdf

Posted in Agile, Change Management, management, Project Management. Tags: , , , , . 4 Comments »

Go with your gut — cautiously

February 9, 2012 — Bruce McGraw

On the popular TV show NCIS, the team leader (Mark Harmon) is frequently heard exhorting his staff to “go with your gut” (for the women readers I guess you call this female intuition!). The lesson he is sharing with the team is that your intuition, as opposed to decisions based solely on analytics, may give you the best answer when you need to make a decision quickly.

Experts in neuroscience talk about intuition as a type of pattern matching. A new situation reminds you of a previous situation and its outcome. For example, given enough experience in selecting subcontractors, hiring coders, picking a winning stock or getting burned in a relationship, you develop a sense of when to move forward and when to walk away. Learning to listen to your instincts can save you time and trouble. Have you had the experience of meeting someone and knowing in the first few minutes that they were an expert in their field—or that they were “trouble”?

Let me call your attention to a recent Harvard Business Review Blog titled, “Learn to Trust Your Gut”. This is a well-written, if somewhat simplistic, view of listening to your inner voice when you believe a poor or even dangerous course of action is proposed.  When your inner voice speaks, the author suggests that, “If you think that doing things another way would make a material difference, talk to your boss (or customer or client). Why do we do it this way? Would you be open to different ways? What would be the payoff and the risk? Can we experiment with an alternative? Would it be worth doing some further analysis?” I agree this is an internal conversation worth having.

However …

Equally interesting to me in the blog post is comparing the author’s suggestions with comments from readers. Many commenters said — in different words and ways — “hogwash”. The gist of their negative reaction is that authority figures do not want to be questioned. They believe that following your gut, applying the principle that it is easier to get forgiveness than permission, or arguing for a different course of action than the one proposed by senior management is career limiting.  (If this is true, Steve Jobs should have not been very successful!)

So, why the disconnect?

I suggest that first you should ask yourself, “Whose decision is it?” As a project or team manager, if the final decision is yours, collect data and also tune in to your instinct. You will make a better decision when you take advantage of analytical and intuitive analysis.

In an alternate case, when your opinion is solicited before an action is taken by senior decision makers, I think you should give the questioner both facts and your intuitive assessment. For example, “I believe that XYZ Corporation brings useful skills and contacts to our proposal team. However, in conference with them, they only presented their approach and did not ask questions about our solution or the customer’s needs. I am concerned that they will have difficulty working in our cooperative environment.”

Finally, consider the situation, when as a project manager or team member you are told the decision and given your tasking. You “know” that the proposed activity is doomed to failure and you have an idea of a different, and more likely successful, way to achieve the stated goal. Here is where the situation becomes a bit sticky. What is the most effective way to share your insight and impact the action plan?

  • Before saying anything, reflect on your motives. Are you often the first person in any meeting who points out problems? Is your intuition telling you to avoid any change or only the proposed one? Are you reacting to the proposal or to the person making it?
  • Assuming, after your self-assessment, you conclude that your motives are pure and untainted by cognitive biases, then organize your thoughts and recommendations as talking points that demonstrate your appreciation of the decision maker’s priorities.
  • Unless asked directly for your opinion, it will be more effective to offer your comments and suggestions in a private face-to-face meeting than to confront the presenter publically.
  • If you are having difficulty putting words to your intuitive feelings, try talking it over with someone you trust and respect. Listen to their questions and feedback and allow it to help you organize your thoughts before talking with the decision maker.
  • Wait a day to let your cognitive analytical and intuitive thoughts coalesce before presenting your thoughts. Sleeping-on-it, like your grandmother said, helps. (Got a tough decision to make? Research suggests you’re best off just sleeping on it and Research: You make better decisions using intuition and Incubating Decisions).

If you have complementary or contradictory thoughts, please share.

Posted in Best Practice, Communication, Leadership, management, Project Management. Tags: , , , , , . 1 Comment »

Learning Scrum – Staying up with the latest project techniques

February 4, 2012 — Bruce McGraw

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.

Posted in Project Management. Tags: , , , , , . Leave a Comment »

Project Manager Travel Guidance

January 19, 2012 — Bruce McGraw

I am sure there are people who enjoy traveling as part of their job, although I have not met any of them recently! Travel to current or potential customer sites, subcontractors, giving a conference presentation or receiving training is sometimes necessary for the project and the organization. Who knows, sometime you might even get a vacation. So, who minds the store while the project manager is away?

Here are a few guidelines to help you prepare for your absence and minimize problems, especially if you will be gone more than a few days:

  1. Check the project schedule to see what is supposed to be happening while you are away. If anything tweaks your antenna as a potential problem, talk with the lead and develop an action plan. Tell them your concern or thoughts and get their feedback. This is a real-world opportunity to mentor project leads who may become project managers.
  2. Note any paperwork due during your absence — status reports, personnel forms — do it before you leave or assign someone.
  3. Check your calendar for any meetings you are required or promised to attend — assign someone to go in your place or let the organizer know you will be absent. If it is your meeting, contact attendees to cancel.
  4. Pull up or pull out your risk management indicators — anything that needs tracking should be assigned to someone while you are gone.
  5. Select a person to be in charge in your absence. Then, inform project personnel, your supervisor and department heads with whom you interact frequently — in writing — with contact information. You may also want to change for voicemail message and out-of-office email message. If your company’s policies allow, give the temporary PM signature authority, either total or specific.
  6. Make sure you have contact information for team members, the organization and your project customers on your cell, iPad or notebook computer. Redundancy is good here since bad or stupid things can happen. I have forgotten chargers and had liquid spilled on devices when we hit an air pocket.
  7. If you will not be reachable by email, phone or text message, assign someone to check your messages daily and follow up.
  8. Meet with your acting manager and review tasks and concerns. Use this meeting as an opportunity for training.
  9. Update your shared project or organization calendar to indicate you are out-of-office. If you use Microsoft server for project document management, be sure to check-in working documents.
  10. Contact your backup PM daily to see how are things are going. Let them know that you value their taking responsibility. Do not undermine their authority or confidence by criticizing decisions made in your absence. Ask questions that help them identify potential problems and think through possible solutions.

I probably left out some tasks that would be important to do before you leave. Project managers; please add your suggestions via comments.

 

Posted in General Project Management, management, Project Management. Tags: , , , . 2 Comments »
« Older posts
Follow

Get every new post delivered to your Inbox.

Join 361 other followers