Kan Ban Boards – a lesson in diversity

I recently had the opportunity to discuss our Kan Ban board solution with other professionals and I was surprised with the diversity we had across our boards given our relative alignment on Agile. We had the usual expected difference on what columns and rows were on the board, but what surprised me were the differences on how the board was managed. How items got on the board and were moved on the board ended up being quite different.

Our Board

Our board is what I would consider a relatively standard board. (Of course, I would have that position) We have limits for each of the columns on the board and the columns are:

  • Open
  • Analysis and Design
  • Development
  • Testing
  • Done

We also have rows that help to categorize the features. I have seen people create rows for individuals, but we wanted to keep it at a higher level to not imply that one person ‘owns’ the feature as multiple people will be working on the feature. (Note: we use the term feature but it equates to a User Story or a small collection of User Stories)

The Diversity

1) the level of Feature/User Stories that you track on the Kan Ban board can vary greatly. This was somewhat expected.

2) Can cards move backward? In my thoughts, I would move the card back to analysis if more analysis was required and then move it back to development when coding can resume. My friend would keep it in development the entire time. I would state neither is correct or incorrect, but it is interesting how we both modeled our board to get us the information we wanted. I primarily wanted to know what type of work was being done, while my friend was more interested in showing how long it has been worked on. (Cycle time) Either system can probably provide both, but it is interesting as to what each person’s preference was. The driving factor in this difference might be our background as I am more project management focused, while my friend is more developer focused.

3)  Defects… My friend would create every defect encountered as a new card while I would consider the defects part of the original card until it has been accepted. (Once the work has been accepted and considered done, then any subsequent defect would be considered a totally new card) This difference was perhaps the most surprising as I just assumed that we would consider the feature in totality and creating a defect as a new card would perhaps give the false impression of done. Perhaps this is another indication of both of us using the board for different primary purposes. Again my friend was focused on flow of the work, while I was using it to manage done according to the stories we communicated to the business users.

Summary

There is no right way or wrong way to implement Kan Ban. That is one of the reasons for the easy adoption. I encourage you to try it and talk to your co-workers and friends. You may be surprised with the variations.

 

#Agile Perfection musings

One of the many toys my kids got over Christmas was the game Perfection. I can remember playing this game many times when I was young and I was happy to see my kids take a liking to it. For the uninitiated, the game of Perfection involves matching plastic shapes with their appropriate match on the board before the timer runs out and the spring releases the board and shoots all the pieces in the air. Good old-fashioned fun. Funny thing is that the game has not changed over the years other than introducing subtle mirror image shapes to confound adults who think they have the game figured out. 😦

While I was playing the game with both my children, I couldn’t help to try to instil some Agile principles in their thinking. But to my surprise the kids already were playing the game with the smallest iterations possible. Instead of trying to create batches of shapes to place, they both instinctively took a piece at a time and tried to place them before looking for the next piece. I instead watched them with fascination as they tried to become more efficient by implementing some more traditional processes.

A couple of these were:

  • One interesting observation came with my son. He soon discovered that he could be more efficient if he batched 2-3 pieces in his hand at a time. Fewer pieces than that and he found that there was too much motion to get the pieces and forgetting of where the matches were on the board. More pieces than that and he spent too much time searching through the pieces in his hand to find the one he was looking for. This was quite fascinating as the process he used was sometime looking on the board first to find a matching piece if he remembered it was one of the batch he had just picked up. So to save on motion he sometimes went from hand to board and board to hand if he recognized he had another match in his backlog.
  • Another interesting observation then came with my daughter. My daughter is much more results focused and really disliked the game popping on her. Her first solution was just to add more time to the game so it didn’t pop. 🙂 Once I mentioned that this wasn’t really in the spirit of the game, she then focused on another angle. She focused on the pieces that gave her the most problems and was sure to do those first. Interesting. My 5 year old daughter just performed Risk Mitigation on her Perfection project. Awesome.

So what does this have to do with Agile?

Good question. The game of perfection is at its heart a game about problem solving just like Software Development. And I think the observations about how to be efficient at Perfection can provide some insight in Software Development and Agile Software Development in particular.

If we wanted to complete the comparison to Agile Software Development one could look at the following analogies:

1)      The Perfection Board can be thought of the entire solution for the project

2)      All the shape pieces are the entire backlog of User Stories for the project

3)      The small number of shapes in hand is the iteration backlog

4)      The placing of the shapes in the board is the iteration itself

 

This leads to the following observations on the process:

1)      Creation of small batches can provide additional efficiency

When the process was matching a shape one by one, there was a lot of movement from the board to the backlog of all the shapes. There was more physical movement and it was harder to remember the location of the pieces on the board AND in the backlog to find the required shape. Once small batches were created, it became apparent that the small batches helped to minimize the amount of motion AND help in the memory of the location of the pieces. Although the board was still the same size, the ability to locate the piece in your hand was much easier. It is much easier for a human brain to focus and remember 5-6 items versus 30 items.

In addition, the small batches provided feedback on our progress throughout the game. You got a much better sense on how you were doing by the duration of the iteration as compared to prior ones.

Iterations assist in minimizing movement, providing focus, and maximizing feedback.

2)      Creation of small batches can group like items together further saving on motion and possibly waste.

One thing that certainly increased the probability of success was when you had successive pieces that ended up being located beside each other on the board. I think this is very analogous to planning User Stories on a project. If you can group the User Stories together in the same iteration, it should save on rework that might be required if you did them separately. In addition, it will also save on subsequent context switching to understand that aspect of the solution again in the future.

