Using Planning PokerTo Increase Collaboration and Gain Consensus

One of the interesting aspects of Kanban is its attitude towards estimation. There are some in the community of kanban practitioners believe that estimation is an unnecessary activity.

I asked for clarification during a recent conversation with David J. Anderson, and his opinion was that estimating was a good thing to do, provided the following 2 points:

1. estimates could be created quickly and cheaply
2. estimates produced were of high-quality

Recently, we have been supplementing what started off as a largely "pure" Kanban project with more and more agile style practices. One of these which is getting great traction is planning poker, a collaborative estimation game.

Our rationale for doing planning poker actually has very little to do with getting good estimates. My colleague, Alexis Hui and I were actually a lot more concerned with getting more team buy-in towards commitments made, collaboration on what the solution should look like before delivery started, and better consensus between architects and developers.

What is interesting is that we limited the estimation range to be between 1 and 13, if something could not fall within that range we needed to break it up or do more research before completing the estimate. Prior to this meeting, I had already provided estimates to the executive sponsor where every story simply equaled 8 days each. As each story was estimated during time poker, the numbers typically were either 5 or 8, and only occasionally did they fall outside that range.

The total estimated number created by the planning poker sessions were almost identical to the ones were all stories equaled 8. So was the estimation session a waste of time? Absolutely not, the one thing that I've noticed about collaborative estimating games, is that they generate a lot of valuable information, often a lot more valuable information than generic modeling sessions. There is something about thinking about how long something takes that causes the mind to shift to a very practical and pragmatic solution. When a cross functional team takes part in this exercise the entire team gets quick alignment around not only what should be done, but how it should be done.

So I'm going to add a third point for when to estimate as an additive to the above 2:

3. When you want to quickly generate information and gain agreement on how to proceed

below are some pictures from the planning poker session:

Using Cost of Delay Functions to Prioritize Product Delivery

In many "agile" projects I’ve been a part of my strategy was to break off specific functions / use case / stories / whatever and delivery them mostly whole one piece at a time. IE in iteration 1 go deliver order entry functionality, in iteration 2 go deliver product fulfillment.

While this approach help keep delivery efficient by breaking up work into smaller units, it does nothing to help business agility. When delivery a product an agile approach is to look at the product from a truly incremental perspective. What is the minimum that one can deliver right now that would meet some basic objectives of the product, what are the next set that would make the product a little better, and so on until I get that ideal product, one releasable piece at a time.

Using this approach means it’s not enough for teams to develop code each iterations that is production worthy. Rather the entire organization needs to think about releasing products to the market in increments.

For this to work the business needs to train them selves to stop asking if they can get the world a year from now, but if they can get a small piece of the world next week.

A colleague of mine, Alexis Hui came up with a very innovative way to manage this approach on a project that we were running. The approach was to extend our Kanban board with a capability and theme map, illustrated below.


The whiteboard was divided into sections based on major capabilities that the product had to meet. Capabilities were further broken up into major project themes that has numerous theme "attributes". Each attribute could be thought up as a feature that could be revisited numerous times over the lifecyle of the project. Each time the attribute required new work a story would be tagged with the theme and attribute.

As an example the provisioning handset capability might have a theme for voice mail that had an attribute for activation and one for de-activation. An initial story would describe the work necessary to provision voice mail on a cell phone with a very simple set of features, a later story would describe fancier features like visual voice mail.

Each theme/attribute set would act as a persistent queue, where stories could be placed.

We then used a concept known as a Cost of Delay Function to prioritize stories. Think of a Cost Of Delay Function as a simple way to profile the impact of not doing a story on the business, or in this case the project. COD, also known as Opportunity Cost, is often graphed as a line showing the relationship between impact vs time, the steeper the angle of the line, the worse the impact is over time. COD can represent financial, political, moral, or other impact that could adversely impact the organization.

While it can be very hard for an organization to know the exact impact over time for not doing a particular work item, one is frequently able to allocate the COD into a broad category or profile. When using COD I recommend using color, or annotations to tag work on a Kanban board to identify it’s COD profile.


Because our project was all about launching a new product, we decided to base our COD profiles loosely on market risk.

Orange tickets represented work items that were necessary to launch the most basic version of the product, the COD on this is represented as a straight vertical line. If we did not deliver these by the target date of the first release then the project would be deemed a failure. These were necessary to enter the market.

Beige tickets represented a second pass at the orange tickets, taking mostly manual bare boned functions and automating them, adding better error handling, and other work to make sure that a fully operational product would support more than a limited pilot. This COD was illustrated as an incremental line starting right way, we were losing money everyday these weren’t implemented, and things would get worse the longer they weren’t delivered. These tickets were necessary to support market growth.

Green tickets represented high end features like customer self care, power tools, customizations features, and market grabbing functions such as keeping a phone number when transferring to the new plan. COD here was illustrated much like the beige tickets, but with a delay before incurring losses, and a more pronounced curve on the line, we didn’t need these features right away, but they were quite valuable later on. These tickets were necessary to steal market share from competitors.

Blue tickets represented longer term investments. Completing a blue ticket did not result in a noticeable business impact. Rather work quality would improve. Architecture work, educating the team on agile practices, refactoring, technical docs, were all profiled as blue tickets. These tickets had a straight horizontal line with a slight upward slope to it, immediate value was not obvious to the business, but not doing them would result in downstream pain. These tickets were necessary to ensure that the IT team could continue to support other market needs at a reasonable pace and price.

The above diagrams shows stories colored by COD. One can easily see which capabilities are more critical to earlier stages of development, and which ones should be done later. It should be noted that prioritization is not as simple as choosing one color, than choosing another, than another. Different business and different projects will choose a different allocation of COD profile tickets depending upon where they are in the product life cycle.

