XP2008 – Day 5

The final morning of the conference was faily quiet again. I did go to “The Agile Technique Hour” which was fun and interesting. David Parsons has posted the materials online, but in brief, we were split into teams in order to deliver features, which were drawings on functionality on overhead acetate. The features were integrated by overlaying the acetate sheats. Neat idea. Initially we had policies in place to inhibit productivity, and gradaully the policies were relaxed to allow us to collaborate better, refactor, regression test, continuously integrate etc.

What I found interesting was that our teams approach was to have a clear vision (a basic bicycle) and to focus on delivering the simplest ‘minimal’ solution for each ‘marketable feature’ and to focus on delivering the ‘minimal viable product’ e.g. the smallest set of features which gave a valuable useable product. In effect, we limited work in progress. We ended up completing nearly all the features without too much trouble (unlike the other team 😉 )

Here’s the final product:

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

XP2008 – Day 4

An excellent workshop by Mary and Tom Poppendieck today entitled “Stop Thrashing: Pull Schedule Techniques for Level Workflow”.  It really left me buzzing, for two reasons.  Firstly, Mary talked about her real experiences implementing a kanban system at 3M which was fascinating, and secondly, I ended up being invited up to the front to share my experiences with implementing a kanban system at Yahoo!

Mary described how 3M moved from an MRP (Material Resource Planning) system which was software based and delivered 60% against plan, to a kanban system which was physical token based and delivered 95% against plan.  The reason it worked was that ultimately, the system was designed by the floor workers who operated it – not by management – so when there were problem, the flow workers understand how to solve them.  To quote Mary, “Computers destroy our capability to schedule”.

The key to a kanban system working is what Mary called ‘setup time’ – the time to get the system ready for production.  A large setup time means that there need to be large batch sizes to be economically viable, whereas a small setup time means that batch sizes can be smaller.  The smaller the batch size, the more just-in-time is possible, and the better the flow.  Setup time for software is generally the merge/test/deploy process and this matched my experience.  At Yahoo! we had a release cycle of one week, because that was how long the release setup time was.  Reducing the time needed for the release process by employing more automation (e.g. testing) would have enebled us to release even more frequently.  One of the goals for a lean manufacturing organisation is ‘single digit setup’, or a setup time of 9 minutes or less.  Mary described a visit to a Toyota factory where the setup time was so small that they were able to achieve a batch size on one – each car in the line was different.

Mary also talked about Building the Empire State which was built in recored time (20 months from the start of the entire project) at a rate of one floor a day.  The bottom floors were being built before the top had been designed by using a number of techniques:

  • Collaborative teamwork between the owner, architects and builders
  • Deigning such that construction was quick and easy (as opposed to cheap)
  • Breaking dependencies so that elements of the building could happen in diffierent orders
  • Focussing on the constraint to enable a flow of material
  • Eliminating waste – for example having restuarants on the buildng during construction

In the afternoon I ran an OpenSpace session on kanban which had around 15 people come along to and I did a quick run through of my latest KFC slides.  There seems to be a real growing interest in the community about these new ideas, and I think the explanations and understands are gradually becoming clearer.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

XP2008 – Day 3

Dave Snowden‘s keynote was entertaining and interesting, although quite a lot of it went over my head.  Dave talked about the need to understand why something works in order for it to scale, with reference to agile development.  His work covers Complex Adaptive Systems, Cognitive Systems and Evolutionary Phsycology and Anthropology.

Some points which stuck out for me were:

  • Adopt a safe-fail experimentation rather than a fail-safe design approach
  • Hindsight doesn’t lead to foresight
  • Manage and monitor boundaries and attractors
  • Measure impact, not outcome

I also attended Lasse Koskela‘s Retrospective Exploration Workshop.  I was primarily interested in seeing how the exercises worked as I’m putting together our own similar course for Conchango as most of the content was based on the agile retropsectives bible.  Unfortunately, there wasn’t really enough time for a good hands-on simulation, although it was enough to trigger some thoughts.  One key thing is to have a shared context which participants to use.  Another conundrum is whether to do lots of powerpoint up front, followed by a full retropsective simulation, or whether to interleave presentation with experience.  One final nice idea which Lasse used was for situations where you don’t have much wall space.  He lifted a table up onto its end, so the table top became a temporary wall which he could stick paper to.

Finally, Sean Hanly spoke about his experiences with a strartup TicketSolve.  This was fairly standard stuff until he mentioned the magic work ‘kanban’!  It turns out that they had difficulty in release planning due to the constantly changing priorities, so adopted a basic kanban approach whereby they only planned short term for the immediate customer needs, and pulled features in iteration by iteration.  It sounded like they had lost some of the big picture as a result which a quarterly planning cadence could have helped with.

As usual side conversations have been as interesting as the main conference.  A theme that has emereged for me is the shift from delivering ‘working’ software to delivering ‘successful’ software.  That’s what Jeff Patton is aiming for, and I think its a goal of the KFC.  Rather than simple asking ‘what do you want?’, ask ‘whats your goal?’ or even ‘what problem are you trying to solve?’.  This helps focus on the value being developed and delivered.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

XP2008 – Day 2

I went to Jeff Patton‘s tutorial on User Story Mapping this afternoon.  I first met Jeff in London last year at XP Day and the Scrum Gathering.  We talked about kanban, and his ideas, and the two seemed very compatible, so I was keen to see how they matched in more detail.  Jeff has also been working with former Yahoo! colleagues Joe Arnold and Aaron Sanders on a kanban related article, so he also sees a connection.

Jeff is trying to solve a number of problems with User Stories that I’ve also seen:

  • they are difficult to prioritise because it is usually a collection of stories that provide value.
  • it can be difficult to understand the dependenies between stories.
  • it can be difficult to understand the whole system from a backlog of stories.
  • creating more smaller stories makes the above even worse!

Jeff’s solution is to break a system down into the following hierarchy:

Goals -> Activities -> Tasks -> Tools
  • Goals are the user centred things which are trying to be achieved
  • Activities are role based themes of functionality
  • Tasks are more specific, but still high level features, which make up an activity
  • Tools are typical more detailed user stories

By creating this hierarchy and generating a physical map using index cards, the relationship between the various parts of the system, and the value that they are delivering, can be communicated and evolved.  Activities form the ‘backbone’ of the system, and Tasks can be prioritised to form a ‘walking skeleton’, or a ‘fully formed, but immature’ system.

From a kanban perspective, it seems to me that the Tasks are similar to MMFs, and are what make up the kanban cards, and that the Story Map is a tool to inform both the value that they generate, and the order in which they should be scheduled.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

XP2008 – Day 1

I’m at XP2008 in Limerick this week. Today was pretty quiet as its all tutorials for the first couple of days, which cost extra, so I didn’t actually go to anything. However, I did hang around and catch up with some old friends.

In particular, I had an interesting chat with Tom Poppendieck about my experiences with kanban systems. Tom felt that while a kanban system was great for small pieces of work such as sustaining engineering, it wasn’t so suitable for larger pieces of work such as new product development. This is counter to my experience that a kanban system using larger MMFs as the kanban actually helps the focus on delivering value with a reduced cycle time.

While generally talking about Lean, Tom also recommended a new book, Ready, Set, Dominate: Implement Toyota’s Set-Based Learning for Developing Products and Nobody Can Catch You by Michael N. Kennedy, Kent Harmon. Another one to add to the reading list.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Upcoming Conference Presentations

I’m really pleased to have had a number of submissions accepted for various conferences this year. I’ve added details onto my Calendar page.

In particular I’ve had 3 talks accepted for Agile2008 in Toronto, one of which is a workshop called KFC Development. I’m really looking forward to sharing my thoughts and getting feedback from attendees which I hope will help clarify the ideas.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Agile North Spring Mini Conference

