As agile software development methodologies become more familiar within mainstream IT organizations, agile practitioners have been experimenting with some of Agile’s Lean roots. One lean practice that has gained traction with many agilists is a Kanban board.
Lean has much in common with agile. Lean has two principles, add value for your customer and empower your workers. If we look at the Agile Manifesto’s 4 we can see similarities between the manifesto and Lean principles:[login]
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile techniques emphasize empowering individuals on the team, as evidenced in the phrase “Individuals and Interactions over processes”. “Customer collaboration” indicates that what is valuable to customers must be a major consideration in agile projects.
Teams looking to lean principles have been able to use Kanban boards both within existing agile structures and as a process that stands on its own. Sustaining engineering projects make an easy start for using Kanban. Below is a guide intended to help teams start using Kanban within their organization. As mentioned in the last part of this article, the best way to start Kanban is get someone experienced to coach your team. If your organization cannot do that, and to help get started, the following can help your team begin with Kanban.
Organizational Buy-In
Since lean terminology is familiar to most business people, it is not as difficult to sell in the organization as some other agile methodologies. Manufacturing companies have a lot of familiarity with these concepts. See the resource list if you would like to learn more about this.
For this reason, a Kanban board can be introduced at a lower organizational level and then melded into corporate culture. Explaining why a Kanban board works should not be as much education to C-Level types as say explaining Scrum to them. Start with one team, and see what works and does not. Capture Cycle times, and compare those to what that team is experiencing. So let’s start our Kanban board.
Determine Your Value Stream
To begin your software organizations Lean journey, the team needs to map their value stream. This is not as complex a task as it sounds. Begin with a workshop involving all the team members. In the workshop, team members map out their current software development process. Mapping out the current process just means that team describes each step the process takes. This is important to make sure this is not a future state the team wants, but the current state.
You can map your process using an electronic tool such as Visio, or consider using an actual Kanban board. For this exercise, the Kanban board is the best way to map out your process. Use the software tools to help you map this out if your team prefers a more traditional value stream mapping tool. Remember that the map will end up on your Kanban Board, so simply using the board to map out your process eliminates some waste.
To map using a Kanban board, set up different Queues on your board that represent the different states your development process has. If your team started with Scrum, you may already have states of In Process, and done. But look deeper and see what actually happens in your process. QA should be involved with your team, so make that a Queue if it makes sense. Creating automated tests may be something your team consistently does during the process, so make that a Queue.
Mapping Examples
Look at an example of how a team might map their development value stream. If your development team has someone who initially creates the acceptance tests (hopefully automated!), then perhaps a queue can be set up as the Creation of acceptance Tests. You may consider this part your Analysis phase. As long as the team understands that the Analysis phase includes creation of acceptance tests, this approach works.
In this instance, after analysis, a developer works on the story or feature, coding unit tests, and the software to the acceptance tests just created. So then a queue for Development should be set up.
Next, the developer hands the story back to the QA person who set up the test, so they can perform their standard test suite on the this story or feature. To capture that in our value stream, a Queue is set up for QA.
After QA, in this example, the team is done. You may want to set up a deployment queue, if that is a process that warrants it. To see a template for mapping using a Kanban board with the above example, see example 1 below:
The above example shows how your Kanban board could be divided based on the example team mentioned above. The team needs to agree on how the current process works. Feel free to map the process you think you want to get to. Do not use that process, but keep it to see the progress you make towards your ideal!Next
Set Your WIP Limit
Once you have mapped out your process consider limiting your Work In Process, or WIP. Each column should represent a queue where work happens. It is a good idea to set a limit to what can be in that queue, and not allow any other work prior to that queue to send work to the next queue until the current limit is relieved.
The way to decide on those limits involves considerations on who is available to work and how much they can give to the team. If you have 2 developers, who use the engineering practice of Pair Programming, the development queue may have a limit of 1 on WIP, and 1 on the Ready queue. The team needs to give input on the limits. Once these limits are decided on, the team should reevaluate them frequently.
Work on your product backlog
At some point the work to be done should ideally be captured on an index card. If you use stories, this should not be hard. Consider moving your units of work into stories or features if you have not already.
Before beginning, make sure that the pieces of work in your backlog are still valuable. Consider making rules such as expiring stories that are older. That way, if your backlog includes stories that are older, your team can be that they are still needed. This solution is especially helpful in Sustaining Engineering einvironments.
Groom the backlog
To groom this backlog, use criteria like submitted date and see how long that request has been in the system. Check with Product Owners as to values of keeping that in the backlog. Or implement a rule that says that all stories not worked on for 6 months will expire. To get it back in the backlog, the Product Owner will need to submit that request again.
Also, make sure that the backlog is properly estimated. Kanban does not require something like story points in estimates. Depending on the maturity of your team, you may need to use estimation until you feel that the stories are written in a consistent manner that the size is usually the same. This would get rid of the need for estimation.
Most teams will need to estimate what is in the backlog. This can be done using traditional XP/Scrum estimation with Fibonacci sequences, or use T-Shirt sizes. Sizing things at small, medium, large can eliminate a lot of wasted time in story estimation meetings.
When the backlog is ready, the stakeholders can put anything not prioritized in a Parking Lot area. The stakeholders can then prioritize those stories in the Parking Lot. When a story is pulled from the Backlog queue on the Kanban Board, it can be immediately filled from the highest priority story in the Parking Lot. This allows the team to always have stories that can move through the board, and the team is always working on the highest priority.
Set up Necessary Team Meetings
Daily Standup
Most teams using Kanban boards use the Daily Standup, common to most agile methods. The difference for a Kanban can be that large teams can use this concept. For smaller teams, the tradition of team members relating what they worked on yesterday, what they are working on today, and relating any impediments will work.
For larger teams, this may be impossible to keep a meeting to 15 minutes. In that case, the team only asks that the team members who have impediments discuss what those issues are. This helps keep the time in that meeting down to a reasonable level.
Stakeholder Planning Meeting
Since Kanban does not use time boxed iterations for planning, there needs to be a regular planning meeting to allow stakeholders to prioritize stories in the backlog. Also, there needs to be a regular release plan.
Assuming the team plans to release every two weeks, then any feature that is in the done column will be included in this release. Because this is based on a flow of stories going through the teams Kanban board, the team should be able to offer the business a predictable rate for stories placed in the board to get into production. Perhaps the rate is every month, or every two weeks.
The great thing about this rate is that it is based on facts from your board, not from estimates. This allows teams to set up service agreements with the business to give them a comfort in when their features will be deployed. There is much value to business in predictability.
Watch your team perform, and improve the process
Once you have started your Kanban board, you are not done. The entire idea behind Lean is that the team will continually improve processes to improve quality and delivery. As your product improves, this should impact the bottom line of your company. In the end this is all about making organizations deliver better products! Below are more resources to read up further on. If you are considering doing this, consider hiring a coach to guide you through this process.
