The Lean of Scrum

By David Starr. David Starr is Chief Software Craftsman for Scrum.org where he focuses on improving the profession of software development. He also founded the online technical community, ElegantCode.com.

July 2012

Inspect the inherent Lean qualities of the Scrum framework along with various ways to help Scrum Teams improve using Lean Thinking.

Applies To

Team Foundation Server

Overview

Seeing Scrum Through the Lean Lens

Toward Leaner Scrum

Conclusion

Current discussions about agile software development invariably include Scrum, Lean, and Kanban—three tools for planning, monitoring, and executing software development activities. These tools are often compared and contrasted by some agile practitioners who proclaim that the Scrum Framework and Lean Thinking work well together while others see these tools as fundamentally different ways of delivering software.

Overview

Scrum is terrifically popular; of teams claiming to use agile development methods, 92% report using Scrum[1]. Having sampled the success Scrum enables, many teams look to mature their practice beyond the basic Scrum Framework. This article explores extending the Scrum Framework with Lean and Kanban techniques, with a mindset of Kaizen, or Continuous Improvement.

Scrum

The Scrum Framework, introduced in 1995 by Ken Schwaber and Jeff Sutherland, is a way for teams to work together in delivering software iteratively and incrementally. Scrum Teams organize work into time boxes called Sprints, which last one month or less, resulting in a set of complete and working functionality in each Sprint.

The Scrum Framework is simple to understand, and has become immensely popular with software development teams and their customers. Scrum promotes cross-functional and self-organizing teams that focus throughout the Sprint to deliver an Increment of working and potentially releasable software.

Scrum is codified in the Scrum Guide, which documents Scrum’s roles, artifacts, and events. The Scrum Guide is maintained by Scrum’s creators and is available online at Scrum.org.

Lean

Lean Thinking is a way of approaching system optimization focusing on reducing waste and improving overall flow of value through a system. Lean has a rich history in manufacturing and has gained popularity in software development circles in recent years.

When applied to software development, Lean Thinking is embodied by the following seven principles, first published in the book, Lean Software Development: An Agile Toolkit[2].

1. Eliminate waste

2. Amplify learning

3. Decide as late as possible

4. Deliver as fast as possible

5. Empower the team

6. Build integrity in

7. See the whole

Applying these principles to the work of delivering a software product is not an end goal. One is not said to "Do Lean"; rather one uses Lean principles to guide decision making and to choose techniques that will improve a system overall. For example, the practice of TDD (Test-Driven Development) builds integrity in to software by inspecting it at the point of creation, thus supporting the Lean principle of building integrity in during the creation process.

Kanban

One technique with roots in Lean Thinking is Kanban[3], which uses Lean Thinking in a formal method focusing on reducing waste, just-in-time delivery, and avoiding overburdening those doing the work. Unlike Scrum, Kanban is not an iterative and incremental method; instead of building on iterations Kanban builds on five core activities.

1. Visualize the workflow

2. Limit Work in Progress (WIP)

3. Manage flow

4. Make process policies explicit

5. Improve collaboratively

Different teams using Kanban often have very different processes. The Kanban method is simply a set of techniques for managing a process, and then optimizing it deliberately. Kanban is easily applied to processes already in place, including Scrum.

Scrum And Kaizen

Once Increments of working software are consistently delivered with each Sprint, Scrum Teams seek new ways to improve their practice. The heart of effective Scrum is Kaizen, the mindset of continuous improvement. Healthy Scrum Teams almost certainly use a myriad of practices in their focus on Kaizen. Tools and techniques like relative estimation, test-first development, build automation, and pair programming are all right at home in Scrum Teams.

Not only do other tools, techniques, and practices work well in complementing Scrum, but there is a Scrum extension model described and managed at scrum.org. This extension model to Scrum encourages community involvement in documenting practices that compliment Scrum and work well with the framework. At the time of this writing, several extensions have been proposed specifically applying Lean practices within Scrum.

Advantages of applying Lean Thinking to Scrum are undeniable. Not surprisingly, many Scrum practitioners have realized greater performance and quality by applying Lean Thinking to their Scrum practice.

Seeing Scrum Through the Lean Lens

The Scrum Framework consists of the following roles, artifacts, and events. If you are unfamiliar with the basic Scrum Framework, read the Scrum Guide before proceeding.

Roles	Artifacts	Events
Product Owner Scrum Master Development Team	Product Backlog Sprint Backlog Increment	Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective

The Scrum Guide sets forth rules for how these components work together, but Lean Thinking provides a framework to further optimize the interplay of Scrum’s roles, artifacts, and events. Scrum Teams select a subset of the Product Backlog to deliver each Sprint, and focus on delivering an Increment with appropriate quality and functionality. Lean Thinking can help in smoothing the flow of work throughout the Sprint and reducing waste of the overall value stream.

Both Scrum and Lean strive to keep quality high, which is necessary to the success of the overall work being performed. To see principles shared by Lean Software Development and Scrum in action, simply analyze Scrum’s roles, artifacts, and events through the lens of Lean Thinking.

Events

With the exception of the Sprint, which is a container for all other events, Scrum events are really just meetings. Lean thinking generally regards meetings as waste, and waste is to be diligently eliminated.

This could lead one to conclude that Scrum events are unnecessary. However, each event in Scrum is carefully designed to eliminate other meetings which would otherwise occur in an interrupt (or ad-hoc) manner. Well executed Scrum events result in fewer meetings and less time spent responding to unplanned interruptions.

Each Scrum event is designed to inspect something and adapt something. The inspection supports Lean’s principles of amplifying learning and building integrity into the process of creation. Adapting a plan, requirement, or other artifact during a Scrum event supports Lean’s principles of deferring decisions and seeing the whole. The following table shows Scrum events and what is inspected and adapted during each.

Event	Inspected	Adapted
Backlog Grooming	Product Backlog	Product Backlog
Sprint Planning	Product Backlog Previous Increments	Sprint Goal Sprint Backlog
Daily Scrum	Sprint Backlog Progress toward Sprint Goal	Sprint Backlog Daily plan
Sprint Review	The latest Increment The latest Sprint Product Backlog	Product Backlog Other long-term plans
Sprint Retrospective	The latest Increment The latest Sprint Scrum Team itself Technical Practices	Scrum Team behaviors Technical Practices Work management practices used within Scrum

Artifacts

Scrum artifacts are meant to be as simple as possible and no simpler. The requirements, plans, and even the software delivered by a Scrum Team are most valuable when they include only the details needed to get the job done.

Product Backlog

In a perfect world, there would be no need to create requirements beyond people simply talking. The person requesting the software would ideally be inherently understood by those creating it, and no intermediate expression of the requirement would be needed. While possible in very small teams with close customer relationships, this simply does not scale. Creating requirements in advance of delivering features is necessary for planning. Lean sees requirements as inventory, a common waste in Lean Thinking, and thus something to be minimized.

In Scrum, requirements are managed in the Product Backlog, which prescribes very little form or structure. There is no requirement that Product Backlog items be highly detailed or perfectly expressed.

While maintaining a Product Backlog and requirements are necessary to plan work, the perfect usage is to create and refine Product Backlog items just a little ahead of the Development Team actually working on them. Efficient Scrum Teams avoid creating requirements in the Product Backlog that may never get worked on.

Sprint Backlog

In a perfect world, there would be no need to plan. A Development Team might simply take the next feature request from a queue, ignoring the context and cost of the requirement. While this simple model of processing work is very flexible, it fails to consider that software development is an inherently complex endeavor. Product Development of significant complexity benefits from having a plan, even if that plan is simple and lacks details.

The Scrum Guide defines the Sprint Backlog as the subset of Product Backlog items selected for a Sprint, and a plan for delivering them. The Sprint Backlog shows an inventory (waste) of projected work for the Sprint, which gets refined at least daily. This daily refinement ensures the plan is never a promise and allows the Development Team to defer implementation decisions until the latest responsible moment.

Scrum Teams build requirements and plans that are barely sufficient, to minimize their cost. This Lean approach to minimizing inventory allows for deferred decision making and empowers the team to self-organize within the Sprint. Rather than focus on the requirements or the plan, Scrum Teams focus on the value being delivered in each Increment.

Increment

Each Sprint includes delivery of at least one Increment of working software. The product Increment is the only Scrum artifact not considered waste by Lean Thinking. Even so, the product Increment can have waste in it. Waste may be present in the form of unused features, defects, incomplete functionality, hard-to-maintain code, or poorly factored designs.

High-performing Scrum Teams ruthlessly eliminate waste in the product itself. Often, this is done by inspecting Increments frequently throughout the Sprint and keeping quality high at all times. This realizes the very essence of the Lean principle of building integrity in.