I am taking artistic license here by comparing the physical movement of the piece to proper spot on the board to the act of understanding the context of that area of the solution and proposing that adjacent solution areas may impact one another.  So revisiting areas can cause additional work to gain context and also possibly cause some rework.

In addition, other groupings like risky or hard items can also provide additional value.

Not all User Stories are independent and interchangeable, planning is required

3)      Measurement, feedback and learning are critical to any process

 Measurement, feedback and learning are critical to being better. Although the popping of the board is a negative event, it was a key driver to getting better. I’m not sure my kids would have been focused to improve if there was no reason to improve. (although I would have preferred positive reinforcement versus negative reinforcement.) To become better and more efficient, measurement is required. Without providing goals and measuring performance against those goals, we may never have achieved the innovation in our process.

 Goals and Measurement are required for Innovation, but they cannot lead the process. The goals and measures must be managed by people, people should not be managed by goals and measures.  

Summary

At the end of the day, the one belief I had that was clarified was that I firmly believe the Iterative approach is better suited for Agile Software Development Projects than Continuous Flow.  This was confirmed by the following three observations:

1)      Iterations assist in minimizing movement, providing focus, and maximizing feedback.

2)      Not all User Stories are independent and interchangeable, planning is required

3)      Goals and Measurement are required for Innovation

Although Continuous Flow has great benefits for processes that are independent, repeatable, and predictable, I firmly believe the problem solving nature of Software Development benefits from the planning, execution, and feedback structures of Iterations.

All from a little game of Perfection. 🙂

The #2 Agile Project Management Tool

Why would I write a post about the #2 Agile Project Management Tool and not #1? Because we all know that sticky notes, and physical Kan Ban board and team stand ups are obviously #1, right? I mean what tool could improve upon that? But in addition to the physical sticky notes, there are some other advantages that can be realized by using one of the many Agile Project Management tools out there.

Agile Project Management Tool Objectives

The additional value I think that can be realized are:

  1. Provide mechanism to manage a Virtual Kan Ban board and facilitate project and release planning.
  2. Provide a virtual, web-enabled Project Management tool that can be used by remote team members.
  3. Provide automated reports that can be used to report on project status, velocity, burn up, and burn down.
  4. Create a database of project estimates versus actuals that can be used to improve.

My Search

I know when I started looking around I was overwhelmed with the amount of tools out there. My purpose in writing this blog post is to provide the information that I wish I would have been able to find to help me with my choice back then. I have downloaded and installed each and every one of the five tools that I will be discussing. Now some of these tools I downloaded and evaluated a few months ago so the functionality may have changed somewhat. My apologies if certain aspects have changed, but these tools are all changing very quickly and it is almost impossible to keep up with all of them.

The Candidates

The Agile Project Management Tools I evaluated were:

  1. Version One
  2. Rally
  3. Target Process
  4. Mingle
  5. Agile Zen

 The Rating Categories

I rounded the criteria down to 10 rating categories which I graded the candidates in each. I graded the candidates by a number from 0 to 3. The ratings were awarded based on my review at that time of the functionality. The review was what I would term to be an intermediate review. I tried to go into a good amount of depth, but I also did not have an inordinate amount of time to perform the review. As usual when I do review like this I fill out the numbers and let mathematics define the winner.

  • Internet-enabled (Private) – allows for all team members to remotely log in and review status
  • Virtual Kan Ban – provides a virtual Kan Ban board that all team members can view
  • Manage Physical Kan Ban – allows for the management of the physical Kan Ban board by printing cards and splitting stories
  • Iteration Planning – facilitates the planning and managing of Iterations
  • Release Planning – facilitates the planning and managing of Iterations and Releases
  • Project Planning – facilitates the planning and managing of Iterations, Releases, and Projects
  • Self Hosted – Allows for the client to host the tool. (Easily and with little additional effort or cost)
  • Workflow and Customization – provides workflow functionality and allowing for customization
  • Build Project History – allows for the retention of project estimates and actuals to improve
  • Reporting – provides canned reports to help to report on status.
  Version One     Rally Agile Zen Mingle Target Process
Web-enabled

3

3

3

3

3

Virtual Kan Ban

2

2

3

2

2

Manage Physical Kan Ban

3

3

3

3

3

Iteration Planning

3

3

1

1

3

Release Planning

3

3

1

1

3

Project Planning

3

3

1

1

3

Self Hosted

0

0

0

3

3

Workflow & Customizations

1

2

1

1

3

build project history

3

3

1

1

3

Reporting

3

3

1

1

3

           
Total

24

25

15

17

29

Notables

  • For what I needed out of the Agile Project Management Tools, Agile, Version One, and TargetProcess were at the head of the class. This is because they allow me to manage iterations with a Kan Ban board AND facilitate overall project planning as well.
  • AgileZen probably has the best Kan Ban board with a timer on the duration a story has been blocked. Very nice feature.
  • TargetProcess has a great feature to be able to easily split stories.
  • TargetProcess was the only one out of the big three that allowed me to EASILY host the solution. This was a key differentiator
  • TargetProcess had an excellent Workflow system with the ability to add custom fields and rename standard terminology in the system. Very cool.
  • TargetProcess also had a good suite of canned reports and a facility for me to create my own reports

In Summary

For my needs, TargetProcess was the clear winner. Any of these tools are great choices depending on what you need to do. But given that I needed to host my data and plan releases and the entire project, TargetProcess was a clear choice. It was also a huge benefit that I was provided the ability to customize the solution and workflow. I have learned to appreciate the power of the customization and workflow features and have used continued to increase my use of these features.