Introduction to Scrum: Benefits and Practices

Posted October 5, 2009 by Kevin Thompson, Ph.D.
Categories: Uncategorized

Scrum is a lightweight agile process framework used primarily for managing software development. Scrum is

  • lightweight because it has few prescribed elements
    • Three roles: Team, Scrum Master (often a Project Manager), Product Owner (often a Product Manager)
    • Three meetings: Sprint Planning, Daily Scrum, Retrospective
    • Three artifacts: Product Backlog, Sprint Backlog, Burndown chart
  • agile because it maximizes responsiveness to changing customer needs
  • a process framework because it is not a process, but a collection of practices and concepts around which a process can be built

For those who are not already “doing Scrum,” the key question is not, “How does it work?” but, “What are the benefits?” This question does not have a unique answer, because it depends on who is asking. Benefits to developers, project managers, and salespeople are different.

This article identifies key benefits of Scrum, and the Scrum practices that produce them.

The Benefits of Scrum

Different stakeholders want different things from a software development process.

  • Developers want to write code, not documents.
  • Quality Assurance engineers want to create test plans that ensure product quality, and have high-quality code to test.
  • Project Managers want a process that is easy to plan, execute, and track.
  • Product Managers want features implemented quickly, with no bugs.
  • Services and Support personnel want to know exactly what is in all product releases, and have a reliable means to satisfy customer requests for bug fixes and enhancements.
  • Sales personnel want to know what is “in the pipeline” for future releases.
  • Customers want all of their feature requests and bug-fixes done quickly.
  • Executives, Program Managers, and PMO personnel want to know exactly what is happening, and what is planned to happen.
  • Everyone wants happy customers.

The list seems long, but the key points are few:

  • Team satisfaction and productivity are maximized when effort spent on non-deliverable items (e.g., internal documentation) is kept to a minimum.
  • Maximizing quality at each stage minimizes re-work at following stages, and maximizes product quality seen by customers.
  • Responsiveness is best achieved by fulfilling customer requests quickly.
  • Everyone who cares should be able to see all relevant information about project plans, status, and history.

Thus the best real-world development process devotes as little effort as possible to deliverables the customer doesn’t value, provides relatively bug-free code at the start of testing, delivers all relevant information to everyone who needs it, and fulfills customer requests quickly.

It is no coincidence that Scrum was designed to satisfy these points.

How Scrum Provides its Benefits

The following sections describe how Scrum practices produce the desired benefits.

Team Satisfaction and Productivity

The “team” consists of the development and Quality Assurance engineers who do the hands-on work of creating a high-quality product. Team members generally find their greatest satisfaction when they can do work that is rewarding.

  • For developers, this means designing and writing computer software.
  • For QA engineers, this means defining the exact criteria for success through the test cases they develop.
  • For all team members, this means producing something they are proud of.

Productivity goes hand-in-hand with eliminating unnecessary work. Scrum addresses team satisfaction and productivity by emphasizing work that is valuable (as a deliverable) and rewarding (to the team), and de-emphasizing what is not (non-deliverable artifacts).

In practice, “non-deliverable artifacts” usually consist of internal documentation about product requirements and design, which customers do not see or value. Scrum projects do require some written documentation, but minimize it by relying as much as possible on real-time communication between people. Thus a Product Manager will write brief requirement descriptions (called “Stories”), and elaborate on the details as needed in discussions with team members.

The requirement for effective real-time communication means that one of the following must be true for all team members, Product Managers, and Project Managers (in order of decreasing desirability):

  1. All are in the same building
  2. All are in the same city
  3. All are in time zones that overlap at least four hours per day
  4. All are willing to spend hours per day outside normal working times (e.g., transoceanic teams).

The last three cases can only be made to work if real-time teleconference and Web-conference capabilities are available on demand.

Maximizing Quality

Teams implement Stories to the requirements, in a very literal sense: An implementation is not complete (a story is not “done”) unless it satisfies the requirements, as defined in the test cases. While test-driven development is not required for Scrum, test cases do define whether the requirements have been met, and no story is complete unless it passes all of its test cases. If bugs arise, developers fix them until the tests succeed.

This practice ensures that each Story implementation is bug-free, with respect to the requirements, at the time of its completion. It does not prevent regression bugs, so additional testing is necessary after all development is frozen. However, the quality of the product going into regression testing is higher than is the case for products going into the final test period for waterfall projects, and high quality ripples through all stages of the process.

