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 »

How to Help Management Make a Better IT Decision

January 26, 2012 — Bruce McGraw

Decisions that directly affect Information Technology (IT) projects or IT services within an organization are not always made in the IT (or Engineering) department. That is not bad thing; it is just the way things are and how business runs.
Like what?

  • Management decides it is in the company’s strategic interest to form a partnership with another company that includes exchanging selected IT services
  • A desirable client requires all documents to be in Microsoft Word, Excel and Power Point
  • Planning which IT functions to centralize and which ones to operate independently or with greater flexibility
  • Figuring out how to balance data security and personal privacy
  • Allocating the internal IT budget to the needs of the organization

The good news is
Almost all companies and organizations ask for consultative help from IT or Technology professionals and project managers as they deliberate strategic decisions that involve IT related tasks.  Of course senior management needs to realize that the options under consideration involve IT, either directly or indirectly. If they don’t get it, you – the project manager – may need to be proactive (subtly and with political sensitivity). For example, if you hear via the grapevine — oh, yes your organization has one so get plugged in! – that the company is considering purchasing XYZ’s CRM system, you might remind your boss that XYZ’s system requires upgrading your server or that it does not work with the database that you currently have.
In asking for a professional opinion from IT, I have found that decision makers treat these expert professionals in one of three ways – hint: the first two are bad.

  • The IT professional is viewed as a deity with magical understanding and powers.
  • The IT professional is viewed as someone who does not understand the reality of managing a for-profit business. So, their opinions or recommendations are viewed with skepticism as to motivation and possible empire building fantasies.
  • The IT professional is viewed as an essential and knowledgeable team member who can provide insight into options and consequences in order to make sound business decisions.

Effectively assisting management decision making

  • Prepare yourself with facts and the opinions of unbiased outsiders – especially if, based on your previous dealings with these managers, you know that “expert” opinion is given higher value than general opinions. (see: Fear No Project post on Cognitive Science Insights into Decision Making).
  • Remember that cost is a big decision driver for senior managers. Include short term costs and long term cost implications, such as maintenance and training in answering questions and presenting information — especially critical when the initial cost may be lower for a poor decision.
  • Prepare to discuss risks and the impact of the decision on existing and planned projects and organizational strategy.
  • Do NOT become emotional, remain calm and objective.
  • Do NOT talk down to the decision makers because they are less knowledgeable about technology. It is your job to explain options, costs and risks in layman’s terms. Consider using analogies and metaphors that will resonate with the shared experience of decision makers.(See the post on Communicating to a non-technical Audience)
  • Listen closely to questions and clarify concerns before giving an answer or recommendation. Offer to collect more information if they seem to want it before making a decision. Just remember that senior managers don’t like to postpone decisions.
  • When you have done the best you can, remain quiet and allow the deliberations to take their course.  One more time, be quiet and listen.

If you have additional ideas or have been successful in helping managers make better decisions, please share your insights.

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

Get every new post delivered to your Inbox.

Join 361 other followers