Scrum Teams also benefit by keeping Lean principles in mind when delivering the Increment. The Scrum Framework itself ensures the Increment is open for inspection at Sprint Review. Receiving feedback on the Increment at Sprint Review is fundamental to amplifying learning.

Roles

The roles prescribed by Scrum are carefully balanced to empower the Scrum Team and balance the tensions within it. Scrum Masters, Development Teams, and Product Owners work collaboratively to succeed, which requires everyone involved to see the perspectives of the others. This collaboration ensures that Scrum Team members see the whole of the Scrum system and makes transparent any decisions which would sub-optimize the Scrum Team by favoring any one role over the others.

Scrum co-creator, Jeff Sutherland, notes the basis of successful Lean implementation is bottom-up intelligence and empowered workers with facilitating managers. Scrum’s self-organizing Development Teams embody the empowered employees from Lean Thinking who are able to drive learning up in the organization rather than have it dictated to them.

Unique to Scrum is the role of Scrum Master, which the Scrum Guide describes as follows:

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.Scrum Guide - October, 2011

One of the chief skills and activities of good Scrum Masters is facilitation. In most cases, Scrum Masters facilitate Scrum events. Scrum Masters are managers, albeit of Scrum adoption and adherence, not people.

Toward Leaner Scrum

Using Lean Thinking to consider and address issues exposed by Scrum often yields high returns and is a great way to sustain a Kaizen culture. Scrum Teams are still learning how to apply Lean to Scrum, but many practices are gaining popularity because they have proven to make Scrum Teams more effective.

There are many common practices and techniques used in knowledge work which directly support Lean principles. Several of these techniques are explored below with an eye toward how they might be realized in a Scrum Team.

What follows is certainly not an exhaustive list of techniques, but simply examples of how some Scrum Teams might improve using techniques common to Lean practitioners. Further, each technique can be applied in numerous ways. Only a few Lean techniques are described here. Scrum Teams may approach the following scenarios differently than described in this document.

Eliminating Waste

Perhaps the most fundamental Lean practice is the elimination of waste. Lean considers waste anything not strictly needed to produce the desired outcome. Common wastes in software development include:

1. Unused code or features

2. Defects that lead to re-work

3. Delays or time spent waiting for something

4. Handoffs from one person, team, or business process to another

5. Highly detailed requirements

6. Insufficient requirements

7. Slow or poor communication

Some waste simply cannot be avoided and is even necessary. In the strictest definition, for example, requirement documents are waste. An index card representing a requirement is not delivered to the client, after all. Therefore the index card is waste. The requirement card is not itself the product feature; it represents work that must be done to create the feature. The requirement card exists to help developers think through and keep track of their work. While most teams see this as a necessary practice, it is easily identified as waste.

While some waste is necessary, much of it can be reduced, optimized, or even removed. Some waste in the software development value stream, such as waiting too long to check in code, is easily recognized and eliminated. Other waste found in software development teams, such as creating large requirements documents before development may begin, is ensconced as culture and requires significant effort and time to fundamentally change.

Scenario

Scrum has been in place for six months. The Development Teams are producing working Increments of software with each two-week Sprint and all measured quality indicators trending positively.

Lean Approach

The Scrum Masters meet to discuss coaching their teams toward higher productivity and quality. A Scrum Master suggests eliminating waste as prescribed in Lean Thinking. Agreeing to try the idea, the Scrum Masters look for examples of waste and categorize them into two lists - those that can be eliminated immediately and those requiring time to manage.

The first list contains waste to be eliminated either by the Scrum Masters themselves or by the Development Teams and requires no permission or waiting. The other is labeled "Waste Backlog" and identifies waste that all agree is present but will take significant time or effort to change. Examples of the two lists are shown below:

Deal with Immediately

Waste Backlog

Some builds are being performed manually on a build machine that must be maintained especially for this purpose. Website packaging is a manual ZIP process. Automate this. Developers are all using a shared development database and data changes are frequently interrupting development flow. Move to a model where each developer has a dedicated development database. Tests are not written until a feature exists. Encourage and teach test-first practices for test specialists.

UML models created prior to coding for all features. Communication impeded by office layout which requires members of the same Development Team to walk between offices for small, ad-hoc discussions. Introduce installers where possible so that deployment is not manual in operations. Many fields in the Bug Tracking report system are required and rarely used. Time spent creating data for these fields can be saved by making them optional.

