Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Agile Techniques: Getting Started With Kanban

This guide is intended to help software development teams start using Kanban within their organization.


advertisement
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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap