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 »

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 »

Cognitive Science Insights into Decision Making

January 12, 2012 — Bruce McGraw

Those of you who know me understand how my company relies on cognition principles and experts to make our projects successful.  Dr. Karen McGraw, the founder of Cognitive Technologies, has said on many occasions that “Cognitive is the first word in our company name because if you don’t focus first on the way people think, work and learn, technology will not make any impact.”  I try to use this guiding principle in all of my management roles and projects.

Making decisions—selecting the best action among alternatives—is a key management responsibility. The higher in the organization a person sits, the greater the impact their decisions have. Because decision making is closely tied to company profitability, the “how” and “why” of decision making has received a great deal of study from cognitive scientists and business professionals.

Project managers often are called upon to provide expert opinions to support decision makers.

Here is a possible scenario …
Your boss’s boss calls on you to present your advice about an IT related decision under consideration, such as securing proprietary data, timing the transition to a new computer system or finding a teammate or subcontractor for a proposed project. If you do not have a personal or professional stake in the eventual decision, your task is to provide factual information and perhaps a professional recommendation.
However, when you, your project or your team will be directly impacted by the decision, you would be well served to apply some of the lessons learned by cognitive scientists on factors that influence people in making decisions.
Cognitive science research tells us that the influence of what you say will be enhanced or diminished by how you say it.

  1. Do some homework about the decision maker. Either based on your experience or the observation of others, try to determine:
    1. What types of information sources the person “values”. Some people are persuaded by academic research and published data, while others disregard “ivory tower” recommendations. Some managers may be motivated by industry standards and best practices. Other managers may prefer information sources that reflect innovation and outside-the-box thinking.
    2. Are there other managers whose opinion affects the decision maker’s preferences? (Sam really distrusts Joe and would not want to do anything that Joe recommends.)
    3. Do the manager’s past decisions reflect the desire for high risk / high reward or slow, measureable progress?
    4. Does the decision maker want quick results or long term impact?
    5. Are there issues outside of the question at hand that are important to the decision maker, such as customer needs, security, worker satisfaction or the environment? (All managers care about cost)
  2. Remember cognitive biases and their impact on processing information (see Does Your Organization Have Cognitive Biases that Influence Management Decisions?)
  3. People generally prefer the decision option that requires the least amount of cognitive effort (“Examining cognitive functions with fMRI”) reports cognitive science researchers from Carnegie Mellon. This may explain why some managers find just saying “no”, easier than actually weighing alternatives or committing to actions. The research further suggests that individuals expend less cognitive effort deciding in favor of a small “for-sure” gain over a potentially risky, but higher-value, gain. “Conversely, the cognitive effort expended in choosing a sure loss was equal to the cognitive effort expended in choosing a risky loss.”
  4. Frame the discussion by choosing descriptive words that resonate with the decision maker’s view of herself or the world. According to George Lakoff, professor at the University of California, Berkeley, people often make decisions based on the way they cognitively represent (or frame) a potential action. Lakoff calls these metaphors and they are the associations one makes to certain words. For example, because of unconscious frames, some people are more persuaded to “become fit” than to “exercise”. Some managers want to “Win the fight”, while others prefer to “protect our assets or position”.
  5. Even though cognitive scientists study differences between the decision-making influences in men and women and have research findings such as, “…women perceive greater risk across many real and hypothetical scenarios relative to men…” (Scientific American, September 20, 2011), beware of changing words or stories based on assumed differences in gender or cultural cognitive style or stereotypes. I would not do it.

An interesting thought piece by Gary Williams and Robert Miller published by Harvard Business Review in 2002 entitled “Change the way you persuade”, suggests some words and concepts may be more effective when making recommendations to managers based if you consider their decision-making style. Based on 1600 interviews with executives, the authors divided decision making styles into five categories: charismatics, thinkers, skeptics, followers and controllers. Here are a couple of their suggestions:

Decision Making Style

Persuasive Words and Concepts
Charismatic Use words like, “proven”, “easy”, “results”; use simple concepts and visual aids that focus on benefits and features. Acknowledge risks. Keep presentation short.
Thinker Have lots of data from different, but relevant, sources. Complexity is okay. Do not emphasize risks. You may be better off just giving them information and letting them reach a conclusion.
Skeptic Establish your bona fides first. Tie your recommendations to those of someone they trust. Expect disagreement and questions. Willing to take risks based on the recommendations of a trusted individual.
Follower References and testimonials can be helpful. Emphasize success others have achieved when following this recommendation. Provide instruction on technical issues. Help them feel confident that they are making the right decision.
Controller Do not emphasize risks, focus on benefits. Provide details to backup recommendations. Do not push for a quick decision.

So are do you know how you make your decisions?  Are you watching for other cognitive clues from staff and stakeholders?

Posted in Best Practice, Communication, Leadership, management, Project Management. Tags: , , , , . 2 Comments »
« Older posts
Follow

Get every new post delivered to your Inbox.

Join 361 other followers