Armed with these lists, the Scrum Masters approach their respective Scrum Teams with actionable suggestions for immediate improvements. Although Scrum Masters coach their teams to higher levels of quality, the self-organizing nature of Scrum Teams requires the teams themselves to value the changes and create a plan for enacting them.

The Sprint Retrospective is a dedicated forum for sharing ideas for improvement and for gaining support to enact them. Effective Sprint Retrospectives often result in plans for enacting improvements, supporting a Kaizen culture. Eliminating or improving waste tracked in the backlog may require work outside the Scrum Team. This is the responsibility of the Scrum Master whose job includes improving the use of Scrum and encouraging agility throughout the organization.

Limiting Work in Progress

Scenario

A Development Team with five members has been using Scrum for 12 weeks, completing three four-week Sprints with mixed results. While the Increments being produced have higher quality than the software created prior to implementing Scrum, less work seems to be getting done and the Development Team members still are not working collaboratively. The Daily Scrum provides a daily reminder that each person on the team is working in isolation on his or her own tasks, although the situation does not seem to be improving.

During Sprint Planning, the Development Team creates a "To Do" list of the work required to deliver each Product Backlog item selected for the Sprint. This technique creates a Sprint Backlog during Sprint Planning, and a mechanism for tracking the Development Team’s progress throughout the Sprint.

The Development Team uses a visible task board on the wall in the Development Team work area to track its progress throughout the Sprint. During the last Sprint, the Scrum Master took photos of the board each day before the Daily Scrum. Some of the photos are shown below.

Day 1	Day 4
Day 9	Day 14
Day 17	Day 20

The Scrum Master shared these photos with the Development Team. Some things were readily apparent, such as:

• More tasks are regularly in progress than there are members on the Development Team.

• On day two, a developer pulled all the tasks for Feature C into the "In Progress" state and left them there for the duration of the Sprint.

• Feature B did not get worked on until the end of the Sprint and was not completed.

• Feature C was worked on throughout the Sprint but was not completed. The developer working on Feature C was frustrated by a lack of help when unfamiliar issues arose. Despite her subtle hinting at the Daily Scrums that she would appreciate some help, it never materialized because other team members were focused on their own work and did not feel responsible for Feature C.

• Features were placed in the Sprint Backlog in priority order during Sprint Planning and the Product Owner was extremely disappointed that Feature B was not completed in the Sprint, as it was ordered higher than other features which were delivered.

• Several features were in progress at once, causing very different parts of the code to change all at the same time. During the Sprint, this led to several build failures and rework as developers unknowingly impacted each other’s code.

All of these observations point back to the Development Team’s practice of working on many things at one time. Switching attention between tasks and trying to focus on many items simultaneously resulted in Development Team members feeling overloaded and overwhelmed by the work in the Sprint Backlog. Accordingly, each team member focused on her own work and acted as an individual rather than as a member of a team.

Lean Approach

During the Sprint Retrospective, the Scrum Master explained the idea of limiting WIP to the Development Team who decided to try the technique. The Development Team decided to implement three new rules designed to reduce WIP in the next Sprint:

1. Features in the Sprint Backlog are implemented in order from top to bottom.

2. No more than 3 items may be in progress at one time. If a fourth item is put in progress, the team will pause to determine why there is a bottleneck occurring in the system.

The Scrum Master took pictures again throughout the next Sprint. Several of the photos are represented below.

Day 2	Day 8
Day 12	Day 20

During the Sprint Retrospective, the photos were again shared with the Development Team who made the following observations about how things had changed for them during this latest Sprint:

1. Development Team members worked together on more complex items. Although opinions sometimes differed on how to do the work, differences were resolved and the team made faster progress overall.

2. Development team members began learning about product functionality on which they had not previously focused. Each reported a feeling of collective ownership for the product as a whole. This stood in stark relief against the previous practices of individuals focusing only on features they understood.

3. The complexity of coordinating changes in many different areas of the code at once was dramatically reduced. So much so, in fact, that the Development Team’s productivity notably increased.

4. Although Feature E was not completed within the Sprint, all the features that were delivered were of higher priority than Feature E. The Product Owner was delighted and decided to ship the Increment to the client even without this low priority feature.

Although creating a Sprint Backlog during Sprint Planning limits the batch size of work selected for the Sprint, further limiting WIP within the Sprint can lead to faster throughput and higher productivity. Limiting WIP during the Sprint also increases collaboration and reduces the risk of having technical specialists whose work is not understood by others.

