oon after I joined a startup online service company I realized that for the first time in my career there was no project manager keeping track of the team’s progress and helping clear obstacles. The absence was noticeable in the disorganized manner work was delegated, tracked, and planned. I had just come from a dot-com that was trying out Scrum and I had become an enthusiastic believer in the efficacy of the process. So, I set about figuring out how to sell Scrum to my IT department and business management.

In this article I’ll attempt to use my experience to help you advocate for implementing Scrum at your workplace. I’ll help you predict and avoid the obvious pitfalls and help you prepare for the questions that are sure to arise from your colleagues and managers. This article presumes that you are familiar with basic Scrum and agile terminology. Some exposure to the concepts of Lean development is helpful but not essential. This article won’t detail what Scrum is or how it works but you can find pointers to excellent books and online information in the resources section at the end of the article or read our short, practical guide to Scrum.

Scrum Process Control?Know What You’re Selling!
Scrum is a project management methodology, not a development methodology and is based upon empirical process control theory. Scrum’s roots can be found in the Lean Manufacturing concepts that were most successfully advanced and implemented by Toyota over the last few decades. These ideas were ported to software development by Jeff Sutherland about 13 years ago. Jeff Sutherland and Ken Schwaber formalized and commercialized the process known as Scrum. You can find pointers to their work in the resources section at the end of this article.

A simplified definition of empirical process control is that processes are monitored and controlled with awareness of what is really being produced and a willingness to make changes based upon these observations. Manufacturing, in contrast to software development, usually has a well defined and fixed set of inputs; this makes it easy to implement rigid schedules. Due to the more predictable nature of manufacturing processes a prescriptive control methodology is appropriate. However, when a prescriptive control process is applied to an inherently volatile undertaking such as software development, both management and development personnel suffer the consequences.

The “Lean ideal” is to approach the building of anything in such a way that continuous process improvement efforts are considered an essential part of what is being built. Self-managing and self-organizing teams are empowered to make choices to improve the product and make their work more productive and enjoyable. I hope to delve into the evolution of Scrum from Lean concepts in a future article but if you’re in a hurry Mary and Tom Poppendieck’s book “Implementing Lean Software Development: From Concept to Cash” is a great resource.

The book outlines key Lean concepts that improve software quality. Many development managers and IT professionals (not to mention business people) still conceive of software development to be like manufacturing. Therefore, understanding Scrum’s roots in Lean manufacturing can help you make the case for Scrum by discussing how these progressive ideas map appropriately to software creation. These ideas aren’t of the ‘flip a switch and you’re done’ variety but rather concepts or themes that guide the way processes flow in your organization. In her paper, “Principles of Lean Thinking,” Mary Poppendieck succinctly lists these basic principles as follows:

The Basic Principles of Lean Development

• Add Nothing But Value (Eliminate Waste)
• Center On The People Who Add Value
• Flow Value From Demand (Delay Commitment)
• Optimize Across Organizations

These basic, underlying principles are then applied to translate Lean manufacturing concerns into the software development concerns listed below.

The Seven Wastes of Software Development

• Overproduction = Extra Features
• Inventory = Requirements
• Extra Processing Steps = Extra Steps
• Motion = Finding Information
• Defects = Defects Not Caught by Tests
• Waiting = Waiting, Including Customers
• Transportation = Handoffs

Check out the resources section of this article for more information about how to translate these golden rules into development best practices. For now, I’ll turn my attention back to making the case for Scrum.

Identify a Scrum Master
Like most developers my experience with project managers has been mixed: some I’ve been happy to have tending things and others just didn’t seem to do much to support the team’s efforts. The project manager in the Scrum process is called the Scrum Master. The Scrum Master is the steward and coach (with respect to Scrum and lean-agile techniques) of the team and a protector of the guidelines and practices of the Scrum process.

The Scrum Master is a leadership role and requires some people skills and the ability to confidently interact with your peers. While Scrum teams are intended to be self-managing and self-organizing the Scrum Master needs to be able to step in when team members deviate from the core Scrum practices. Being the sentinel of the Scrum process does have a traffic cop aspect to it but it is really about protecting the team and supporting it to be maximally effective using the process. Therefore, some previous project management or team lead experience is helpful, but depending on your personality, not indispensable. If you’re coming from a development role, having actually been a member of a Scrum team is especially helpful because you can use your own experience to inform how you help your team mature in its application of Scrum and Lean-Agile principles.

I knew from the start of my lobbying to implement Scrum that I wanted to take on the challenges of the Scrum Master role. I believed that I had a clear vision of how the role would serve the team and advance the causes of the business. If you’re advocating the adoption of Scrum in your organization this is an important point to consider. If you’re not prepared or interested in stepping into a leadership role then you ought to be certain there’s a good candidate interested and available. The appointment of a Scrum Master is not a requirement that you can ignore, so until you have someone who can fill the role, you aren’t ready for Scrum.