Maximizing Responsiveness to Customers

Responsiveness means providing turnaround to customer requests in a manner that is consistent with customer priorities. Since instant turnaround is not possible, the next best thing is to respond quickly to high priorities, and less quickly to low priorities.

The only way to deliver any new feature or bug-fix quickly is to work in short development cycles, which is why the basic unit of Scrum development, the “Sprint,” is typically 2-4 weeks in length. Longer cycles, composed of two or more Sprints, are also common and often referred to as “Releases” (which is not a Scrum term).

Productivity and job satisfaction both require that people are productively employed, not sitting idle, which means that parallel work for team members is the norm. The two strategies for parallelizing work on a set of Stories are

  • Parallel work on serial Stories. The whole team collaborates on one Story, until completion, then begins work on the next.
  • Parallel work on parallel Stories. Each team member works on a different Story, until completion, then starts on another one.

Since Sprint lengths are “time boxed” (have rigidly-enforced durations), and unexpected problems can occur, it is often not possible to complete all work planned for a Sprint. For this reason, it is critically important that Story development be serialized as much as possible. This allows us to deliver, say, eight of ten planned Stories when only 80% of the expected work can be completed. In contrast, the parallel-Story strategy might produce no completed Stories at all in this case, and deliver zero value to customers.

The need to serialize Story development implies another important Scrum concept: Ranking. The set of Stories planned for a Sprint is called the Sprint Backlog, within which Stories are ranked (sequenced) for implementation. The Product Manager (say) is responsible for ranking the Stories, so that the most important ones are done first. (The Sprint Backlog is a subset of the larger Product Backlog, which contains all un-implemented requirements.)

The combination of short development cycles and ranking of requirements maximizes responsiveness to customer needs.

Providing Transparency

“Transparency” means that all steps, inputs, and outputs of the development process are visible-but to whom?

In the narrow sense, as typically described in books on Scrum, transparency applies to the internal membership of the team, the Scrum Master, and the Product Owner, as they need to know the status of the project every day. In this case, and for co-located teams, transparency may be provided by posting index cards or sticky notes with the current Story and task status, along with the current burndown chart, in a public location. The Scrum framework essentially guarantees this level of transparency.

(A “burndown chart” is a bar or line chart showing, each day, the amount of this Sprint’s planned work that remains to be done. The ideal progress is indicated by a diagonal line, trending down to zero on the last day, against which the actual state is compared.)

Transparency in the wider sense means that every stakeholder who has a need for project status information has immediate access it. “Status information” includes not only the status of the current Sprint, but the content of past Sprints or Releases, and the Product Backlog. The Scrum framework does not provide a standard practice to meet this need, but it provides excellent an excellent foundation for meeting it.

Transparency for stakeholders and distributed teams can be achieved via agile project-management applications (e.g., Rally or ScrumWorks), to which all team members and stakeholders are given access. These applications store all requirements and task definitions, track work status, and provide sophisticated reports. They enable distributed teams to collaborate, and allow stakeholders to query for the information they need, without adding a burden on the team or Scrum Master.

Conclusion

Scrum is designed to optimize team satisfaction and productivity, product quality, responsiveness to customers, and transparency for stakeholders. The key practices that enable these benefits include de-emphasizing work on non-deliverable items, implementing and finishing each Story in a Sprint Backlog in rank order, working in short Sprints of 2-4 weeks, and making past, present, and future project information available to all stakeholders.

Advertisements

More on Kanban versus Scrum

Posted September 30, 2009 by Kevin Thompson, Ph.D.
Categories: Uncategorized

David Koontz sent me a fun (and funny) take on Kanban versus Scrum.

Enjoy!

http://lizkeogh.com/2009/09/16/scrum-vs-kanban-fight/

Also, Roderick Lim Banda has produced a good article comparing several approaches to project management, and mapping them to different project attributes which they best address. See his thinking at

http://www.cioforum.co.za/publiccioforum/topic_026.htm

What is a ‘Scrum Nazi?’

Posted September 24, 2009 by Kevin Thompson, Ph.D.
Categories: Uncategorized

My colleage Tarang Patel brought this term to my attention, and I find it fascinating. What, exactly, is a ‘Scrum Nazi?’