Reducing Wait Times

A lot of time is spent waiting for things to happen in software development. This form of waste is easily found in most Development Teams. New Scrum Teams find themselves waiting on numerous things during a Sprint, including:

• Permission to do something

• A long process to complete

• A hand-off from another team or individual

• Tests to be run or validation to be completed

• Access to a needed resource

• The cooperation of a person outside the team

Worse than inefficiencies of waiting Scrum Teams is the time customers and businesses spend waiting for software to be integrated, packaged, and shipped. This problem grows with the size of the development organization. As more developers or teams are added to a project, the cost of integrating their work into a single product increases.

The longest wait time built into Scrum is the Sprint. Being the container for all Scrum events, the only requirement of Sprint duration is that it be one month or less. This limits the time spent waiting for a working increment of software to no more than one month. Most Scrum Teams deliver working Increments even more frequently.

Scenario

A company has six Scrum Teams working on a large and complex software product. Each Scrum Team focuses on a specific feature area and work is coordinated via a master Product Backlog. Sprints are three weeks long and include integrating the work of all Development Teams.

Previously, Sprints were two weeks long, but as the product grew so did the complexity of creating it. New Scrum Teams were added which needed more time to integrate their work, so the length of Sprints was increased to accommodate the integration activities.

Week three is now known colloquially as Integration Week. Integration of new features into the main code line is the primary activity during this time. An Integration Team is established each Integration Week with representatives from each Development Team. They direct the work of integration activities.

The Integration Team does not accept new features during Integration Week, although they do request small changes to address integration issues. This causes a flurry of ad-hoc code changes during Integration Week in response to the needs of the Integration Team.

The following graphic shows typical configuration management during a Sprint. Development Teams create their own development branches at the beginning of each Sprint. They merge their code at the end of week 2. During week 3, Development Teams service the requests of the Integration Team as needed.

While integration during the Sprint is necessary, one third of the capacity of the six Scrum Teams is currently being used to accomplish the integration. During that time, much of the capacity of the teams is spent on activities outside the Sprint. Note that in the example above Team 5 had no work at all during Integration Week.

Increasing the cost of Integration Week is the flow disruption in the Scrum Teams who must often switch context. Some teams are privately branching and forking code lines in attempts to stay productive throughout the week, increasing overall complexity and subverting the transparency required to make good decisions.

Lean Approach

The Scrum Masters for the teams meet to discuss options. One Scrum Master relates her team has been largely successful in limiting WIP during the first two weeks of each Sprint. The Scrum Masters observe that if every team limits WIP to one feature at a time, it could potentially integrate its work as each feature is completed.

If this practice were used across all Development Teams, no team would wait until the end of week two to ingrate their work. Instead of waiting to integrate new features, each team could now consider integration to the main code line part of the Definition of Done1 for each feature on which it works.

The Definition of Done is a concept in Scrum in which Development Teams agree on what must be true for each Product Backlog item selected for the Sprint in order to consider that Product Backlog item "done". For more about the Definition of Done, see the MSDN article Done and Undone.

During the next Sprint Retrospectives, the Development Teams agree to try integrating their work as each feature is completed. They establish and commit to the following new rules:

1. Each Development Team limits WIP to one feature at a time.

2. A feature is not complete until it is integrated in the main code line.

3. Before starting to work on a new feature, Development Teams will update their code lines with a fresh copy of the main line.

The resulting activity is represented in the following graphic:

The new rules have caused the teams to experience smoother flow in the delivery of features. Development Teams are no longer required to sit idle and disrupted during week three of the Sprint as there is no Integration Week.

The time taken to integrate changes during the Sprint is higher at first but as the Continuous Integration model becomes more familiar, the productivity of each Development Team increases. Over time, the features added per Sprint increase.

Because being done with a feature now means that feature is integrated into the main code line, there is no longer any question of whether a feature is really done. The Definition of Done now includes integration to the main code for each individual feature. The risk of failing to integrate is dramatically decreased.

Finally, the decision to reduce the time a Development Team must wait to integrate code has increased the overall productivity of the Development Teams and made the need for Integration Week obsolete. Thus the Scrum Teams may go back to shorter Sprints, enabling the Product Owner to ship even more often as appropriate.

Deferring Commitment

Deferring commitment is one of the original Lean principles expressed as a value of Lean Software Development. This principle is often described as "waiting until the last responsible moment" to make a decision.

