Our Situation
My team and I are currently working on a new line-of-business web application, and we had a discussion today about what the best Agile process would be for our current endeavor. Up until last Friday, we have been practicing Extreme Programming (XP). We generally have week-long iterations, starting on Friday mornings and ending on Thursday evenings (so that end-of-iteration crunch time to meet our iteration commitment doesn’t fall on a Friday evening). Friday mornings we have our stand-up, then our retrospective, and then we plan our next iteration. Last Friday, we decided to try out a Lean/pull process for a week. This morning at our stand-up, I was trying to pick between working on a rather large story that was at the top of our “Ready” queue, which I probably could not have finished by the end of the day, and a smaller story just below that is more manageable for today. If we were to continue using Lean/Pull, having the story half-finished at the end of the day is not such a problem, but if we’re going back to XP and fixed-length iterations, I need to make sure there’s no work-in-progress by EOD. This post is about which process we decided to use and why.
Extreme Programming
An advantage of XP over Kanban is our perception that its easier to convey rough estimates of a batch of work to upper management.
My boss (the CTO) routinely meets with the CEO and COO of our small company and they will discuss a strategic new product, or a fairly large module to be added to an existing product. They will collaboratively write a set of stories, and then on the following Friday, the development team will meet to give a rough estimate to each of those stories (or each of the “must haves” if there are a lot of stories). Once we’ve done that, my boss will divide the sum of estimates by our weekly velocity (the average amount of work we complete per week), then multiply by a risk-factor, to produce an estimate of when that chunk of work will be done, and conveys that back to upper management. The estimate and the scope it represents are not set in stone, and everyone understands that. This still has value to upper management, because they can choose to cancel or defer that chunk of work if its expected value isn’t roughly commensurate with the required effort. Also, it serves as a signal to whether or not they should be brainstorming new strategic products/modules, or whether we’re busy enough that it’s not worth-while for the moment. Additionally, the iteration commitment in XP provides a bit of security in knowing that the work currently under construction will be done by the end of the week, which can be communicated to other stakeholders if asked.
In an ideal world (eg. textbook Agile/XP), we would be able to deliver the most valuable features to production in one iteration, generate some value, and build from there. In the real-world (or in our world in any case), there is often a minimum marketable feature set that must be completed in order for a new application to deliver any value in its business context. In our business, our customers are busy and selective, so if you demonstrate something for them that doesn’t do the core functions that sparked their interest, at best: they’re not going to use it in its current state. At worst: they will lose interest in the new product and decline to dedicate any more attention to it in the future. Another factor that can result in a minimum marketable feature set like this is a marketing push. Given a fixed marketing budget, are you going to spend those valuable dollars running that full-page ad in a trade journal after the product has had just a week of development? I think that would probably be unwise in most situations. All of this is certainly not to say we should return to waterfall and decide the scope up front, then do it ‘til it’s ‘done’, etc., but merely that like most things in life, selecting when to ‘launch’ a new application is a balance. You want to launch with the minimum set of functionality that will actually garner the attention of your intended audience, without doing so much up front that you need to do a ton of re-work after it’s used in production and the users tell you everything that’s wrong with it. The trick is to implement A, B and C (if those are the features that are absolutely critical) without trying to deliver D, E and F (the nice-to-haves) at the same time. The problem is that the effort required to build A, B and C often takes more than one reasonably-sized iteration, in the case of a new application.
To sum up, the fixed length iterations used in XP enable us to deliver valuable timeframe estimates to upper management, and I don’t see a way around that in our business context.
Kanban
Kanban is Japanese for “signboard” or “billboard”. “Kanban is a signaling system to trigger action. As its name suggests, kanban historically uses cards to signal the need for an item.” (Wikipedia) We have actually been using a virtual Kanban board for a little while now, as in it’s simplest usage, it’s effectively similar to the XP-style story board (index cards stuck on a ferrous whiteboard with colored magnets) we were using previously. The process change I referred to previously is that we briefly tried out a pull system, where our stakeholders added and prioritized stories in the “Ready” queue at will, theoretically signaled by our completion of work. We tried this rather than having a fixed-length iteration this week, prompted in part by it being a short week due to the 4th of July holiday recognized on Monday.
What attracted us to a pull-system is the flexibility it gives stakeholders to introduce new cards or prioritize cards in the middle of an iteration. (Both are prohibited in XP: scope is fixed for the current iteration and the order of story implementation is selected by dev team members based on the logical flow of work occurring during the iteration.) The other nice thing about it is that it avails us to interesting approaches (like Value Stream Mapping) for maximizing the throughput of new features. (In other words, minimizing the amount of time it typically takes a story to go from conception to production.) It definitely sounds nice in principal, and seems to have worked out well for Toyota.
The down-side of using Kanban when developing a new application is that there’s no apparent way to do the broad estimates that we currently communicate to upper management. Although you can use your calculated cycle time (the average amount of time it takes a feature to go from conception to production) to estimate when a particular feature will be delivered to production, what about the time required to deliver the minimum marketable set of features? It doesn’t seem possible to use cycle time to calculate that, and you can’t use velocity if you don’t have fixed length iterations. Furthermore, the chunks of work represented by the minimum set of marketable features doesn’t seem very compatible with a pull system. The stakeholders aren’t adding a feature to the queue as we get work done, they’re telling us the minimum set of features that are needed before they’re willing to call a meeting with a key client to demonstrate a new application, and that seems logical given the circumstances. Lastly, calculating cycle time and identifying bottle necks becomes much more difficult if the stories moving through the value stream are not similarly sized, and they commonly are not toward the beginning of an applications lifetime, since there is little or no infrastructure in place at the beginning.
Decision
Since the value of being able to produce rough estimates for new applications to upper management exceeds the value of them being able to add and prioritize stories in the middle of an iteration, we decided to go back to using XP for our next iteration. We will continue to use XP on this application (and all new functionality which can’t be fully launched after one iteration) until it is actually being used in production. We will deliver it to a production environment at regular intervals prior to that, and demonstrate it there for upper management. Once the intended users are actually using it in production and getting value from it, we have tentatively decided to try out a pull system again, since it will make more sense to have new features be pulled through the system in response to work being completed once we are getting feedback from the intended audience, and rough estimates will not need to be communicated back to upper management for that application. Does ‘XP for brand new apps, Kanban for enhancements’ seem like a good modus operendi? One thing that occurs to me as I’m reading back over my post is that if had decided to go with a pull system from the start, we could use some estimation methodology that is unrelated to our process (for example some flavor of COCOMO, or SWAG, or you name it), although I gather that the velocity-based estimates we have been using since we adopted XP have been a lot more accurate than estimates given before the company used an Agile process (although I guess that could have to do with adoption of other Agile practices keeping us focused). If anybody reading this has implemented a new application using a pull system under similar constraints, how did you deal with estimation (was it anywhere near accurate?), and was your work queue much larger at the beginning of the project, or was it small throughout?