Asynchrony Solutions Blog

It’s not always about technology

by on February 21st, 2012 at 5:16 pm

At Asynchrony, we like to give back. We like to support causes and support each other. Danny Shoemaker, a member of our Business Development team, is on a mission to climb Mount Kilimanjaro this summer in honor of his loved ones who have dealt with cancer and to support the mission of LIVESTRONG. There are very few of us who haven’t been touched by cancer in one way or another. For more information about how you can support Danny and to learn more about the participants and their goals, follow the links below.

LIVESTRONG.org blog: http://bit.ly/zwK2AQ

Danny’s Survivor Summit page: http://bit.ly/wiev8B

The Agile Architect: Deadline Ahead: Will Your Team Make It?

by on February 17th, 2012 at 5:12 pm

My new Agile Architect article, “Agile Deadline Ahead: Will Your Team Make It?” is online at ADT Magazine at http://adtmag.com/articles/2012/02/16/agile-deadline-ahead.aspx

You can read all of my Agile Architect columns at http://adtmag.com/Articles/List/Agile-Architect.aspx

Tags:

Kanban: It Changed My Life

by on February 8th, 2012 at 5:52 pm

Well, maybe not my life, but my project’s life.  A bit reading and patience will allow me to explain.  But first, a definition of the word: Kanban.

kanban |ˈkänˌbän| – noun

a Japanese manufacturing system in which the supply of components is regulated through the use of a card displaying a sequence of specifications and instructions, sent along the production line.

“Now wait.  We are not in Japan, and we are definitely not a production line.” Understood, however we can take this system and apply it to our practice.

Kanban in practical terms is best described with a picture.

We have multiple queues drawn by string, or marker on a whiteboard, or imaginary (it depends on the project).  Each queue represents a phase of our development process.  A new project, for example, may have the following queues: Waiting, Code In Process, Code Complete, Acceptance Testing In process, Acceptance Testing Complete, Ready for Customer Review, Ready for Production.

As requirements, from our client or customer, are recorded, they are written onto story cards and placed into the Waiting queue.  When someone begins working, that person picks up the first card and moves it over to the next queue to begin Coding.  When the story has been completely coded, it goes to Code Complete so that the person who provides acceptance testing can pick it up and begin working on that story.  This process continues to happen until it reaches the end.

Stories get worked on from the right side first, so that it can reach completion as fast as possible.  This provides the most efficient and focused flow of progress.

 Just in that brief description, I have covered a bunch of topics we deal with when working on a project:

  • Recording, prioritizing, and tracking customer requirements.
  • Showing progress of work in progress.
  • Communicating when something is complete and ready for the next phase of the development process (Acceptance Testing).
  • Providing visibility for when work is running out and new requirements are needed from the customer or client.

Kanban provides a ton of invaluable assets, as a system, to your project.  Such as: efficiency, focus, communication, limit work in process, prioritization, visibility on status.

We also limit work in process (WIP), because work in process is considered waste.  It is considered waste because it, at the state of being work in process, is unusable code.  If at any point in time the customer says “Let’s change priorities completely” or if for some reason the project finished prematurely, the incomplete code is wasted.

We apply WIP limits by restricting the number of stories that can be in a particular queue.  If you can’t move a queue forward because the WIP limit is already full, you are forced to either clear the queue ahead or find someone who can.  This is very important because it prevents the project from consuming a block in flow of progress.

Our primary Kanban consists of the following queues.  Feel free to use the exact same queues for your project but beware that every project is different and requires a different kanban.  Pay attention to the pain of your project, start simple and adjust based on that pain.

  • Backlog
  • Waiting (limit 3 features)
  • Code In Process (limit 3 stories)
  • Code Review Ready (optional, limit 1 story)
  • Code Review In Process (optional, limit 1 story)
  • Quality Acceptance Ready
  • Quality Acceptance In Process
  • Quality Acceptance Complete
  • Feature Waiting for Stories (limit 3 features)
  • Feature Ready for Customer Review
  • Release Waiting for Features
  • Release Ready to be tested on Staging
  • Release Ready for Production
  • Released to Production
When building your Kanban, remember the definition.

a Japanese manufacturing system in which the supply of components is regulated through the use of a card displaying a sequence of specifications and instructions, sent along the production line.

Your project’s development cycle is a production line.  In order to get the most quality and the most work completed think about work in process, notice where stories have the longest cycle time (time a story spends in a given queue), which queue fills up too fast (perhaps you need more resources to satisfy that queue, or you need a greater WIP limit).

If you are developing cars, you want as many completed, high quality cars as you can build.  You don’t want 500 windows, 200 doors, 6 handles, 3 mirrors and 1 car.  Same goes for developing an application.  You don’t want 10 features in process and 1 feature completed; you aren’t guaranteed time to finish the work in process.

I hope this post was useful to you. I would love to get some feedback.

This post is the first in a series I plan on publishing about how Kanban changed my life.  Check in to see the additional posts. I will also update this post with links.

Tags: , , , , , ,

Older Posts