There is little to no value in making a decision that prematurely commits one to a course of action, so the thinking goes. Why not wait until the decision must be made, so the most possible information about the issue will be known? This limits the risk of making the wrong decision and allows time for even more choices or paths of action to surface.

Scenario

During Sprint Planning, the Development Team creates detailed plans for how to implement the PBIs selected for the Sprint. Often, the plan changes during the Sprint as more information is learned. They notice that when the work is less clear, the plan changes even more. Knowing that unused requirements are waste, the team would like to avoid this planning rework.

Committing to one course of action requires discarding other options. This often causes those aware of the commitment to discard ideas. There may be several ways to implement a given feature but when a course of action has already been chosen, developers may stop considering other ways to approach a problem and the potential for innovation declines.

Lean Approach

The Development Team decides to allow larger and less defined items in the Sprint Backlog. In fact, they decide a Product Backlog item may be accepted into the Sprint without a detailed plan at all.

The Development Team now waits to create the detailed plan later when more is known. For them, this means breaking the large Sprint Backlog item into smaller pieces when the work is actually beginning or underway. This defers detailed planning until it is actually needed and allows the team to change its mind about implementation closer to the point of work. It also ensures using the best possible plan rather than executing a plan that may no longer be valid.

This results in better understanding of implementation options when the time comes to implement the feature. The Development Team has learned more about the product during the time it implemented previous features in the Sprint, and has allowed time for investigation if needed.

Visualizing Workflow

The first step in the Kanban method requires visualizing the actual workflow used by a team. This realizes Lean’s "see the whole" principle and requires that the actual workflow be shown, not an idealized version prescribed by a business process document or some other pre-existing model. A useful visualization represents what actually occurs.

Once work visualization exists, work may be tracked within it. A sample model of a typical stage-gated, or waterfall, development process is shown below with several features in progress.

Scrum Teams have been using workflow visualization for years to see the work of the Sprint. The most common form of workflow visualization in Scrum Development Teams is the Scrum "Task Board" or simply "Scrum Board". This visualization is usually simpler than the model shown above, and may look similar to the following model.

This typical form of workflow visualization is strongly influenced by Scrum’s prescription of cross-functional Development Teams. Focus on cross-functional Development Teams is a defining characteristic of the Scrum Framework. A cross-functional team has all competencies it needs to deliver a complete Increment of working software in each Sprint. Team members perform many activities of software development at the same time.

Cross-functional teams may do a little of everything at once as they implement one feature together. This is very different from the plan-driven model wherein specialists focus on doing all of one activity at a time. Further, members of cross-functional teams may have specialties, but all team members regularly work on all activities needed to deliver the software, whether or not the activities are within the individual’s specialty area. Cross-functional software development teams tend to out-perform teams of dedicated specialists.

Scenario

A Development Team is delivering Increments of working software but team members are not collaborating well. Coders are working on problems in isolation before handing code to testers who must rush through validation toward the end of the Sprint.

This leaves little time at the end of the Sprint for testing to occur so the Development Team sometimes skips this and delivers the Increment with incomplete regression testing. Defects are being found in production that would have been found earlier had functional regression testing been allowed to finish.

Lean Approach

The Scrum Master works with the Development Team to model the actual workflow that occurs within each Sprint. Even though the team uses a typical Scrum board at the Daily Scrum, it soon becomes apparent the actual workflow is a stage-gated process. The team produces the following model to reflect its real workflow:

The Scrum Master helps the team understand the potential increase in productivity gained by working in a cross-functional manner. Although dubious, the team members agree to try improving their workflow to be more cross-functional.

The Development Team leaves the visualization intact and uses it to monitor work in the Sprint, but agrees to look for every opportunity to collapse stages. That is, the team looks for opportunities where two stages may be combined into one, thus replacing a handoff with collaboration. They do this a little at a time by making deliberate changes to how individuals within the Development Team work together. At each Sprint Retrospective they revise the model to reflect the improvements made by the team.

First, Arnie and Kyle agree to collaborate on merging the design and coding phases. They try several techniques to improve collaboration and soon learn their workflow has changed to the following:

This Development Team soon learns about creating failing functional regression tests before the code is implemented, resulting in the following changes:

Over the next several months, the Development Team seeks opportunities to reduce the number of stages in the delivery pipeline. The culture of the team actually changes as specialists share their knowledge and everyone pitches in to help work flow more smoothly through the team. Team members begin considering themselves "specializing generalists" as more collaboration occurs.

