Agile software development has been a hot topic for a while now. There are many companies offering training for Scrum Masters and Agile software development plus a host of books on how you could implement an Agile software development methodology in your company.
In truth, many things about Agile software development are quite in-line with LEAN thinking, but there are some differences which I believe makes LEAN a preferable approach over adopting Agile methods. Yet we often perceive these two things to be one and the same. Yet I believe this to not be the case.
According to Boehm and Turner in Balancing Agility and Discipline:
A truly agile method must include all of the following attributes: iterative (several cycles), incremental (not deliver the entire product at once), self-organizing (teams determine the best way to handle work), and emergence (process, principles, work structures are recognized during the project rather than predetermined). Anything less is a “lightened defined process.”
It is a couple of these considerations that appear out of balance with what LEAN is trying to accomplish, namely self-organizing teams and emergence – depending on how these are interpreted. Iterative and Incremental may be as well. In cases where the unit to be delivered is well understood, why subdivide the work arbitrarily?
Mr. Cho, Vice Chairman of Toyota said it best:
Brilliant process management is our strategy. We get brilliant results from average people managing brilliant processes. We observe that our competitors often get average (or worse) results from brilliant people managing broken processes.
Indeed, self-organizing does not necessarily mean making the best choices, just making their own choices. Combine Mr. Cho’s observations with that of Barry Boehm and Richard Turner:
There are only so many Kent Becks in the world to lead the team. All of the agile methods put a premium on having premium people… (p. 46)
And, as Boehm and Turner remind us:
A significant consideration here is the unavoidable statistic that 49.999 percent of the world’s software developers are below average (slightly more precisely, below median). (p. 47)
These grim realities about people remind us of an important point. There is not an unlimited pool of great people to staff our Agile development projects. Furthermore, even our best people have bad days, and individual variation can produce unacceptable results some times. True LEAN thinking seeks out ways to eliminate these risks – to get consistently high performance in spaces where human fallibility can lead to customer dissatisfaction, financial loss, and even potentially loss of life.
It seeks to do so without introducing new wastes in place of old ones eliminated – refactoring and constant testing (continuous integration) aren’t activities your customer would reasonably pay for. We are doing these things because we haven’t considered how we might not. Letting each team discover what’s “best” for them may compete with solid data to the contrary. There’s no issue with the purest sense of emergence, because it could embody continuous improvement, but it also could be perceived to mean “as you see fit, regardless of it is the best known choice at the moment.” In my opinion, it’s software development, not a lifestyle preference that we are pursuing. Preference should take a back seat to data driven choices about which process to pursue.
The question raised is “can we achieve brilliant results in software without brilliant people?” and I truly believe the answer is a resounding “Yes!” To combat long schedules, high costs and poor quality, we must work to eliminate activities which fail to add value. Software development is fertile ground for waste with development policies often implemented as a death-by-a-thousand-cuts. Each production incident generating new checks and balances to make sure that “thing” never happens again, while failing to create quality at the source of injection for more general problems.
We can step back and take another look at how we get work done. We can use simple but effective techniques to keep bugs from ever being written in the first place and from escaping where they are injected. And most importantly, we can shift our employees from thinking about the work to thinking about how we work so that everyone is contributing to the continuous improvement of our software development practices.
If we continue to compare Agile methods only to the worst-of-the-worst waterfall methodologies, then a quote from my mentor seems apt: “a meal of rice and beans is gourmet, compared to a dead carcass on the side of the road.”