“Plans Are Useless But Planning Is Essential” (Dwight Eisenhower)
Because I’d been a participant in the Scrum process and not the Scrum Master I knew I had to do some reading and prepare a formal presentation to make the case for adopting Scrum. I started with Ken Schwaber’s “Agile Project Management with Scrum.” The book clearly describes the underlying theoretical and practical mechanisms that are the foundations of the Scrum methodology. Moreover, it details realistic scenarios of Scrum in action to help you envision how Scrum might work (or not) in your organization.

Introducing business people to Scrum and Lean-Agile methods with an emphasis on how Scrum will reduce their pain is more likely to succeed then blasting them with its theoretical attractiveness and how it will assist IT.

With my Scrum project development experience and some reading under my belt, I felt I had enough information to make a ‘What is Scrum’ presentation to my colleagues and IT management. But before you start designing your slides, you’ll have to make sure you can get an audience with the appropriate decision makers. If your team is struggling or in crisis, getting the right people in your audience probably won’t be difficult. If your organization is doing “alright” then advocating that there is “a better way” will likely be a tougher sell. Introducing business people to Scrum and Lean-Agile methods with an emphasis on how Scrum will reduce their pain is more likely to succeed then blasting them with its theoretical attractiveness and how it will assist IT.

The slideshow I presented was a Scrum 101 that detailed how a typical sprint is run. In addition, I focused on the tangible benefits of Scrum for all of the interested parties in attendance, so it’s important to know who is going to attend. Management’s chief interest is to know how Scrum can be used to identify and plan the workload such that IT can deliver what the business wants in a timely fashion. For example, how does Scrum handle change and complexity? Scrum’s biggest sale point with respect to planning is that it increases the visibility of choices and consequences in iterative development. You’ll probably find that it takes very little effort to show that by developing smaller, more understandable units of work the development team can estimate more accurately. I emphasized that estimates are still estimates, not guaranteed dates, however, this more granular approach to breaking out work increases the chances communicating a fuller picture of the work effort from the start.

In my presentation I further contended that the shorter development cycles Scrum mandates would afford us the opportunity to change direction more quickly and more smoothly when business priorities changed. Quality could be improved because smaller units of work are generally easier to test. Moreover, in contrast to ‘waterfall’ style development, the time to write the tests is represented as individually estimated tasks. These tasks are such a visible part of the schedule that they are less likely to be the frequently cut corner that testing can be in waterfall style development schedule crunches. Be sure to emphasize the benefits and overall importance of frequent builds and tests when you communicate about Scrum.

I knew from prior discussions with my colleagues that they understood we weren’t adapting well to the rapid changes in our environment. Long weeks were more the norm than the exception and emergencies were part of the routine. Every employee who had the misfortune to live through it told the legendary tale of the hellish month leading up to the product’s prior release. We needed not only to boost our quality but also to recognize what we could accomplish within a given timeframe so we didn’t get overwhelmed. Scrum delivers this kind of predictability. Don’t be shy about exploiting your company’s oral tradition in order to remind your audience that they are vulnerable to the very types of dysfunction that Scrum can help solve.

Scrum isn’t a silver bullet for preventing the business from needing things at the last minute but I argued that creating a pattern of reliable delivery (in shorter increments) with a solid communication feedback loop to the business when issues arose would inevitably increase the business’s confidence that we could and would deliver what they needed when they needed it. Of course, I continued, things don’t always go according to plan but if we’re all one team, one company, isn’t it better for everybody to understand the challenges at hand and figure out how to respond together? In waterfall development, when a crisis arises and the schedule is pushed to the limit there’s precious little honest communication about what doesn’t get done?what corners are cut in testing or code quality to “make the date.” An honest, empirically controlled process enables IT to work with the business to determine the best course of action for the business as a whole under the circumstances. An argument for this type of transparency should be appreciated by anyone who truly cares about the business.

To support my claims that these lofty Scrum and agile concepts could ease everybody’s pain, I presented an example burn down graph of a Scrum project I had worked on (see Figure 1). A burn down graph is a key Scrum artifact that displays the progress of the work for a given sprint. This is the empirical reality of the project and it is the Scrum Master’s responsibility to keep this status information up to date.

Figure 1. A Scrum daily burn-down graph for a 20-day sprint is shown.

The chart shows the number of days remaining in the sprint on the x-axis, while the y-axis shows the number of days’ worth of work remaining to be completed. In Figure 1, the blue line shows the ideal, while the back line depicts actual results. Together, these two plot lines can tell you at a glance how far off the mark your sprint has progressed and whether you are ahead of or behind schedule. The drop down at day 8 indicates that hours of work completed between these days haven’t yet been recorded, i.e., this is normal.

The burn-down graph is a tremendously powerful visual aid to see the sprint’s progress. If the burn-down bumps briefly above the line there’s not much to worry about but if the slope flattens out above the ideal burn-down rate then either new tasks are being added faster than the work is being accomplished or non-sprint work is being performed instead of the work the team committed to complete. This helped the group understand how Scrum can give at-a-glance feedback about your success.