As collaboration on the team increases, so does collective knowledge about the software being created and the insights of team members into each other’s responsibilities. This collaboration naturally collapses the stages of work during the Sprint and is reflected in a simpler visualization of the workflow that occurs within the Sprint. The Development Team is now cross-functional and views its actual workflow accordingly as seen below.

The team’s iterative reflection on eliminating process stages ultimately resulted in the workflow Scrum prescribes in the first place, a single development phase of In-Progress. This shows how a fully optimized Kanban board ultimately shows itself as a traditional Scrum board.

Building Integrity In

Many techniques of software craftsmanship focus on building integrity into the creation process. Software design patterns, test-first development techniques, refactoring, and pair programming all seek to increase quality of software at the time it is being created. Using techniques that increase quality early in the creation process ensures teams don’t rely on an after-the-fact quality check to "test quality in later."

Scenario

A Development Team has experimented with test-first development techniques and is successfully using the Given/When/Then expression of acceptance criteria in unit tests created by the developers during development.

Given/When/Then acceptance criteria format
Given <some initial context> When <some action occurs> Then <this is the result>

The team has good, readable unit test suites on which developers depend to guide their design and test the code frequently with an automated test harness.

Although this approach is working at the unit test level, the testing specialists on the Development Team are still using Microsoft Word documents to create the acceptance criteria for functional testing. They are validated manually after features are coded and complete. Because these tests are not being run until coders think a feature is completed, a significant number of defects are found by the testing specialists. This is causing re-work within the Sprint and sometimes leads to features not being completed before Sprint Review.

Lean Approach

While discussing the acceptance criteria workflow at Sprint Retrospective, the Development Team decides to try the following:

1. The testing specialists will create acceptance criteria not as Microsoft Word documents, but as failing automated tests that have no internal implementation.

2. The new automated tests will run daily at 5 AM and at 3 PM, producing a report of the test passes and failures. Newly created tests always fail.

3. When coders select a new feature to work on, they begin by implementing the functionality of the stubbed acceptance test.

4. The test may be refined by the coder, but in collaboration with the testing specialist who created it, so the original intent of the test is retained.

5. The feature is not complete until the test passes.

6. All tests must pass by the end of the Sprint.

After a couple Sprints using this technique, defects and rework have decreased. The Development Team monitors the report updated by the twice-daily automated test runs and realizes the passing and failing of tests can be shown as a trend. The team creates a report that gets updated with each automated test run. The report shows acceptance test pass and fail results trended over the course of the two-week Sprint. The graph is shown below.

The Development Team discovers they find more value in reviewing this report at their Daily Scrum than the typical Burndown Chart. The Scrum Master confirms this new graph can act as a crucial part of the Sprint Backlog.

The Scrum Guide specifies that the Sprint Backlog is the set of selected Product Backlog items for the Sprint, plus a plan for delivering them. For this Development Team, the plan is now constructed from failing acceptance tests and progress toward completion is tracked by trending the number of passing and failing tests. As with using tasks in the Sprint Backlog, tests may be added, deleted, or amended throughout the Sprint. The creation of a given test will often lead implementation of the corresponding feature by as much as a few days.

Using actual automated tests now as both the requirements and the mechanism of functional regression means that the tests are the requirements. This also allows the work of the Sprint to be viewed as a progression of making automated tests pass. This test-first development technique has redefined the way the team thinks about using Scrum and causes requirement validation to be injected into the creation process itself, thus building integrity into the product.

Many aspects of the immensely popular Scrum Framework support Lean principles. As Scrum Teams mature and improve, they often find Lean Thinking an effective tool for finding more value in iterative and incremental development.

While specific techniques may come and go, continuous attention to improvement is critical in maintaining healthy software development teams. The Scrum Framework is flexible enough to accommodate Lean improvement methods like those found in Kanban. Viewing Scrum through the lens of Lean Thinking often leads to better quality, higher productivity, and less waste.

Deliberately optimizing a team’s implementation of Scrum can be tricky. When looking for ways to improve, don’t let perfect be the enemy of good enough. Perfection of Scrum is far less important than delivering high-quality working software that is valued by customers, so focus first on those things that genuinely improve the product.

References

1. West, D. (2011). XXXXX. Forrester Research

2. Poppendieck, M. P. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional.

3. Anderson, D. (2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press.