I gave a short presentation at the Agile North April Mini Conference last Saturday. It was a great half day, and possibly the first Agile conference without any reference to Scrum or XP! Just Real Options and Kanban with Portia Tung, Pascal Van Cauwenbergh, David Anderson and myself.

I’ve added my slides to the downloads page. The talk was also videoed, so that may appear later aswell.

Unfortunately, we all had so much to say that we ran out of time, and I wasn’t able to play my “KFC Games”. Actually, they’re more simulations than games, but here’s some links to what they involve in case you want to try them out anyway.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

KFC Development

I’ve been referring to my latest thinking on development process as KFC Development. Its a bit of a gimmicky name, which makes it memorable, but there is some meaning behind it. KFC stands for Kanban, Flow and Cadence – three lean concepts which I think are important and complementary.

Kanban – Kanban is the mechanism which controls the workflow and helps manage inventory and investment, and identify bottlenecks.

Flow – More specifically One Piece Flow. The one-piece is a Minimal Marketable Feature (MMF) which ensures there is focus on the delivery of actual value. This avoids the temptation to artificially break work down into smaller chunks in order to fit them it into an iteration or sprint. A side effect of this flow, is that typical agile time-boxed iterations can become unnecessary.

Cadence – Cadences give the team the rhythm usually provided by time-boxed iterations. There can be a variety of cadences, from daily stand-ups, to quarterly roadmap planning. An additional cadence is that defined by cycle-time, which determines throughput, and allows a level of forecasting of future work.

I’m hoping to explore these ideas more in the future.

VN:F [1.9.22_1171]
Rating: 5.0/5 (2 votes cast)

Kanban Commitment

In a recent post on kanban-esque scheduling, Brian Marick asked whether using a kanban system to manage software development has enough discipline, and in particular whether there is enough commitment to deliver. I’ve been working on ways to answer this, and recently came to a conclusion, when David Anderson reminded me that Corey Ladas has already said the same thing, which he described as striking a different bargain with the business.

To put it in a nutshell, rather than making commitment on an iteration/sprint/time-boxed basis, you make the commitment on a feature by feature basis. In other words, when a Minimal Marketable Feature (MMF) gets scheduled, you agree an SLA for when it’ll be delivered. As Corey has already explained the concept so well, I’ll instead describe how I came to the same answer.

When we were using a more Scrum-like approach, we make a forecast of what we could deliver on a Sprint by Sprint basis, along with a longer term forecast using the Product Backlog. However, moving to a more kanban-like approach meant that there were no time-boxed forecasts, and the Product Backlog became just a list of things to do no prioritisation and forecasting.

But the business, however, still wanted some idea of what to expect in the coming months, so for the last two quarters, we’ve tried to put together a high level roadmap. The kanban approach meant that we didn’t want to invest much in analysing and estimating a Product Backlog up front. Instead we identified some key MMFs and did some simple T-Shirt size estimates, and based on our historical velocity we plotted out what we thought we might deliver in each of the following three months. This was very quick and high level, such that we planned for Q1 this year in under 2 hours. What we have actually delivered, however, has turned out to be very different due to the usual changes in circumstances and priorities.

That’s a fairly clear indication to me that even such basic estimation in advance is wasted inventory. So how do we set an appropriate level of expectation with the business so that they know when they might get a feature? Cycle time and throughput help, but when MMFs are of varying size, the calculation of when to prioritise can be complicated. On one the Agile mailing lists, Alistair Cockburn recently described the purpose of planning to be able to answer the question “With what we NOW know, what will the most useful system we can create look like on THAT date?” and that’s when it occurred to me that an estimate is just a way of setting an SLA with the business so that they have confidence that if we start something NOW, then it will be done by THAT date.

As a result, estimation can be done in a lightweight way at the “last responsible moment” in order to set an SLA with the business. The last responsible moment will depend on the criticality of the feature. For a more critical feature, the SLA may be required earlier in order to ensure it can be prioritised soon enough. For a less critical feature, the SLA may only be required when it as actually scheduled.

