Six Recommendations for an Enterprise Scrum Transformation

26 April 2013

John Hill
IconATG


Background

This article describes six essential recommendations for an enterprise Scrum transformation.


When I attended the February 2013 Agile SoCal group meeting in Orange County, California, the main event was a presentation by George Schlitz, founder of BigVisible Solutions. The title of this presentation was "Agile Beyond the Teams — Holistic Change for the Serious,"1 during which George described the following five (nonhierarchical) facets of every enterprise that may need realignment when "going Agile" (condensed parenthetical descriptions below each facet are mine):

 

Leadership (Senior executive tenets that determine and control the overall enterprise)

Organization (Structures, policies, processes, and systems supporting the enterprise)

Note: Mike Cohn describes four organizational components requiring realignment under Agile that I believe to be part of this aspect: "Human Resources," "Facilities," "Marketing," and "Finance."2

Product/business strategy (Plans for products or services that the enterprise provides to its customers)

Delivery (Product development and delivery frameworks — e.g., Scrum, XP, Lean, SAFe, etc.)

Execution (Elements of the frameworks used for the Delivery facet — e.g., user stories, pair programming, TDD, etc.)

George then shared a holistic approach to change that can be used by enterprises of virtually any size in any industry, addressing all five of these facets. I completely understand (and agree with) George's categorization of these five interrelated facets that significantly impact Agile transformations across the enterprise.

As I drove the 50 miles to my home after the presentation, I thought about the kinds of common problems I've encountered over the years with Scrum implementations. I then evaluated my current approach to addressing these problems and realized that most (though not all) of them were largely solved by five specific recommendations I frequently make. My "sixth recommendation" (which always comes first) is to ensure that all five recommendations are first socialized at the leadership level (to ensure approval and buy-in), after which I'd request both initial and ongoing support "from above" for my recommendations. It's also sometimes helpful to sell one or more senior executives on suggestions like this and have them help make these recommendations to the leadership team (or work with a respected consultant to make the sales pitch). At the end of this discussion, I've included a table mapping the specifics of my recommendations to the enterprise facets presented by George that they impact.

The recommendations I make are not my invention but are instead well known. Much has been written about them on the Scrum Alliance website (mostly relating to Scrum, which will also be my focus).

And now for some background to frame the need for these six recommendations. . . .

Job descriptions and roles for Scrum development team members

Scrum eliminates titles for individual team members, instead viewing every member of the development team as being "equal." The team has no "boss" and decisions are made collaboratively, with the product owner taking responsibility for the content being produced and other business-related issues, while the ScrumMaster performs the well-known servant-leader function.

When we first introduce Scrum to a development team, team members already have specific titles with narrowly focused job descriptions that normally put them into a silo. Developers write code, business analysts write specifications, QA engineers write and execute test cases, etc. As I wrote in a 2007 article on this website:

This mentality fostered the "mini-waterfall" most of us see when initially implementing Scrum. That is, business analysts would write specs for a developer, who would code from the specs, after which QA analysts wrote and executed test cases, rejected code for re-work, and so on. This cycle repeated for so long that the sprint goal was not often realized. This model also resulted in much idle time for team members, as developers and testers had to wait while business analysts wrote specs, everyone else had to wait while developers wrote code, and so on.3

This model can be improved based on Scrum's encouragement for teams to become truly cross-functional. Given the proper opportunity (and leadership support), most developers can write great specifications (which are both lean and sufficient) and write effective test cases. I've also found that developers can execute test cases very well (as long as it's not their code being tested). Similarly, business analysts, QA analysts, technical writers, and the like can broaden their skills to include writing specifications, unit-testing newly developed code, writing test cases, executing test cases, and producing user documentation. The only exception to full cross-functionality, in my experience, is that only developers will write code. Following this model will enable the evolution of a truly cross-functional team. This is first seen near the end of a sprint, when QA resources are strapped and they indicate that they can't finish in time. Now everyone with any bandwidth can take up the slack, and the team meets the sprint goal more often than when each person is performing a single role.

Performance reviews and reward systems for Scrum development team members

The problem with role-based job descriptions that discourage cross-functionality is exacerbated when individual performance reviews occur (at least annually, sometimes more often). The review usually lists all of the attributes associated with one narrowly described job role and normally includes "goals" for the individual set during a prior review. These goals tend to focus on an individual's contribution and ignore how individuals should instead contribute to the success of a collective Scrum team.

Scrum, on the other hand, recognizes the need for collaborative, self-organizing teams to succeed. Performance reviews should seek to improve success for the entire team and the resulting software. Performance reviews must be conducted differently for Scrum to succeed. I've had teams degenerate into dysfunction immediately following traditional performance reviews. Team members return from their review and suddenly try to do a lot of individual work (in a silo) to show what they can each do alone in service of their current individual performance "goals" (usually tied to a desired salary increase).

Meanwhile, iterations fail, schedules and quality slip, etc. Truly Agile organizations today include a major component of the performance review dedicated to an individual's role as part of a team. In her presentation "Appraisals and Compensation: The Elephant in the Room," Mary Poppendieck offers her view on appraisals, bonuses, and compensation and their dramatic negative impact on performance in environments relying on collaboration — a topic often avoided, as it causes conflict between rewards and teamwork. She says:

Should we be surprised when our incentive systems extinguish collaboration if individuals compete for rewards? Another assumption built into typical appraisal and reward systems is that an individual's performance can be reliably and unambiguously assessed. However, this is true only when performance can be objectively measured and attributed to individuals and when individual jobs have almost no interdependence. These conditions do not apply to software development.4

Mike Cohn describes a better approach:

One organization I worked with revised its annual review form, removing the individual-oriented criteria, such as job knowledge, time management, and ability to balance multiple priorities. It replaced them with team-oriented criteria, such as makes others better at their jobs, contributes to shared knowledge, willingness to work beyond job title, and met team deliverable and quality goals.5

Potential employee assessments (for "new hires")

Recently, as part of an interview process, I completed an on-line "assessment" given to all prospective employees of an organization. The first section included business and logic problems, which was fine. The subsequent sections dealing with self-assessment, however, were traditionally oriented toward ranking self-propelled superstars ahead of truly collaborative team players. There were questions asking if you could confidently make decisions critical to the business alone in a vacuum versus the "need" to work with others. If your answer favored collaboration, the next questions drilled down into your lack of "confidence" in your work, your inability to work without supervision, the amount of detail you require before you begin to work, etc., with no good answers available. I was brutally honest in my answers and indicated that I preferred involving others in important decisions (especially when developing software). I was thus not a self-starting rock star and was likely evaluated as a good fit for the mail room (I didn't get the job).

In my pre-Agile days, I would have answered these questions very differently, since I was an aggressive self-starter requiring no supervision, capable of giving everyone orders and setting their priorities and direction for them. But this is no longer the ideal portrait of an individual developing software with others a part of a team.

The role of the project manager under Scrum

Traditional project managers can wreak havoc on Agile projects if they continue to operate as before (directing tasks, seeking status, scheduling numerous meetings to review requirements and schedules, disrupting the team, and significantly impeding progress). The concepts introduced by the Agile Manifesto require the role of the project manager to change under Agile. In Michelle Sliger's whitepaper "A Project Manager's Guide to Going Agile," she says:

When software development project teams move to Agile methodologies, they often leave project managers behind. Traditionally trained project managers are confused as to what their new roles and responsibilities should be in an environment that no longer needs them to make stand-alone decisions. This paper focuses on redefining the job of project manager to better fit the self-managed team environment, one of the core Agile principles. Special emphasis is placed on the shift to servant leadership, with its focus on facilitation and collaboration. Mapping of PMBOK knowledge areas to Agile practices is discussed at length. After reading this paper, project managers should have a better understanding of what changes they need to make professionally, and how to make these changes in order to survive the transition to an Agile software development approach. . . .6

The role of functional (line) managers under Agile

Functional (line) managers can wreak the same havoc as project managers across Agile teams unless they modify their behaviors. In Management 2.0: The Role of the Manager in Scrum, Pete Deemer describes line manager behaviors that are "fine in Scrum" and contrasts them with the following eight behaviors that either conflict with Scrum or are no longer necessary once Scrum has been implemented:7

  • Decide what work needs to be done.
  • Assign the work to team members.
  • Keep track of what everyone on the team is doing.
  • Make sure the team gets its work done.
  • Make commitments to management about how much the team can do by a certain date.
  • Be responsible for the team meeting those commitments made to management.
  • Compile a weekly status update report for management.
  • Hold a weekly team staff meeting.

In his article, Deemer explains how these behaviors now belong to other Agile team roles and describes the effects of these behaviors in detail when line managers cling to them on planet Scrum.

Product/business strategy is not always aligned with customer perception of "value"

How many times have you participated in a sprint planning session where the product owner cannot easily finalize the content for the next sprint due to indecision around which stories to complete next? Some multiple-sprint releases that require significant effort deliver little customer value. This makes product owners very nervous and is perceived poorly by the business.

Now for the recommendations:

Six recommendations to help an enterprise-wide Agile transformation when implementing Scrum

Based on all of the background provided above, here are my six recommendations to better ensure a successful Scrum adoption across an enterprise:

  1. Job descriptions
    • Rewrite job descriptions for the following existing team roles that have changed under Scrum:
      • Project managers6
      • Functional managers7
      • Analysts, programmers, testers, and user experience designers8
      • Align incentives for all Agile team members to encourage cross-functional, team-oriented activities per Mike Cohn's guidance5
    • Write job descriptions for the following new Scrum roles:
      • ScrumMaster9
      • Product owner10
  2. (Re)train staff on new and revised roles before attempting a Scrum implementation (and train all new hires on these roles during orientation). This activity must include:
    • Training project managers on their role in the Scrum framework (especially targeting how the PM role differs from that of the ScrumMaster!)
    • Training functional (line) managers to understand what they should continue doing while managing within the Scrum framework and, much more important, targeting managerial behaviors that should be discontinued under Scrum
  3. Reorient performance reviews to encourage team building and efficiency, reward team-serving, promote cross-functional behaviors based on the newly revised job descriptions, and discourage individual "superstar" goals that negatively impact teams.5
  4. Revise criteria for new hires by ensuring that assessments for potential new employees developing software properly evaluate an individual's potential role as a member of a team (and not seek individual "superstar" traits for anyone involved in software development, which is a collaborative activity).
  5. Determine "business value" for user stories. Educate the business to work with product owners on assigning relative "business value points" for user stories. Doing this enables product owners to understand the effort required (based on the number of story points) to deliver specific value (based on the number of business value points associated with each story). This encourages product owners to question delivering functionality with little business value that requires significant effort, and it spotlights low-hanging fruit (small stories that deliver proportionately greater business value).
  6. Obtain leadership approval and support for recommendations 1 through 5. Socialize these changes with leadership before attempting to enact any of them. Having approval, buy-in, and support "from above" better ensures success. This, however, can be a huge challenge, requiring more upfront work on your part (another significant topic requiring a different discussion).

Although following these six recommendations won't cure all of the problems across all five facets of the Agile enterprise, success can be better ensured for an Agile framework (Scrum in particular) to deliver smaller increments of software more frequently with higher quality than was possible prior to implementing these changes. Going into an Agile transformation, we must also recognize (up front) that these changes represent very real threats to the status quo, require initial buy-in and support at the leadership level, and could take time.

It often helps me to remember that Rome was not built in a day.11

Notes

1. Schlitz, G. Agile Beyond the Teams — Holistic Change for the Serious. Presentation delivered at [ANN] AgileSoCal Meeting, Irvine, California. February 20, 2013.
2. Cohn, M. Succeeding with Agile: Software Development Using Scrum. 2010; Addison-Wesley Professional, 38-40.
3. Hill, J. Shake It Up: Moving Beyond Plain Vanilla Scrum. Scrum Alliance. January 29, 2009. http://scrumalliance.org/articles/35-shake-it-up.
4. Poppendieck, M. YouTube.com, http://www.youtube.com/watch?v=MSYlqx1Yvqk. November 10, 2011.
5. Cohn, M. Succeeding with Agile: Software Development Using Scrum. 2010; Addison-Wesley Professional, 29.
6. Sliger, M. A Project Manager's Guide to Going Agile. Rally Software Development Corporation. March 2, 2006. http://images.brighthub.com/media/9039B0_a_project_manager-s_survival_guide_to_going_agile.pdf.
7. Deemer, P. Manager 2.0: The Role of the Manager in Scrum. Scrum Alliance. December 9, 2009. http://scrumalliance.org/articles/148-manager--the-role-of-the-manager-in-scrum.
8. Cohn, M. Succeeding with Agile: Software Development Using Scrum. 2010; Addison-Wesley 29.
9. Hill, J. Empowering Teams: The ScrumMaster's Role. Scrum Alliance. June 11, 2007. http://www.scrumalliance.org/articles/52-empowering-teams-the-scrummasters-role.
10. Pichler, R. Agile Product Management with Scrum: Creating Products That Customers Love. 2010; Addison-Wesley Professional.
11. Heywood, J. Epigram, 1546.

Article Rating

Current rating: 0 (0 ratings)

Comments

Cherie Silas, CSP,CSM, 6/9/2013 9:22:19 PM
Very Good Article. Concise and filled with great information. I'm going to share this article with my clients who think that they can simply teach people scrum and transform an organization.

A Transformation simply doesn't work without proper change through every thread of the organization. If you want scrum masters, you need to have job descriptions that align with scrum masters and hire people experienced with scrum. But - If you keep posting jobs for project managers ... that's what you'll get! This creates a never ending cycle of starting over from the beginning that hinders a true transformation.
John Hill, CSP,CSM,CSPO, 6/10/2013 2:26:51 PM
Cherie: Thanks for the kind words. It's always refreshing to hear from someone else that actually "gets it". And thank you in advance by helping to propagate these "new" ideas with your clients. Although things are already beginning to change, efforts from those like you will increase the velocity of these changes. Thanks again! John H.

You must Login or Signup to comment.