The end of year event seemed to go well - it was good to be in a posh, well equipped venue where we didn't have to strain to hear the speaker. The food from Anands was great but my catering estimation technique leaves much to be desired. I thought about how much I usually eat and drink and then multiplied it by the number of expected attendees. Obvious to me now that I lie above the mean.
I was very impressed with David's Kanban Overview and Experience Report - a polished and compelling presentation. The combination of the two common sense ideas in Kanban; making the working state of a team clearly visible through the use of a Kanban board and reducing task switching by limiting the amount of work in process is very attractive to us. It was these two simple things coupled with the collection of simple metrics such as lead, development and engineering time across many tasks which has me hooked. The ability to use this data to quantify the effects, positive or negative, of any adjustments to the system (increased WIP limits, more team members). The ability to use these stats to the team's benefit is significant to me - the simplicity and volume of stats seems so relentless and very difficult to refute. In the past development teams have had gut feelings about whether process/environment changes are good or bad but this is difficult to sell to managers. A Kanban approach seems to give more bargaining power to the participants in the value stream by providing a ton of useful information without over-burdening them with meaningless time sheet style data collection. I've already sourced a mechanical date stamp (as found in libraries) to mark up the transition dates for tasks!
The following day David and Peter came to visit us at NHS Information Centre (NHS IC) where they participated in an introspective by the some of the development team. This was a useful exercise and revealed some interesting problems - none of which were particularly unusual for a development team. It was a good way to focus attention on the good and bad parts of our current process prior to Davids presentation to the NHS IT meeting later that day. The presentation was very well received across the board from senior managers to developers. By the following morning several teams had already made a start on creating a Kanban board and were questioning how their work was structured. Interestingly, they were keen to identify data to collect in order to generate statistics. This level of keenness for time-recording is not common for developers and hopefully reflects a desire for process improvement rather than sticks to beat others with!
Our team (an established team running along broadly xp/scum lines) very quickly had
our kanban board up since we were using a scrum board in Mingle and the transition was relatively painless . What occurred next surprised me as it seems our iterations just vanished. The PM removed the current iteration and after a panicky moment we just shrugged and carried on with no fall as yet as we go with flow.
I have had an uneasy feeling about our sprints recently. For the last few as we had been operating in "release" mode where we had a list of stuff (mostly small "tweak" stories and defects) in priority order. Detailed story point estimation wasn't of much value, we were releasing to UAT very frequently (I'll try to blog about this separately). So when the iterations disappeared I felt like we had gained more than we had lost. Mostly we had a gained a more honest view of the way we were working in practice. We plan to release fortnightly but my guess is that this will converge to a release per feature - this is easier in a web environment.
Coincidentally, we also had a planning meeting on this day too. The planning around the Kanban board placed the focus on the only attendee from the team of 3 customer proxies. He clearly felt uncomfortable making decisions as to what should go into the input queue and the resulting prioritised queue may end up being adjusted after he has discussions with the others. Unlike our previous approach where we planned on a Monday for the following two weeks the flexibility inherent in the Kanban prioritisation process means that we have some leeway in the timing of planning. In some of the prioritisation discussions it became clear that for some features the discussion may need to involve more customers which raised the question as to who really owns the input queue. This is probably not the most shouty and may also change over time. Need to think more about this.
I was aware that there was no real estimation going on during the prioritisation process - specifically we didn't get to play planning poker. Kanban seems to encourage the use of T-Shirt sizing and the collection of data to give lead time values based on historical data values for those T-Shirt sizes. Story point estimation can be used but is often not felt to be of value. This is an area where we need to be clearer and will probably start with simple T-Shirt sizing.
This is as far as we have got will post further updates as we progress and refine.
I'll also post on Peters excellent "Why Do Coders Code" exercise separately.