Not having heard the term in daily use, I can only speculate, but I infer that a Scrum Nazi is a fanatic who demands rigid adherence not only to a particular Scrum process, but to an ideology of Scrum that permits no disagreement regarding its superiority over all other project-management philosophies.

Every ideology has its fanatics, so it shouldn’t be surprising that this is true of Scrum, but I find something ironic about a rigid orthodoxy based around a lightweight framework that deliberately under-specifies how software development is to be managed.

I’ve never met a true Scrum Nazi in person, but a discussion with some people at one company some time ago made clear to me that a “Scrum uber alles” mindset does exist.

These folks, many of whom had a strong background in Scrum, were in the process of setting up a new office. They had put together a set of requirements for the office, and a to-do list for various tasks that needed to be accomplished to complete the move.

The odd thing, to me, is that they discussed planning the office move as a Scrum exercise, complete with user stories, epics, and release plans.

Why is this odd? It’s odd because Scrum is designed for cyclic development, wherein teams provide useful increments of new functionality (which have immediate value) for a product at short, frequent intervals. The schedule for Scrum projects is fixed, but the scope is allowed to change in order to meet the schedule.

In contrast, there is no product as such for an office move. Also, the work has a fixed scope that must be achieved, and is neither cyclic nor incremental in any useful sense. Finally, the schedule, while important, has more “give” in it than does the scope.

In short, an office move is an inherently waterfall-style project, not a Scrum-style project.

I mentioned these points to the folks at this company, in as mild a fashion as I could. While everyone was polite and civilized, it became clear that there were no points of agreement to be reached.

My attitude towards project management is that one should use the approach that makes the most sense, rather than apply the same approach to all projects. I suspect that the Scrum ideologues (surely a nicer term than Nazis) feel as they do because Scrum is the only technique they’ve seen used, successfully, on software projects, and have often seen waterfall approaches fail. To me, this is an example of learning the wrong lessons, in a way that leads to a case of, “If you only have a hammer, all problems look like nails.”

I love Scrum, and believe in it deeply for managing most software projects. However, I wouldn’t plan an office move, or a fancy dinner party, with Scrum.

I’d like to hear about your experiences with Scrum ideologues, and mis-matches between project characteristics and project-management philosophies that you’ve seen. Are these things common? I suspect the answer is “Yes,” but would like to know.

Kanban versus Scrum

Posted September 14, 2009 by Kevin Thompson, Ph.D.
Categories: Uncategorized

Once upon a time, “Agile” was a new word. Somewhat later, “Scrum” was a new type of agile development. Now I’m reading more about “Kanban” as a new(er) type of agile development.

Henrik Kniberg has an interesting comparison of Kanban vs Scrum on his Web log. He does a very nice job of summarizing the difference. If I were to summarize his summary, I would say that Kanban essentially replaces the concept of time-boxing as the main constraint mechanism with that of limiting simultaneous tasks in a particular workflow state.

Scrum Sprints are planned, through collaboration between the Team, Product Owner, and Scrum Master. This planning is time boxed, just as the Sprint itself is time boxed. Given a particular team size, the execution of the Sprint is constrained by the duration of the Sprint, with requests implemented in rank order.

Kanban work is not time boxed. Instead, the team works through a steady stream of requests, prioritized as appropriate. The constraint is on the maximum number of simultaneous requests allowed per workflow state. Thus the team might have a limit of two “In Process” requests at any time.

My take-away is that Kanban and Scrum are both Agile.

I like Scrum more from the planning perspective, because it entails more planning (albeit short term). Like it or not (and most engineers don’t like it!), stakeholders outside the Scrum teams do want to have some concept of “plan” or “schedule.” The business as a whole has valid needs for such things.

I like Kanban more as a process for handling a stream of unpredictable requests, such as in tech support departments. Kanban’s emphasis on “pull” and absence of time-boxing appear well-suited for the interrupt-driven life style of tech support.

Scrum processes can handle tech support issues, but not instantly. Kanban processes can handle feature development over time, but provide less of a safety net in terms of working to a plan and having due dates.

That’s my take on Kanban versus Scrum. What’s yours?

Daily Scrum Meetings for Distributed Teams

Posted September 8, 2009 by Kevin Thompson, Ph.D.
Categories: Uncategorized

Introduction

