Posted by: jsonmez | April 28, 2010

The Kanbanand Guide

In my last post, I talked about some of the problems of Agile processes and suggested the introduction of a new process which takes some of the best parts of each of the popular processes and condenses them into the Kanban lean- style-thinking of limiting the work in progress.

For this post I want to clearly define what I am calling “Kanbanand” with two primary goals in mind.

  1. Allow someone who is interested in doing a Kanban like process to find enough information to be successful.
  2. Create a common thread for people who are already basically doing what I am suggesting.

Three Pronged Fork

I want to present Kanbanand as a three pronged fork.  In my mind there are 3 distinct areas of a successful Agile process which must be addressed.

  • Business and overall encompassing project process.
  • Development practices, including standards and best practices.
  • Infrastructure: build systems, deployment, source control.

We must know how to run our day to day process, how we physically construct our product, and how we actually build and deliver the product.



  1. Project is broken into stories which are small vertical slices through the system which are prioritized.
  2. A Kanban board is used to make the progress of a team visible and has limits to control the Work In Progress (WIP).
  3. At least once a day team members meet around the Kanban board in a stand up meeting to talk about the progress of the board.
  4. The team meets on a regular basis to have a retrospective to discuss how to better improve their process.
  5. Teams always pull in work, work is never “pushed” in.
  6. Once work has been approved as “done” it can never be “not done”.
  7. Find something to measure and measure it.
  8. The team is responsible for, and empowered to determine how the team accomplishes its goals.


  • Roughly same sized stories over irregular sized stories.
  • Stories specifying what, over stories specifying how.
  • Stories that are one sentence over stories that are one page.
  • Talking about how to move the board forward over talking about what I did or someone else did.
  • Cross functional teams over specialized teams.



  1. All code is unit tested.
  2. Static code analysis tools are used to set code standards, all code must meet those standards.
  3. Any code that is done, is completely done.  It is refactored, it is unit tested, it meets the quality standards.
  4. Code is never commented out.  Anyone is allowed to delete any commented out code at any time.
  5. Determining code is meeting the quality standards must be done in an automated way.
  6. No one owns code, anyone can work on any code.
  7. Documentation is ONLY created when it will serve a known purpose and has an immediate value.  (Code should document itself with good names and simple flow, unit tests document the low level requirements of the system.  Automated tests document the behavior of the system.)
  8. Testing requirements come from the customer, not from the developer.


  • Test driven development over writing unit tests after the code is done.
  • Pair programming over working alone.
  • Readable code over smaller sized code.
  • Doing things right over doing things fast.
  • Showing the customer over asking the customer.
  • Impromptu discussions at white-boards over scheduled meetings.
  • Building tools that will help make completing ten things faster, than completing one thing faster.
  • Writing automated tests over manual testing



  1. Code is continuously built and integrated as soon as it is checked in.
  2. Builds build code, run unit tests, run quality checks, produce deployable bits.
  3. Builds fail if any unit test fails, or any quality check fails.
  4. Code is only deployed from the exact bits that were produced by the build machine.
  5. Code can be deployed to any environment with the push of a button.
  6. Production data never goes to any other environment.
  7. Developers can always run a local build which is the same as what will be built on the build server.


  • Moving forward to fix problems over rolling back.
  • Integrating soon over merging later.
  • Quick builds over slow builds.
  • Deploying on demand over deploying on a schedule.


That is my first crack at it.  I have tried to keep the process as simple as possible, but still include as rules the things that I think are most important to be successful.  I tried to keep the things that involved judgment calls as values.  I believe this provides enough information to allow an organization to create a custom process that will work for them, but will still have enough controls to be consistent in the things that I feel make Agile practices valuable.

Let me know what you think, or if you have any suggestions.  I will update this post as this list evolves.  I am sure there is something I missed or could state in a better way.

Like I said before, if you are doing some form of Kanban, you probably are already doing Kanbanand.  If you are doing Scrum, your major change would be to drop the planning and instead try to get same sized stories while limiting your WIP.



  1. […] my next post I am going to attempt to define what I will call Kanbanand.  I will proceed with the goal of […]

  2. I like this. It is a very clear and concise description of how software should be built, coupled with many essential values. I especially like the focus on software craftsmanship. I’d like to see some mention of cross-functional teams, and see the principles of self-organization, collaboration and prioritization called out more explicitly. Other than that, great job 🙂

    • Thanks for the input Tobias,

      I agree with you. I made a couple of changes to the Process part talking about prioritizing stories, having teams be empowered to determine how to reach their goals, and a value suggesting cross function over specialization.

  3. Great post , I like the simplicity and the way things are broken down as Process , Development and Infrastructure with Rules and Values. It would be great to see a similar section that focuses on People, rules and values when it comes to people.

    • Hi Bachan,

      Thanks for your comment. I added some things to the process to account for some of the people rules and values. See if you like that better now. I’m not a 100% sure I want to break people off by themselves just yet.

  4. […] that need to change to really be able to do Agile development.  (Which is why I suggested a new process Kanbanand that does address those […]

  5. This is really great, and impressively concise.
    Not sure I understand Infrastructure Rule #6:
    “Production data never goes to any other environment”.

    • Thanks, I appreciate the compliment. I intend to write a whole post on “Production data never goes to any other environment.”
      Basically it means that you don’t take production data from a prod database and move it down to dev for testing or debugging.
      The only place production data lives is in production and never copied anywhere else.

  6. […] Developer, Prod is Not For You In my Kanbanand guide, I have a rule for infrastructure that says, “Production data never goes to any other […]

  7. Hey man, I enjoyed the post — agree with nearly everything, was wondering if you could elaborate on this statement a little bit: “Once work has been approved as “done” it can never be “not done”.”

    • Thanks, I appreciate the compliment.

      What I mean by that statement is that work that whatever the requirement is for a story to be considered “done” is, that has to be the final word on it. The work can be changed, but it comes in as a new story.

      One problem I have seen on agile teams is someone later down the line trying to claim that a story is not “done”, because it doesn’t do this or doesn’t do that, or it wasn’t what was expected. I am trying to eliminate that problem by saying that you have to have someone make the final sign off before you consider that work done in the first place, and that sign-off needs to stand.

      It is horribly demoralizing to an agile team to have someone say a story is not done, when the team has been told it was done. The team starts to feel like they are not able to know if they are every building the right thing.

      The best way to stop that in my opinion, is to have a clear sign-off person in the business who says that a story is done. That might be a product owner, or some other role, but that role and understanding needs to be defined.

      Hope that helps 🙂

  8. That clears it up, thanks!

  9. […] seems like the principles in my Kanbanand Guide still mostly apply, even in this situation, […]

  10. […] past about some of the shortcomings of specific agile methodologies.  I’ve even suggested a new one […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: