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 »

Improving Productivity – Suggestions from PMI

December 9, 2011 — Bruce McGraw

If you have not wandered through the Project Management Institute’s (PMI) knowledge center, you have missed an excellent source of best-practice thinking on a variety of issues relevant to project and corporate management. Recently I reviewed an article by Pradeep Patra, PMP and Sunitha Bartaki, PMP of Tata Consultancy Services Limited that I thought was interesting. The article titled, “Productivity Improvement Using Ten Process Commandments” can be found in its entirety here.

At the beginning of their article, they note that productivity improvement is never ending, as discussed in writings on Kaizen and the philosophy of continuous improvement. Productivity improvement initiatives can also be costly. Therefore, their first recommendation is to develop and use a cost of quality (CoQ) to evaluate the impact of changes designed to improve productivity.

Their productivity commandments are:

  1. Leadership commitment
  2. Manage change — Absolutely, I agree. Productivity improvement requires change and to succeed at managing change requires the active support of visionary leaders. (see previous posts on change management: Change Management Strategies, Role of Project Managers in Change Management, and Planning Your Organizational Change.
  3. Organize and plan — can I say, “duh.” However, they continue the “organize and plan” discussion by recommending that the organization create a prioritization of changes — just like ranking software change requests — and that individuals create and monitor early warning signs of problems as part of risk management. OK, that is a very good thing for all organizations to do.
  4. Reward people for contributing to the productivity improvement process.  You have to incentivize people if you want them to change and try new things.
  5. Train the leadership team, participants, customers and clients. The better stakeholders understand the productivity improvement process, the more valuable will be their support and contribution.
  6. Create a process improvement framework for project managers, engineers, process managers and support personnel. If the cultural change required is significant or the suggested improvement costly, complete pilot studies or small implementations before spreading across the entire organization.
  7. Measure key variables -  this goes without saying for any initiative you try to implement.
  8. Assess and evaluate — “evaluate what you want because what gets measured gets produced.”
  9. Improve communication – I have written several posts on the importance of communication.
  10. Focus on benefits — measure cost savings following these do’s and don’t’s:
    1. Do: assign representatives from finance to validate the initiative and remember to include soft benefits that indirectly affect profit, like customer and employee satisfaction.
    2. Don’t: make productivity improvement another name for cutting costs, nor set unrealistic targets that doom the initiative to failure.

Although the recommendations seem simplistic — and you have heard it all before — the suggestions for a successful productivity improvement initiative are valid.

Posted in Best Practice, Change Management, Project Management. Tags: , , , . 1 Comment »

Finding a Content Management System Solution – Part 2

November 17, 2011 — Bruce McGraw

Last week in part 1, I talked about selecting a content management system (CMS) (which has many names like records management or knowledge management) from a technical perspective. However, just as with any productivity-enhancing tool, the process does not end with getting the tool. Rather, the process begins by understanding the value of content management to the organization and ends with training, acceptance and implementation. If your organization truly wants to benefit from content management, there must be changes in “business-as-usual”.

Your organization will need to have all of the stakeholders participate in any project to implement a CMS so you should be prepared to involve business units, legal, finance, contracts, marketing, operations, human resources, PMO and any other groups who have a stake in the information flow of your organization.  You will also need a plan for the implementation project so that you can achieve outcomes that are beneficial to the organization.  To quote Lewis Carroll, “If you do not know where you are going, any road will get you there.”

In 2006, Dr. Karen McGraw, CEO of Cognitive Technologies, suggested 10 questions decision makers should answer before committing resources to content management system solutions (Dr. McGraw’s complete white paper):

  1. What content do we need to manage better or use more effectively?
  2. What types of content management initiatives are we involved with already?
  3. Where is the greatest impact for content management efforts?
  4. Where are the best opportunities to achieve business value and ROI?
  5. Where are we in terms of content management maturity?
  6. What kind of technical infrastructure is required to support content management?
  7. Are we prepared to implement and manage the cultural changes that may be required for content management to be successful?
  8. What are the characteristics and competencies our employees will need to succeed with content management?
  9. Does our content management initiative support our strategic business objectives?
  10. Am I providing the required leadership and support to ensure the success of content management initiatives in my organization?

Dr. McGraw emphasizes the point that implementing a content management system should not be undertaken lightly or perfunctorily if benefits are to be achieved. In my experience, the key to success is user acceptance. If staff members see value — or potential value — in content management, they will expend the time and effort required. If users do not anticipate gaining any direct benefit, they may perform only the minimal tasks needed to comply with the process. Worse, they may sabotage the system through inattention to detail, refusing to use the system or discouraging others.

Getting User Buy-in
The value of implementing a content management system may not be intuitively obvious to all employees when considered in light of their current job tasks. In addition, seasoned veterans of other management initiatives may sigh with foreknowledge that they will have to do something more and different. Therefore, it is up to management to sell a vision of the content management systems benefits to the organization and to individual workers.

Here are seven tips that will stimulate employee buy-in:

  1. Get a representative group of users to participate in setting up the CMS — identifying the source documents and agreeing on the tags and taxonomy — classification scheme — that they would find helpful when searching for information
  2. When rolling out the CMS initiative, use stories and examples of time saving and quality improvements that tie directly to the work being done by individuals in the audience
  3. Offer incentives for early adoption
  4. Ensure that managers and leaders serve as role models in using the CMS
  5. Provide training
  6. Make sure the tools provided by the CMS offer easy-to-use mechanisms for the employees to add and describe content
  7. Plan and implement a process to keep content updated and well organized (read that as tools, responsibilities and information). Nothing turns off users like outdated materials or hard to get to information.

Managing Change
Implementing a content management system across the board yields many benefits to the organization in capturing and accessing knowledge. However, a CMS based system requires changes in business-as-usual. Your organization can learn from other successful change management strategies to successfully transition to effectively using your new CMS.

In the past I have talked about change management and you will find some helpful hints and practices here: Role of Project Managers in Change Management, Project Management PMBOK – Monitoring and Change Control, and Planning Your Organizational Change. Best practice suggestions for change management include:

  • Have a plan
  • Involve key stakeholders and keep them informed
  • Use small projects or departments to test the CMS and polish any rough points before rolling it out over the entire organization
  • Expect resistance — because some people just fight change of any kind. Understand the source of their concerns and address them:
    • The known is comfortable
    • Change requires thought; many current work behaviors have become automatic and require no conscious effort
    • Some people resist change in principle
    • Change is scary—you don’t know what you will win or lose
    • You may fail in the new world order
  • Develop outcome measures to evaluate the CMS
  • Seek assistance from change management experts either in your own HR department or ask for outside training or coaching
  • Offer training
  • Reward effort

If you and your organization have implemented a CMS, please share your experiences and suggestions to facilitate success.

Next, in part 3 of this discussion, I will address one of the most important aspects of a content management system – what do you do after the implementation to maintain the effectiveness and use of the CMS?

Posted in Best Practice, Change Management, Content Management, General Project Management, Knowledge Management, Planning, Project Management. Tags: , , , , , . 1 Comment »
« Older posts
Follow

Get every new post delivered to your Inbox.

Join 393 other followers