COD allocations are also dependent on the nature of the business they are in, for example start ups will likely face more extinction level events than blue chips, and have more "warm" colored tickets in flight to respond to these events.

It was typical using this approach to revisit an attribute several times. The first story for an attribute may be a blue ticket involving a spike, POC, or actual design. Subsequent stories for the attribute could involve one more orange and beige tickets, depending on the desire for a mostly manual solution or full automation of a component out of the gate. Later stories would often be a series of blue and green tickets necessary to POC new technologies and implement new functionality necessary to support some high end feature.

The one common theme here is that the simple use of color can be used to convey an awful lot of information with deep meaning to the business, helping delivery support real agility.

Why co-located team rooms are important

One of the most valuable aspects of co-locating a team in a common area is that it eliminates a lot of the "us vs them" mentality that tends to happen when team members are working in different locations. I have observed that it is a fairly natural occurrence in teams that are distributed to be less collaborative and helpful to each other if they are separated by distance.

For example, here's an interesting email conversation trail from a previous project between two distributed teams (in the same building but different floors and opposite ends of the building):


Email 1 from Debugging Developer:

Hi Developer B,

I was wondering if processing transaction A is supposed to work for ActionTest. I’m using the following data with an error of “failed to execute called process”, can you advise, thanks.

Data used:

Some complex XML message      

     

Response email from Developer A:

You sent a transaction per below.  The changes were not deployed on the tActionTest.  I will have to rebuild that deployable.  (It was deployed for the end-to-end process, not the test webservice.)

I can't find your request in the logs to check the error.

Thanks,

Developer A

Email 2 from Debugging Developer:

Ok so I guess it shouldn’t work until its been rebuilt right?

Response email  from Developer A:

Yes, I forgot about deploying the test service because I was focusing on the integration model. 

Developer X just deployed the most recent ProcessingComponent changes on the test service, and this included my code updates, so the service should work now. 

ProcessTransactionService fails this sample request as per below:

  

  < Failed OrderDetail(s) : 9084694735  ErrServiceQueryFail

   updateSubscriber_ERROR-1553

and more complex XML/>

Thanks,

Developer A

Email 3 from Debugging Developer:

Great, yeah I see that error now, middleware integration admin logs for ActionTest still times out. I’m not sure why the error occurs, is there any way that I can dig deeper? 

Response email from Developer A:

Look at the ProcessTransactionService.

Email 4 from Debugging Developer:

Any idea what “Failed Tranasaction(s) : 1234567 (error=-65608)” means? I understand that transactions with FDR of 232 and IBC of 456 must be used, so I specified the following request:

Some complex XML...

Response email from Developer A:

Did you intend to address this to me?  I don't know this.  AquaLogicBus is calling the ProcessTransactionService (java).  This error is returned from the ProcessTransactionService.

Thanks,

Developer A

Email 5 from Debugging Developer:

Yeah, I just thought you might know, Developer B might have a better idea.

Developer B, I’m sending the request below to AquaLogicBus and get the error: “Failed Tranasaction(s) : 1234567 (error=-65608)”, tn I used is:  ,

What rules are there for Transaction A?

Thanks.

Response email from Developer B:

But the error is self descriptive...the transaction is not unqiue i.e. processed...you cannot process the transaction twice/more in ProcessTransactionService.

Email 6 from Debugging Developer:

I have yet to trained myself to understand (error=-65608)

I’ll try more numbers even though numbers such as 1234567 and more also do not work for Transaction A, these numbers have not been processed since they were verified by GetStatus of the ProcessTransactionService returning ErrGetStatus.

After a bit more back and forth, finally the Debugging Developer discovered the root cause of the problem. In total, this took 6 hours and ~10 emails. Think this is a good example of the communication effectiveness Alistair Cockburn talks about:

Kanban - Add colour to your work to help the team focus

One of the aspects I find valuable with Kanban, is the work visualization. However, sometimes I find that the work is so chaotic/iterative and collaborative in some portions of the process that the standard columns and rows in the kanban board don't provide enough flexibility. You'll see this when you have one work item that requires separate but related work from multiple team members due to their specialization.

 In these situations, I avoid trying to fit the highly iterative work into columns and rows, and collapse them together into a single step on the board. The problem I run into when I do that, is it becomes hard for the team to figure out who is working on what and what work remains to be done on the work item.

To solve this problem, I apply colour to the work using coloured stickies that I "tag" on work items to denote what's be done on each particular work item.

In this example, the team pulls a work item (user story) into the "Create FitNesse Template and Automate" column of the board. To move an item through this part of the delivery process, requires the team to define detailed acceptance criteria in the language of the domain model, get it into a FitNesse page, and then automate the tests. This requires at least three specialized skillsets, a business analyst who understands the requirements that can help define the acceptance criteria, a developer that can verify that the acceptance criteria can be automated and develop the automation code if needed (fixtures etc.) and an architect/product owner that can review the acceptance criteria. Also, the work is not necessarily sequential and may be done in parallel or require multiple iterations.

To help visualize the work for the team, we applied coloured stickies that are tagged to each work item once something has been completed on it. For example, if the FitNesse template is done and data is defined than we tag it with a red sticky. If automation is completed / not required than it is tagged with a blue sticky and upon review from the architect/product owner we tag it as yellow.

A neat result of this process, is that each team member can immediately tell what item they should be working on. The business analyst just needs to look for work items that are missing red tags, which is a signal for them work. Similarly, blue for developers and yellow for the architects/product owners.