To get back to Brian’s concern then, the discipline and commitment is because the team is saying, as Corey puts it, “When we agree to take on a work request, we intend to deliver it within n days“.

VN:F [1.9.22_1171]
Rating: 5.0/5 (3 votes cast)

A Kanban System for Software Development

Prior to September 2007, my team was using traditional Scrum; a t-shirt sized and prioritised Product Backlog, two week Sprints begun with a two hour planning meeting and ended with a two hour review and retrospective meeting, and Sprint Burndown and Velocity as the primary metrics.

However, despite the team completing Product Backlog Items every sprint, and making regular releases, there was dissatisfaction within the team. The Product Owner felt that the development team was under-performing, and the development team felt that the Product Owner was not giving clear and consistent prioritisation and specification of what needed to be done. Despite numerous attempts to adapt the process to try and resolve the issues, including shorting the Sprint length from four weeks, and altering the level at which we did Product Backlog planning and specification, we were unable to improve sufficiently.

The primary issue was that during Sprint planning, the development team were unable to accurately identify and estimate appropriate tasks, usually because while the Product Owner knew what goals he wanted to achieve, the actual solution was often not yet fully understood. This would be highlighted by a poor Sprint Burndown signature, and the result was a trend to slip back into waterfall-style deliverables to functionally and technically specify work before development could begin. In addition there was a tendency for individuals to focus on completing planned tasks and lose sight of completing the larger feature they were part of. Ultimately, this prolonged the lead time to actually complete and release software.

In September 2007, the team agreed to a change in the process inspired by hearing about Kanban systems at the Agile 2007 conference. The goal of a Kanban system is to minimise inventory, or Work in Process, and maximise throughput of value in the system.

Rather than Sprints, with their Sprint Planning meetings, we have moved to a weekly cycle in which we simply refreshed a buffer, or queue, of the immediate priorities to work. The items in this queue are Minimal Marketable Features (MMFs) – the smallest things which can deliver value on their own. This is different from XP User Stories, which might demonstrate progress, but aren’t necessarily valuable in their own right. The queue was initially sized at seven MMFs, but we recently reduced it to five due the fact that we were prioritising items into it unnecessarily early.

MMFs move from the Queue to WIP when the development team begin working on them. The focus is then on getting the MMF “Done” as quickly as possible, where “Done” means that value has been actually delivered and realised, which invariably means that code is deployed and running on the production servers. Currently we are not limiting WIP, which a traditional Kanban system would.

One of the concerns with pulling MMFs in this way, with little forward planning, was that there was little or no visibility of whether the team would, or could, meet any longer term strategic objectives. To address this, we have added a quarterly cycle, which allows us to set up to three high level Goals to guide the selection of MMFs. These Goals are then linked to a number of key MMFs which are t-shirt sized and provisionally forecast to be worked on in particular months. This probably strictly counts as creating inventory, but is done in a way which minimises investment as much as possible, while allowing some basic release planning. The identification of key MMFs also allows tracking of progress using Cumulative Flow Diagrams and a Parking Lot.

The team also continues to hold retrospectives every month in order to keep inspecting, learning and adapting, and also measures monthly Velocity. In addition, the cycle time of each MMF is measures, from the date it is prioritised into the queue until the date it is agreed to be Done. A mean cycle time can then be recorded every month.

Note that this is not to say that traditional Scrum itself is broken, but that Scrum had highlighted a problem quickly and visibly. One solution might have been to ask the team to spend more time planning to ‘groom’ the product backlog in advance of Sprint planning. However, this feels like suggesting that if the planning is failing, then the solution is to do more planning, which seems to be valuing process over people, counter to the values of the Agile Manifesto. Rather, Lean thinking, and Kanban Systems suggest doing less up-front planning, and valuing focussed teamwork over process in order to deliver value quickly.

VN:F [1.9.22_1171]
Rating: 3.0/5 (1 vote cast)