Finally, I described the daily rhythm of Scrum most notably the daily status meetings and the updating of the remaining hours on tasks. My experience with Scrum was to use agile estimating and planning techniques and the manual posting of task-related stickies on the wall. The result is a dashboard that not only displays the team’s workload but serves as a powerful demonstration of the activity in the organization. In my experience, both IT and business management are very impressed with the visibility this provides into testing and development activities. This is another opportunity to emphasize that the transparency Scrum provides enables everybody to work together to make the right decisions for the software and the organization; secrecy serves no purpose.

Lukewarm Reaction?
It turns out that though I thought I was very convincing the development manager hadn’t been very enthusiastic about the presentation. He wasn’t in favor of “diverting resources to estimate and plan” when we could be going heads-down to push out functionality for the business. The obvious enthusiasm of the team to get out of the rut we were in ruled the day, with the majority of the development team urging the development manager to give Scrum a try. Since we started with Scrum this manager has become a true believer in the process. But at the time he was skeptical, so when he approached me the next day, asking “what do we do next?” I had my work cut out for me. Hopefully in your situation you will have more eager adopters but be prepared to help the skeptics along through the early phases of adoption.

There was just one little problem: I knew Scrum could work for our organization and I knew what a reasonable Scrum team looked like in action but how to get there from our current state was a question I hadn’t deeply considered in a practical way. What are the concrete steps to get Scrum up and running? Mercifully, the answers I vaguely intuited are wonderfully explained in vivid detail in Mike Cohn’s “Agile Estimating and Planning.” I picked up my copy and read it in a hurry. I followed my sales pitch with a second presentation, aptly entitled “Concrete Next Steps to Implement the Scrum Process.”

Concrete Steps to Implement the Scrum Process
The high-level view of what it takes to get up and running with Scrum is straightforward:

1. Create a prioritized Product Backlog
2. Hold a story point estimation session
3. Allow the business to revise the backlog’s priorities based on the story point estimates
4. Decide on the length of the sprint
5. Hold an iteration planning session and commit to the package of work that the team believes it can accomplish in the sprint
6. Commit to convene 15 minute daily team status meetings for team members to update everybody on their progress
7. At the end of the sprint, review the sprint and roll out the functionality that is ready to go

The CTO was going to attend this presentation so I worked hard to lay out the practical considerations involved in these points and how it would help our efforts. I also emphasized that any new process takes time to get comfortable with so we wouldn’t be perfect at estimating and planning right away. With that said, I didn’t attempt anything fancy. My prescription of what to do to get going with Scrum followed standard Scrum agile estimation and planning practices, beginning with the Product Backlog.

The iteration planning session is where the rubber meets the road as testers and developers break down a feature into its constituent tasks.

The Product Backlog is the indispensable element of Scrum from which everything else flows. This is the Scrum term for the list of features or stories that the business wants to implement and it is the source of the work commitments made by the development team. Making a firm commitment to getting a particular package of work completed in a sprint is a central tenet of Scrum. Without an up-to-date, prioritized product backlog, the development team has no guidance as to what work to undertake.

Once the Product Backlog was in place, I suggested a story point estimation session, which would give us a sense of the size of the various features being requested. Then the backlog would go back to the business to see if, based upon the relative estimated size of the various features, whether there was a preference to shuffle priorities. For example, perhaps the business would prefer that we knock off a few smaller items before a particular larger feature.

The iteration planning session is where the rubber meets the road as testers and developers break down a feature into its constituent tasks. Once the tasks are broken out and estimated they would be loaded into the Scrum Masters sprint workbook and we could see how the task hours added up. If more work was committed too than looked like it would fit then we would return the sprint to the backlog. If we could get to the work then it would be pulled back into the sprint, otherwise, it would be reprioritized for possible work in the next sprint.

Since the remaining operational activities of the sprint took less explanation and prompted less discussion I went through them pretty quickly. I did emphasize repeatedly that getting up to speed with Scrum would require some time. This gradual improvement notion didn’t ruffle any feathers but perhaps a more critical audience would have grilled me as to how much time and when would Scrum “be working right.”

The CTO was on board with this exercise and we were able to get a quick round trip of the backlog so we could begin our iteration planning. We chose to do a longer iteration for our first Scrum because there were a couple of larger features that we wanted to complete; in hindsight I think that we might have been better off starting with a shorter sprint. The key obstacle to initiating a shorter sprint schedule was the perception that the overhead of estimating and planning meetings was too high. This concern has already diminished as the value of the planning and task break outs has become clear but it was a significant issue at the start.

Achieving a Rhythm
At this point in our maturation as an organization using Scrum (3rd sprint) we’re much more cognizant of what the issues were that prevented us from completing the work we wanted to accomplish in the first sprint. We have a variety of incoming queues of work. It is extremely challenging to prioritize them because the work supports different aspects of growing and stabilizing a rapidly evolving product. Scrum provides a robust and reliable mechanism to see the progress of our efforts and understand the trade-offs that are implicit in the choices the business makes. The metrics that the Scrum workbook provides are already indispensable tools in how the business makes decisions about what it can accomplish. While we’re a few sprints away from achieving “a rhythm” I believe we’re heading in the right direction.