Scrum Team (2019)

Scrum Methodology

Introducing Scrum to your Software Team

This blog aims to get your new team up and running with an Agile delivery approach as quickly as possible. To do this, we'll use the Scrum framework to show how you can successfully transition a new-to-Agile team to this method of working.


We’ll use a pragmatic approach, based on real-world examples, offering the steps that you'll need to take.


We will cover the following topics in this blog:

  1. Why Scrum is an excellent place to start
  2. How to efficiently transition to Scrum from Waterfall
  3. Visible workspaces for managing software delivery
  4. Measuring and reporting progress with visualization
  5. Removing impediments
  6. Managing delivery as a team sport


The importance of team retrospectives

We'll also describe several ways that you can measure the team's progress during the Sprint to help keep them focused and purposeful.


Why Scrum is an excellent place to start

Scrum is a lightweight framework that provides the necessary mechanisms to get your team's mindset focused on the essential aspects of Agile software delivery. If you were to compare learning how to use Agile to learning to ride a bike, then Scrum could be seen as the training wheels that get us moving forward.


That's not to say that Scrum is over-simplistic; as the saying goes, it's easy to learn but will take a lifetime to master. So while Scrum provides enough of a framework to get us started, it will also set us on the path to developing an Agile mindset.


So, Scrum is a perfect place for an Agile team to start its journey. It is by far the most popular framework amongst fledgling Agile teams. This blog aims to introduce the Scrum framework in a way that will help you to successfully transition a new-to-Agile team to this way of working.


Iterations and iteration length

Scrum is an iterative, incremental delivery process. Each iteration, or Sprint, as they are known in Scrum, lasts between a minimum of 1 week and a maximum of 4 weeks, with the preference being for as short as possible.


Shorter iteration lengths are what give our team its agility, as we get feedback at the end of each iteration; the sooner we get feedback, the faster we can adapt our approach.


If your team is new to working iteratively, there's no denying that it will feel odd at first. Based on experience, my recommendation is that your team picks an iteration length that feels slightly shorter than comfortable.


Taking this approach will give your team an opportunity to improve their process so that it fits the iterative style, and challenges them to change up their thinking.


What this means is, if you think 4 weeks is comfortable in which to deliver a working increment, choose 2-week iterations. If you believe that 2 weeks would be more than comfortable, opt for 1-week iterations.


The Scrum team should fix the iteration length, so pick an iteration length and stick to it. If after six iterations it isn't getting easier, then perhaps change the iteration length. Remember, the preference is always for the shortest iteration length possible.


Most teams I've worked with will opt for a 2-week Sprint, with teams occasionally choosing a 1-week Sprint if they feel they can achieve something meaningful in that time. It does depend on the context, but in general, my experience has been that 4 weeks is too long to wait for feedback.


Starting a new Scrum team

A word about time-boxes before we start: all Scrum events are time-boxed. For those that are formally part of the Scrum framework, their time-box recommendations are in the Scrum Guide.


All other activities or events that we introduce, such as Product Backlog refinement, should also be time-boxed. For these time-boxes, the facilitator of the event should estimate how long they think they need. They declare the time-box at the beginning of the event as part of the setup.


If you hit the time-box and you still have work to do, you can ask the team what they would like to do. Should they carry on, and if so, for how long? Should they reconvene at another time, perhaps?


Remember, meeting fatigue is a real thing, and people may have other commitments. Finding out if they can commit more time to extend the time-box is only polite, plus it's also an opportunity to sense the feeling in the room. If the energy is low, it may be worth taking a break.



To kick off a Scrum team, you'll need a few items:

  1. A timer: This is used for time-boxing meetings; most smartphones have one of these
  2. Whiteboard or wall space: This will be used to create your visible workspace

Tape for marking columns or swim lanes: If you're using a whiteboard, electrical tape works well; if you're using a painted wall, you'll need to use low tack tape, such as masking tape


Index cards: These are for writing User Stories post-it notes: These are for writing User Story tasks


If you're putting post-its straight onto a wall, not a whiteboard, buy the post-it® Super Sticky variety. They have much more sticking power and will save you from having to pick post-its off the floor and trying to figure out where they came from.


Black sharpie pens (fine tip): These are used for writing User Stories and tasks

The previous suggestions form a basic Agile toolkit, which each Scrum Master should have. I keep my own toolkit in a clear plastic fishing tackle box.


Preparing to Sprint

Before we start our first Sprint, we'll need to do a little housekeeping first. The primary focus is to make sure we have everything set up for the first Sprint Planning session.


The following activities are set up for team participation. Involving the whole team is the first step in creating a shared understanding and ownership of the product we're building.


Also, include stakeholders for a well-rounded picture. Including those with a vested interest in your product will enable you to get their input from the beginning, starting the relationship as you mean to go on.


Here are the pre-requisites for carrying out this series of activities:

  1. What you'll need: Index cards or A5 paper, post-it notes, black sharpie pens
  2. Setup: A large table to work on that the whole team can fit around
  3. Remember: Set a time-box before you start

We begin by first making sure that our Product Backlog is in order, which we'll do using the following activity.


Activity – defining the Product Backlog

One of the hardest parts of our transition to an incremental delivery approach is breaking down our team mission (the problem we're being asked to solve) into manageable chunks of work that will deliver working software.


Fortunately, there are several techniques for creating a backlog from scratch; these include User Story mapping and impact mapping. Both focus on maximizing the value we deliver to our customer.


For now, we'll assume the Product Owner has already created a set of User Stories for us to release, plan, and refine.


Have the User Stories written out on index cards, one User Story per index card? If you're using an online tool like Jira, print each User Story on a sheet of A5 paper.


Having a physical backlog in the form of a deck of index cards has several benefits:

  1. It allows you to lay out the backlog easily to see the bigger picture.
  2. It's tactile; something you can touch, pick up and examine, or easily move By shuffling the order, you can create multiple planning scenarios.
  3. You can easily stick the stories on your Scrum Board, and turn them into a key part of your visible workspace.


Throwing the completed User's Stories in a cardboard box at the end of a Sprint and watching that pile of done stories grows iteration after iteration is very rewarding


Activity – release planning

Simply put, release planning is a process in which we determine what order we should implement the User Stories from the Product Backlog. Remember that our aim is to create customer satisfaction through early and continuous software delivery, the first Agile principle.


When creating a Product Backlog, it's easy for it to become a bit of wish list. Blue-sky thinking happens as part of any requirements gathering process, regardless of the technique used.


Release planning allows us to prioritize the User Stories; the aim of prioritizing a Product Backlog is to surface the stories that will bring the most value and satisfaction to our customer first.


It's entirely plausible that your Product Owner has already prioritized their User Stories. If not, the following are a couple of ways that the team can prioritize the backlog together.


If you do choose to prioritize as a team, who should be present? Well, you'll need your Product Owner. If the Product Owner would like to include key stakeholders, you should include them.


Finally, I would recommend including the entire team. I'm always surprised by the amount of information about a product that surfaces during release planning, and your team will benefit hugely from hearing it.


The following activity is a group approach to prioritizing User Stories:

  1. Activity: Moscow
  2. What you'll need: The Product Backlog deck, post-it notes, black sharpie pens, and Spare index cards
  3. Setup: A large table to work on that the whole team can fit around
  4. Remember: Set a time-box before you start


Moscow is a simple but effective way to prioritize the backlog based on business value and risk. It is an acronym that stands for M: Must have this

  1. S: Should have this, if at all possible
  2. C: Could have this if it does not affect anything else
  3. W: Won't have this time, but would like to in the future


The lowercase "o"s are needed to make the acronym pronounceable. If it weren't pronounceable, it wouldn't be an acronym, it would just be an initialization.


The Must User Stories are non-negotiable—if you don't deliver them, then the product won't work and it will be a failure. It's nice to have features classified as either Should or Could. The Won't classification doesn't mean that you won't ever build this functionality, it just means it won't be part of the first release.


The simplest way to play Moscow is to set up the table in the following way:


Follow these steps to release plan and prioritize the backlog:

1. Lay all of the User Story cards out on the table and give people time to familiarize themselves with the User Stories. Set a time-box appropriate to the number of stories. This step can be fairly social, people may share stories, or even read them aloud.


2. Next, we prioritize the stories, you should ask people to silently work and move the User Stories into the categories they think are the most relevant. Again, set a time-box for this.


Some stories will get moved and then moved again. Most stories will end up in the Must category to start with, and the table will likely look as follows:


If this situation does arise, remind people that this isn't in the best interests of the product's development. While User Stories marked as Won't be equally important as those in the Must category, deferring some work allows the team to get on with other features sooner.


To help this thought process, you need to think about which features might deliver the most business value or will reduce risk and uncertainty the quickest.


Ask the team which User Stories in the Must category can be moved down while still producing a coherent first release. Ask for suggestions of which stories you definitely Won't need, and then place them in Won't. Remind people that this is just for the first release.


After two or three iterations, you should see something like this:

Take the opportunity to review the User Stories and make sure you have a coherent set of stories for the Must swim lane. If it helps, order the stories from left to right in their logical sequence.


The User Stories in the Must swimlane are your first release. While this won't necessarily represent a complete set of features, once built, it will give you enough to gather good feedback from your customer, and as such, will act as the beginning of your product's lifecycle.


You'll almost certainly identify additional stories during this stage, so it's important to have extra index cards and sharpies nearby.


Another fun way for the team to work is with Buy a Feature. Buy a Feature is a game where team members are each given a certain amount of money.


You start by pricing all of the features, making sure that some are more expensive than one person can afford, and only a group can purchase them.


The object of the game is to decide as a team which features you deem most important for your product and need to buy. To do this, you have to collaborate and pool your resources. 

  1. Activity – introducing the Product Backlog
  2. The first step in this activity is used to familiarize your team with the Product Backlog:
  3. What you'll need: User Stories written on index cards or printed, post-it notes, and black sharpie pens
  4. Setup: A large table that the whole team can fit comfortably around
  5. Remember: Set a time-box before this activity starts


The first step in this two-part activity involves your Scrum team sitting around the table. Your Product Owner has the Product Backlog; they pass it to the team member on their right. That team member takes the top story and reads it aloud, including the acceptance criteria and any notes.


They then place it in the center of the table so that other team members can read it, ask questions, and discuss the acceptance criteria. You should make any refinements to the story, usually in the form of pencil or post-it note additions.


Once the discussion is complete, the User Story will remain on the table, and the Product Backlog is passed right to the next team member, and the process is repeated.


This activity completes when either the backlog has been worked through or the time-box is over—whichever comes first.


As a general rule of thumb, it does help if your Development Team has seen the User Stories before they have to consider them during Sprint Planning. Giving your team a chance to digest what needs to be done to achieve the User Story will give them greater confidence when planning.

  1. Activity – estimating User Stories on the backlog
  2. The second step in this activity is to estimate the stories on the backlog.
  3. Activity: Using estimate buckets to size User Stories
  4. What you'll need: User Stories written on index cards or printed, post-it notes, and black sharpie pens
  5. Setup: A large table that the whole team can fit comfortably around
  6. Remember: Set a time-box before this activity starts


Once you've had the chance to review the backlog, the second step is for you to refine the User Stories further.


A good place to start any refinement is to try to estimate the stories. When you ask for an estimate, it immediately triggers the thought process, "what do we need to do to complete this story?"


The ensuing conversation from your team will give a good indication if the objective of the User Story is clear and the acceptance criteria are well-defined.


If they aren't, you won't be able to estimate the User Story and the team will need to go through a series of refinements with the Product Owner before they are ready to try to estimate again.


Bearing that in mind, and also taking into consideration that not everyone has used relative sizing before, we'll take the following approach:


Spread the stories out on the table and take the time to read them and ask questions if necessary. You may refine the User Story or add acceptance criteria at this stage if you wish. 


The next step is to take another User Story from the unsized pile and compare it to one of the stories you've already sized. We should ask ourselves the following:

  1. Is it double the effort or more of the already sized story?
  2. Is it half the effort or less of the sized story?
  3. Is it a similar effort?


Our team places the story in the appropriate column relative to the already-sized story. You then pick the next story and compare it to the already-sized stories.


You decide if it's bigger, smaller, or similarly sized to the currently placed stories. You then put it in the column that's most appropriate and pick the next story card and repeat the process.


At this point, you should take a step back to admire your work and to decide if you've got it more or less right. Remember that relative sizing is less about precision and more about gut instinct, and most importantly, it's about team agreement.


Once your team is happy with the relative sizing of each story, write its size on the story card in the bottom right-hand corner, as per the following example:


Activity – setting up the Scrum Board

The Scrum Board is the team's information radiator. It enables them to communicate Sprint status with little or no effort, even to people outside of the team. The visual nature of the Scrum Board can also give teams an insight into how they might improve their approach.


Make sure that you leave enough space in each column regarding width and height. It may be a good idea to use an actual index or story cards and post-it notes to make sure you have enough room.


The importance of team retrospectives

Scrum is an empirical process—we're constantly learning what works well and what doesn't work so well. Scrum requires a team to inspect and adapt its process on a regular basis. In this way, the team can continuously improve its approach, sometimes making profound changes along the way.


Retrospectives are at the heart of this mindset; they teach us to reflect and improve. Just as we would debug our software, we are now learning how to debug our process.


It's important not to accept the status quo! There's always a better, and hopefully more satisfying, way to do something.


State of the Team Description

A State of the Team is a gathering of multiple teams to understand what has been accomplished by each team, and what is needed from other teams, functional groups, or leadership. The state of the team allows all stakeholders to understand a global view of all status and progress.


This allows leadership to assess the organizational risk profile, and determine where support is needed, as well as an opportunity for teams to learn what others are experiencing. It is an important tool to build trust and understand progress at an organizational level.


Typical Roles

  • Agile Leader
  • Agile Team
  • Product Owner
  • Scrum Master


Desired Behaviors

  1. Create a schedule of State of the Team meetings.
  2. Develop a simple agenda that is common for all team. Teams should not have to prepare but should be able to summarize the information they are already collecting from daily stand-ups, retrospectives, and sprint demos.
  3. Go beyond status and capture the best ways to solve each team’s problems with the collective experience in the room.
  4. Stay agile. The meeting time will depend on the number of teams; however, a good rule of thumb is 15 minutes per team.


Team Room Set-Up Description

An agile team should have their own space, known as a Team Room. Team room set-up is typically done when a new team is formed, or a new project is set to begin. Elements of a team room that need to be considered are listed below.


  1. Size of the room
  2. A workstation that supports pair programming
  3. White Boards/Flip Charts
  4. Task Boards


Typical Roles

  • Agile Leader
  • Agile Team
  • Scrum Master


Desired Behaviors

  1. Secure the dedicated space for each agile team.
  2. Identify the room layout and all key elements that will be needed.
  3.  Purchase or secure all elements for the team room.
  4. Assemble the team room and reevaluate assembly during retrospectives.


Technical Debt Description

Technical Debt is incurred when the agile team proactively determines that a less optimum, less efficient, or less robust solution is appropriate given constraints of time, budget, or resources.


As this graphic from Martin Fowler describes, as technical debt increases, the costs and effort to continue development, or maintain an existing system, will become too high, and a “technical debt sprint” should be scheduled within a release to improve code quality.


The challenge for any Development Team is that:

  • The business community likes technical debt due to short-term gains.
  • The technical community dislikes technical debt due to long-term pain.


Typical Roles

  • Agile Team
  • Scrum Master


Desired Behaviors

1. Quantify the technical debt and balance the business needs with the technical needs of your projects.

2. Leverage the practices in sprint planning to plan, prioritize, and sequence the elimination of technical debt by allocating them as user stories to future sprints and releases.

3. The decision to incur technical debt should be proactive and not the result of defects or coding errors.


Test-Driven Development Description

Test-driven development (TDD) is an agile technique where a developer will write a basic test case to verify the desired functionality, knowing that it will fail, and then writes the minimum amount of code to pass the test.


The developer will then enhance the code to ensure that it meets acceptable performance and coding standards and principles.


Test-driven development brings the most value when used with short sprints, where rapid experimentation is possible.


Desired Behaviors

  1. Incrementally create test cases and related software that fails initially, but eventually passes each test case. An automated test framework is normally used to encourage efficiency.
  2. If manual testing is used, save test cases for the future to ensure that changes to the software do not cause unintended defects.
  3. Use the test case inventory to evaluate requirements changes.


Three Diverse Humans Description

Three Diverse Humans, or TDH, is a User Story and Design validation technique that involves review and input for three separate, but equal, individuals prior to Product Backlog generation, or commitment to a complex design.


The typical TDH session is a one-hour, rapid-fire meeting that includes a developer, an analyst/SME, and a tester, but it can be attended by alternative roles as well.


Typical Roles

  • Developer
  • Analyst/SME
  • Tester
  • Others as Alternates


Desired Behaviors

  1. The TDH session begins with an agreement of the backlog stories or design to be reviewed.
  2. Five minutes of discussion, led by the author of the work product.
  3. Feedback by non-author participants from their perspective. For example, a tester might provide feedback of additional tools, environments, or technology that is required, while a developer may offer suggestions for downsizing a story.
  4. The User Story or Design is adjusted in real time, if possible, or placed on the backlog for a design sprint, spike, or backlog grooming session.


Training Description

Agile teams are learning teams. There are different ways to train team members, but each one should be designed with outcomes that build capability. Organizations should identify what training methods will work best for each scenario, and ensure that all team members have the capabilities to meet their commitments.


Professional Training is typically related to certification or a profession.

  1. Technical Training is related to the technological aspects of the job.
  2. Soft Skills are communication and personal skills that help to ensure success in the work environment.
  3. Team Training addresses the process the team agrees to adopt.


Typical Roles

  • Agile Leader
  • Agile Team
  • Scrum Master
  • Product Owner
  • Trainer/Coach


Desired Behaviors

  1. Determine organizational and team training needs. This may be captured in a training backlog.
  2. Ensure that consideration is given to training goals, budget, and resources.
  3. Develop a plan of execution that includes what training method will be used and a timeline.
  4. Ensure that accountability is assigned for accomplishing planned training and monitoring to completion.


Unit Testing Description

Unit testing is a technique applied by individual software developers to ensure that the smallest, self-contained pieces of code function as designed and provide the correct results.


Because manual unit testing is time and effort intensive, many tools exist to automatically run unit tests based on design elements coded directly within code modules. Continuous Build/Integration tools ensure that code is unit tested with no failures prior to check-in of code.


Typical Roles

  • Agile Team
  • Organization (e.g., Infrastructure or Support)


Desired Behaviors

  1. Provide the infrastructure and support at the organizational level to implement automated unit testing for each team.
  2. Create team agreement items related to unit testing all code.
  3. Ensure that the developers are trained in how to design code to support automated unit testing.
  4. Ensure that automated testing provides demonstrable value, and improves scripts if it does not.


Velocity Description

Velocity is a historical definition of a given team’s ability to deliver value during a consistent sprint duration. Velocity is used by agile teams for sprint and capacity planning, and to predict whether teams will successfully meet their sprint forecast.


Velocity is team and duration specific, meaning that as a team changes, they cannot expect its velocity (value delivered) to remain constant. Any change to the team or sprint duration will affect the team’s ability to deliver.


During sprint planning, an agile team will set a velocity objective for the sprint based on historical data. A burn down (or burn up) is used to depict a team’s actual velocity during a sprint or release.


Typical Roles

  • Agile Team
  • Scrum Master
  • Product Owner


Desired Behaviors

  1. Depend on velocity for sprint planning if the team and duration remain constant.
  2. Do not attempt to normalize velocity or story-point values across multiple teams.
  3. Do not attempt to assign hours or days to story points. The usefulness of velocity is based on its unit of measure being value, not time.


Visual Information Management Description

Visual information management is the practice of using information visualization techniques to depict important information to a large group of people. Visual information management is a clear, simple, and effective way to organize and present the result of a team’s work.


It can also be perceived as fun by the teams since visual elements bring color and life into an otherwise sterile office environment. Visual management will positively influence the behavior and attitude of team members, managers, and stakeholders by helping build transparency and trust.


The term “information radiator” is used to describe any artifact that conveys project information and is publicly displayed in the workspace. Information radiators are an essential component of visual information management, and they can be any handwritten, drawn, printed or an electronic display that the team places in a highly visible location.


Typical Roles

  • Agile Team
  • Product Owner
  • Scrum Master


Desired Behaviors

1. Use highly visible information radiators to convey cultural norms:

  1. The organization is committed to transparency.
  2. The organization is committed to high trust.
  3. Use information radiators elicit conversation when visitors are with the team.
  4. Take advantage of whiteboards, flip charts, poster boards, or large electronic displays as information radiators.
  5. Regularly update information radiators to keep the teams interested and informed.


Acceptance Testing Description

Acceptance testing, also known as User Acceptance Testing (UAT), provides the customer with an opportunity to validate that the product increment or released system is able to handle real-life scenarios and transactions.


Some of this can be addressed in Sprint Demos/Reviews, but often systems become so complicated that more formal acceptance testing is required.


To get the most valuable feedback, testing should be performed by an actual end user, or qualified designate, and should be conducted on the production system in the actual or simulated production environment.


The goals of UAT include gaining the customer’s approval of the system or product and clearly identifying any defects or issues and capturing changes to existing use cases or user stories.


Typical Roles

  • Customer
  •  End User
  • Product Owner
  • Scrum Master
  • Team Member


The Sprint Retrospective

The Sprint Retrospective usually follows on immediately from the Sprint Review and is the last meeting of the iteration. It's an opportunity for the Scrum team to inspect and adapt its process.


In general, the Scrum team will ask itself what went well during the Sprint, what didn't go well, and what it can improve. They should consider aspects such as team dynamics as well as processes and tools. The outcome of this meeting is for the team to come up with actionable improvements that it can carry out during the next Sprint.


Additional events

Most Scrum teams add additional events to their Scrum workflow. A good example is called backlog refinement, an event which some teams hold as regularly as once per week, or at least once per Sprint.


The backlog refinement meeting aims to look at the top stories on the backlog and prepare them to be worked on in an upcoming Sprint. Part of this preparation will include estimating the User Stories, which will tell us whether:


  1. We have enough information to able to start working on the User Story
  2. We've broken the story down into a small enough chunk; a User Story must be small enough to be completed in one Sprint


XP - Extreme Programming

Extreme Programming (XP) is the second most popular framework, used by roughly 10% of Agile teams. XP stands out as one of the few Agile frameworks that prescribe technical practices.


For instance, peer review is considered so important; when dialed up to 10 we do peer review all of the time. If all code is written while working with another programmer, we are code reviewing continuously. So XP makes the rule that all software that is destined for a production environment must be Pair Programmed.


He applied the same thinking to unit testing. XP deems unit testing so valuable it makes it a rule to write the unit test first before any code is written.


Writing tests first, also known as Test-Driven Development (TDD), is a practice that supports the creation of simpler code designs because just enough code is written to fulfill the test specifications.


The resulting automated test suite also inspires the confidence to make subsequent changes to the specification tests and code, in the knowledge that if the tests still pass, other parts of the system are unaffected by the change.


So this is how XP got its name. It prescribes core programming practices and turns the volume on each up to maximum, taking them to the extreme.


Events: Release planning/iteration planning, daily standup

  1. Special features: Prescribes technical practices, gathers requirements with User Stories, promotes working at a sustainable pace
  2. Lacks: Compromise—it's a fully committed, all-or-nothing approach


These are the roles XP recommends for a team:

There doesn't need to be a one-to-one relationship between team members and functions. One person can perform more than one role.


For example, the person who has the Coach role could also have a Tracker role. Some instances of combined roles are Programmer-Tracker, Programmer-Tester, and Coach-Tracker. Some roles shouldn't be mixed; for example, for the Coach to remain objective, they probably shouldn’t combine with anything except Tracker.


The same is true for the Customer, where we will also want to avoid conflicts of interest. Plus it's a time-consuming role in its own right.


XP requires that the Customer is part of the team; their involvement throughout the product development life cycle is key to its success.


In XP, it's assumed that the customer has the most information about the value of what is being built. At the same time, it's expected that the Development Team has the best idea of how to implement that value and how much it will cost.


While this may be a radical shift from your current way of working, you'll be amazed by the results of having the customer on the team —I've seen this work well many times.


We may be the experts at building software, but our customer is the expert in their domain and is the person closest to the real-world problem that we're trying to solve.


XP uses iterations to deliver working software incrementally. The iteration length is anywhere from 1 to 3 weeks. The team should pick an iteration length and fix it, only changing it if it's necessary:


Iteration demo

As with Scrum, the demo is an opportunity to invite stakeholders along so that they can see progress and give feedback.


The focus is on a demonstration and inspection of the working software completed during the iteration. Information gathered from the demo can be fed into the release planning ahead of the next iteration, and if necessary changes can be made and the release can be re-planned.


Iteration retrospective

Similar to the idea of the Scrum Retrospective, the iteration retrospective is an opportunity for the team to take stock of how things have gone during the past iteration and determine whether it can make changes to its process for the better.


Kanban and Lean Software Development

In this section, we look at Lean Software Development and its origins in Lean Manufacturing. We'll first discuss the thinking that led to significant breakthroughs in responsiveness and quality on the Toyota production line. We'll then look at how we can apply those to software development.



The following timeline shows a brief history of Lean and Kanban:

Lean Software Development and Kanban have their history in manufacturing and the work done by one company, in particular, Toyota Motor Corporation.


In its effort to economically mass-produce affordable motor vehicles for people after the Second World War, Toyota made profound changes to the way it organized its production line.


Toyota realized early on that there was a significant waste in manufacturing, which added to the overall cost. They implemented two notable changes to typical mass production lines, which had a profound effect on reducing costs and significantly increasing quality.


  1. Reduce all waste which didn't add value to the customer
  2. Focus on single-piece flow through the production line using a pull system


Reducing waste

Waste was identified at multiple levels, for example, overproduction of a particular part was seen as a waste for two reasons. Firstly, space was needed to stockpile the part until it could be used. This cost money not only for storing it but also took up floor space that could be used for production.


Secondly, sometimes problems in the manufactured parts weren't found until they were combined with other parts and put to use further down the production line. If a problem were discovered that required the entire batch to be re-machined or re-manufactured, this would add significant time and money.


Single-piece flow

In a production line environment, there are multiple workstations each of which takes the work of preceding stations and combines it or enhances it before passing it on to the next workstation. In this way, each station adds value and passes it further down the production line until the product being built is complete.


In a traditional product line environment, the work was pushed from one station to the next. Sometimes the work was sent in batches.


For example, the machine that built widget A, with some amount of retooling, also built widget B. Rather than lose time due to retooling, if you built batches of say 100 at a time, the machine operation was more efficient.


To solve these problems, Toyota perfected a system called Kanban. A Japanese word meaning signboard, Kanban is used in lean manufacturing to signal when a piece of work needs to be done.


The profound change that Toyota's employee Taiichi Ohno implemented in this signaling system was to reverse the flow of information on the production line.


This means that stations further down the production line would send Kanban signals to the stations behind them that they needed certain parts made.


The following figure shows how a Lean Production Line works:

A Lean Production Line waits until there are orders for its product because the communication channel is reversed. The order being placed is a signal to the end of the production line that it needs to deliver more finished products.


It does this by sending requests to the stations preceding it in the production line so that they can make and assemble the necessary parts for it to deliver a finished product.


The reversed flow creates a pull rather than a push approach to manufacturing and changes the dynamic of the system to focus on the whole system's end-to-end flow.


In layman's terms, this means that each station on the production line is concerned with carrying out the request it receives as promptly as possible to ensure the next station ahead of it is also able to do so.


Each station only carries out the work when it is requested; this is the Just in Time (JIT) of lean manufacturing. In any time between servicing requests, the workers at the station can clean their station and prepare themselves for any potentially busy periods ahead. They can also use this time to see if there is anything they can do to improve their process.


It is the responsibility of the entire production line to smooth out any unevenness in the flow. Workers should not try to compensate by deliberately operating their station even though they have no work requests, as this leads to unnecessary overproduction and stockpiling of inventory.


How Kanban/Lean fit into the Agile movement

Kanban, although not technically an Agile method, shares many similar attributes. The Toyota Production System (TPS) was founded on the principle that people were at its heart:


You may find some people are initially skeptical that it is possible to translate practices from Lean manufacturing to software product development. They argue that there are very few similarities between a production line and a software development process.


Production lines are doing the same repetitive tasks over and over again in sequence, which is often associated with a predictive planning approach. However, using Just In Time manufacturing, Toyota has created and evolved an approach that makes their assembly line much more responsive and adaptive than any other.


The Lean approach to process management has already strongly influenced the thinking of those who formed the Agile Alliance. Many of the methods the practitioners created incorporate aspects of Lean already, such as Scrum's use of the Scrum Board to make work visible.


XP and Scrum's use of iterations to manage the batch size and create JIT thinking about the requirements and implementation of software products. 


Introduction to the mechanics of Lean/Kanban

Here are the basic characteristics and features of Lean/Kanban:

  1. Planning style: Lean/Adaptive
  2. Delivery Style: Flow/Incremental
  3. Iteration length: Doesn't have time-boxed iterations
  4. Principles: Eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, see the whole
  5. Roles: Not prescribed, existing roles
  6. Artifacts: Kanban (message board)


Special features: Kaizen (Continuous Improvement), makes work visible, limits work in progress, work with your existing process, make policies explicit, evolves empirically


Lacks: A clear process framework of its own; instead it asks that we make our existing process visible and use the principles of Lean to improve it


There are no explicit roles defined by Kanban; assuming you have everyone necessary to do the job you've been asked to do, this is sufficient.


Start with your existing process. Map the workflow on a wall, making it visible so that everyone sees it. Use this sudden wealth of information on how your system works to makes changes and bit by bit evolve it into something that works better.


Getting started with Kanban

There are four steps to implementing Kanban within your team, which we'll cover in the following sections.


Step 1 – Make the team's work visible

This involves creating a board that reflects the current process the team uses to deliver software. The work that the team currently has in progress and the stage it's at also needs to be shown. The easiest way to do this is to write down each work item on an index card and place it in the appropriate area of the board.

For example, a Kanban board for a team with a simple workflow would look something like this:


Step 2 – Make the work policies of the team explicit

Teams often handle this by placing entry and exit criteria for each column to make them transparent. This will look something like the following:


The policies form what is commonly known as the Definition of Done (DoD). The DoD is a checklist that the team applies to each work item. It is a way for the team to ensure they've completed the work item to a satisfactory standard and therefore ensure they are the baking quality of their product.


Step 3 – Improve flow

With Kanban, as with the other Agile approaches, we want to add value as soon as we can, by delivering useful software as fast as possible. The reason for this is two-fold:


1. Most people don’t know what they need until they see it. It's hard to imagine how the software will look and behave until it's built. Everyone has a different version of it in their head. Once you have something working, you can start to get feedback from your customer. This is when the real work begins.


2. The domain we’re operating in is rapidly evolving. In business terms, 6 to 12 months is too long to wait for something. The way the business works and the rules that govern it could have easily changed within such a timeframe.


For work to start to flow across the board, we have to do two things:

1. The first step is to reduce the size of each work item so that it is as small as possible. Taiichi Ohno called this reducing the waste of unevenness (Muri).


For us in the software industry, unevenness is reduced by managing and reducing probable variability, which we can also manage by keeping the work item as small as possible. This doesn't mean that we're eliminating all variability, just reducing the amount.


2. The second step is to switch to small batches. This can either be done as Scrum or XP does, using Sprints or Iterations.


Alternatively, the more granular way is to start to manage Work In Progress (WIP) limits so that the team can focus their effort on the items currently being worked on and avoid the loss of time caused by context switching when multitasking.


Assuming the items have been prioritized by value, this allows them to focus on completing the high-value items first.


Rather than thinking and working in iterations, the focus in Kanban is on optimizing the flow of work items through the system. To optimize flow two shifts in thinking have to happen. Firstly, we need to think of the system as a whole, the end-to-end process from idea to delivery of that idea.


Secondly, instead of pushing the work through the system, we have to think of the system as pulling the work through it. When the system has the capacity, it pulls the next piece of work into it to be worked on.


This requires careful control; the aim is to avoid large batches of work that move as one cohesive block as this only encourages optimization at the local level. Instead, we carefully manage WIP and prevent overcapacity by limiting the number of items being worked on at any given moment.


To identify where you might have flow issues in your process, you can map your entire process out so that the entire process is explicit.


This is similar to a technique known as Value Stream Mapping, but where a Value Stream Map is a snapshot in time, modeling your Kanban board precisely to your Value Stream allows you to observe and iron out any problems in flow in real time.


Visualizing your work in this way will soon help you identify when there is too much work in progress.


Blocks like this can have quite subtle effects. One observed result of allowing work to accumulate is to put all of the work items in the column into a single batch. We can then create a single software deployment and carry out testing on all the items at once. We think this will create efficiency in our testing, which it may do at a local level.


However, with five work items in that column, the reality is that each work item will delay the others as we wait for testing to complete. If we find any problems with one or two them, the whole batch will be delayed and the overall flow will be significantly reduced.


To tackle this, determine if this is a one-off or whether a pattern is emerging. Either way it is important to take pressure off the people who are currently testing, by swarming on the work as a team. Once the workload is back to normal, the team can prevent this from happening again by placing a WIP limit on the test column.


Step 4 – Kaizen or continuous improvement

Once the team is up and running with the preceding three steps, the next thing for them to implement is Kaizen.


Kaizen is a Japanese word meaning continuous improvement. It is similar in concept to Scrum and XP's retrospective event. The team is encouraged to take time to reflect on their work regularly, and where possible identify improvements to the way they carry it out.


Choosing the right framework

It's no surprise that most Agile transformations start at the team level. Agile is a grassroots movement led by a bunch of software developers who knew, through their trials and tribulations, that there had to be a better way to build software.


In choosing the right framework for your team it will depend a lot on where you are on your journey.

If you're a product/project team, Scrum is the place to start. Especially if you're new to Agile, or if you have a mix of Agile understanding of your team members.


Scrum is simple to pick up because the framework gives you everything you need to get started. Plus, once you begin to master some of the basics of Scrum, it's easy to add practices which enhance your agility.


This is the path that we will follow in this blog, in it we will give clear guidance on how to build up our team's practice of Scrum.

What follows in this section is a commentary on the three methods we've just overviewed where we took a quick look at the similarities and differences.


Designed for small teams

All of the Agile frameworks described in this blog are designed for use by small teams. For Kanban, there is no prescribed team size, but if clear communication and coordination among team members is needed, then keeping the team size small is desirable.


An Agile team's ideal size is often referred to as a two-pizza team, that is, the team is just big enough that two pizzas would be enough to feed it. This obviously depends on the size of the pizza!


They don't include product discovery phases


The other thing you'll notice about each of these frameworks is they don't explicitly define phases for product discovery/ideation. Few Agile methods do, DSDM being the standout. Instead, most prefer the team to manage this themselves. There are a number of techniques for doing so, including Design Thinking, User Story Mapping, and Impact Mapping.


There are similarities with subtle differences

Scrum and XP both explicitly involve the customer, Scrum with the Product Owner role, XP with the customer/business representative on the team. Lean Software Development emphasizes people are at its heart.


Scrum doesn't explicitly mention release planning, it assumes that the Product Owner will manage the backlog and the items nearest the top of the backlog are the ones of most value to the team. It assumes that the Product Owner will manage the backlog and the items nearest the top of the backlog are the ones of most value to the team.


Scrum and XP form batches of work using iterations. XP encourages its practitioners to err towards the smallest iteration possible.


This stimulates incremental delivery thinking and moves teams away from the pitfalls of a mini-waterfall, where you execute a User Story in a series of handoffs just as you would a waterfall project.


Kanban doesn't make use of iterations to batch work. Instead, it focuses on flow; achieved by keeping each work item as small as possible and by limiting the work in progress so that people can focus on one task at a time.


It is designed to work with your existing process, and because of its value-driven mindset, it will start to shift the Development Team's thinking towards delivering something sooner rather than later.


The advantage of using Kanban at a more granular level, work item versus iteration, means that we can be even more adaptive and responsive to change. However, with great power comes great responsibility, and the Kanban approach does require more attention to detail.


For example, to remain this adaptive requires that the customer and team have an innate understanding of the overall objective and whether they are currently tracking towards it.


I often hear people discussing where and when you should use Scrum versus Kanban. For example, because of Scrum's history in product development, it seems the logical choice when developing a new software product or making significant enhancements to an existing one.


For most people, Kanban seems better suited to a more ad hoc backlog, where it is typically little or no coherency between work items. This is often the case when the product is in maintenance mode (some would call this BAU or business as usual).


However, we shouldn't let Kanban's apparent simplicity fool us; of the two approaches, Scrum and Kanban, Kanban is probably the more nuanced.


Tightening Feedback Loops in the Software Development Life Cycle, it can be used just as effectively as Scrum to build products, if not more so. Applying Lean thinking to product development increases flow and works particularly well when the top portion of the Product Backlog is prioritized and well defined.


Mixing and matching Agile methods

As we’ve seen in this blog, there are a lot of similarities between Scrum, XP, and Kanban. No matter where we start as a team, most will start to combine the practices and thinking of one or more of these methods.


Sometimes we do it without realizing, for example, XP’s User Stories have become a universally accepted way to gather Agile requirements.


Sometimes we do it explicitly because we want to enhance our Agile adoption with the benefits of a particular practice. An example is when Scrum teams enhance their workflow using Lean principles, Tightening Feedback Loops in the Software Development Life Cycle.


When we look at the practices that each method presents, we see a spectrum form. At one end of the spectrum, we have Kanban, a simple but nuanced approach for making work visible and then improving our workflow.


At the other end, we have XP, where years of practical experience led the founders of that movement to insist on following a specific, disciplined approach. XP can be too extreme for some as there are a lot of practices to adopt. 


Lean Software Development and Kanban could be seen as too light—just do what you're doing now, but make it visible and seek to improve it by continuously eliminating waste in our process. Sounds simple, but understanding and optimizing our system isn't as easy as it sounds and requires much practice.


Scrum can be seen as somewhere in the middle. It provides enough of a framework for people to start their journey to becoming great inspectors and adaptors. At the same time, it holds back from prescribing a huge change in technical practices that may cause change phobia.


So, start with Scrum and get used to incremental delivery. Then begin to apply good disciplines that bake quality in from the beginning rather than test for quality later. Do this by conducting a number of experiments to see what works for you in your context. 


One final thought, we need to consider that most Agile frameworks focus on the delivery of software. Few include explicit phases, either at the beginning for the initiation of product ideas or at the end of release and deployment.