The “Daily Scrum” meeting is a core practice in Scrum, and one of only three schedule-related practices (the others being the Sprint Planning and Retrospective meetings).

Scrum emphasizes the need to minimize overhead, since overhead takes time away from development. Team meetings entail significant overhead, since they pull all team members away from productive work. For this reason, we expect team members and others to collaborate as necessary, meeting informally two or three at a time, to resolve questions and issues.

However, informal collaborations don’t provide a common awareness of the project status across the team, and increase the likelihood that critical issues may not be handled quickly. For these reasons, Scrum prescribes a Daily Scrum meeting for the whole team, but keeps the meeting short.

The Ideal Daily Scrum

The Scrum Master facilitates the Daily Scrum meeting. His job is to get the team and Product Owner together, and get from each team member three pieces of information:

  1. What I’ve done since the last Daily Scrum
  2. What I plan to do before the next Daily Scrum
  3. What issues I know of that require assistance from someone else to resolve

The purpose is not to resolve issues in the meeting, but to acquaint everyone with the current status of the project, and to call out the need for collaboration to resolve issues. Issue resolution occurs after the meeting, when the people involved get together for the purpose.

An experienced team of six people can easily complete a Daily Scrum meeting in less than fifteen minutes.

Daily Scrum Meetings for Distributed Teams

Daily Scrum meetings are more difficult to arrange when team members are not co-located. Distributed Scrum meetings require teleconference facilities, including phone conference (at a minimum), Web conference, and video conference (if possible).

In the simplest case, a distributed Daily Scrum meeting is identical to the local version, except that the communication occurs over the teleconference system. Unfortunately, two factors can conspire to make Daily Scrums difficult:

  1. Time-zone differences
  2. Language differences

Coping with Time-Zone Differences

Time-zone problems are minor if the outlying participants have at least two hours of overlap in their standard work days. For mixed East-Coast / West-Coast teams in the US, for example, the time difference is three hours, and team members have five overlapping work hours in which to schedule meetings.

Trans-oceanic teams have more difficulty. Teams split across two sites separated by more than eight time zones have no overlapping hours, and there is no convenient way to arrange a Daily Scrum meeting. The practical ways to handle this are

  1. Pick a time that inconveniences one site (usually, the one with fewest members)
  2. Have separate Daily Scrums for sites, with Scrum Master recording both
  3. Replace short Daily Scrums with longer twice-weekly status meetings

The first option is the simplest, and most straightforward. The problem is that it makes life hard for part of the team every day.

The second makes life easier for most members, but jeopardizes the common awareness and quick response to issues.

The third also makes life easier for most members, and may be unavoidable when the difficulty of getting to the meeting is significant for some members, but it also jeopardizes quick response to issues.

None of the alternatives is attractive, because there is no attractive way to collaborate closely with people who work several thousand miles away. It is better to avoid the problems by having team members co-located, or at least with some common working hours.

Coping with Language Differences

Daily Scrum meetings become impossible if team members share no common language. Consider the case where members in a US “headquarters office” speak English, while those in a “branch office” in China may not all speak English. Even those in the remote office who do speak English often read and write it better than they speak, and may not feel comfortable enough to speak in meetings.

Recommendations for dealing with language differences include

  1. Have a local facilitator at the remote office who speaks both languages, and guides or interprets as necessary
  2. Have all team members submit their three pieces of information by writing (e.g., email, Wiki) in advance, for review and discussion at the meeting

Conclusion

Distributed Scrum can work, and distributed Scrum meetings can work, provided that enough care is taken to cope with time-zone and language differences. It is important to weigh the impact on communication and morale against expected benefits before making a decision to set up distributed teams.

Welcome to Deep Scrum

Posted September 8, 2009 by Kevin Thompson, Ph.D.
Categories: Uncategorized

My name is Kevin Thompson, and this is my Web log about the Scrum framework for agile software projects.

I have a doctorate in physics, and certifications in project management and Scrum, so I take a very quantitative and scalable approach to Scrum. I am fascinated by the mathematics of Scrum, and how its basic concepts arise in a natural way from the fundamentals of project management.

I manage Scrum projects, teach Scrum to teams and project managers, and lecture on Scrum and software project management (email for details).

Kevin Thompson, Ph.D.

Project Management Professional
Certified Scrum Practitioner
Certified Scrum Master