I had the fascinating experience of being part of a Lean/Kaizen event recently where the facilitator bulldozed a group of fifty people over the course of a week to create a workplan for a couple of months. The idea was for these folks to head off as five different teams to work in concert on delivering the first piece of functionality in a large, complex product.
The traditional waterfall method of software delivery has fallen to as much discredit and ridicule as it has because there was nothing to show for the project team's efforts until the very end and the world could have changed completely by then. More often than not by when strategy and vision got translated to reality, it bore very little resemblance to what the powers that be had in mind - not to mention that the market and competition had transformed enough to make the product obsolete. Then there was the whole business of scope bloat, cost and time overruns.
Lean/Agile is supposed to fix all that and help teams to recover from their mistakes quickly as they continue to deliver their minimal marketable features at the end of each iteration. Sounds beautiful in theory except that the devil is in the details. In the session I went through, the project teams had a lot of inter-dependencies and could not realistically be free-agents that churned out widgets every other week. There were key architecture decisions that had to be made which impacted everybody. Understanding of the full scope of the work and thrashing out the details was therefore critical to success.
Yet, the facilitator kept emphasizing the importance of not getting too far out into the future because change was inevitable. Defer decisions until as late as possible was his mantra. Some of the senior developers were clearly not on board with the idea but had to go along with what the "expert" advocated. At the end of the week, all the artifacts that were to come out of the workshop were ready and to that end the leadership team touted the session as a magnificent success.
There were two or three "open questions" on the table that could depending on resolution trash nearly everything that was accomplished over the week. Our Lean/Kaizen guru minimized the impact that they may have because as far as he was concerned this was "Mission Accomplished" - an we all know how that turned out.
After having worked Agile for years now, time after time I have seen projects turn into tain-wrecks because there was never enough time to get design and architecture right. If you have the foundation laid and a solid blueprint, it is possible that you construct a high-rise in small chunks and stop at a logical point when time or money run out. You have the basis on which to build and know what the end game is.
To expect to work on the foundation and blueprint "iteratively" as you build goes against commonsense and yet that is what the so-called Lean/Agile experts advocate IT shops to do and even more amazingly management buys into this and gets into Kumbaya mode. Just because stuff is not being done in the much derided "traditional waterfall" method is no guarantee of success. We can move Kanban cards on Heijunka boards till the cows come home and will still not have a high quality product to show for it. It never ceases to amaze me how the a process has come to be like a magic charm for success. This is no different than reposing faith on an amulet to cure a disease instead of trusting the advice of a trained medical professional.
Comments