I’m pretty much burned out on reading about Agile software development. I spent 2-3 years rabidly reading about it, and now that we’ve been applying it at The Day Job, I’m more interested in solutions and improvements to specific problems and processes I encounter. So the generalized stuff and platitudes you find out there gets to be repetitive and not immediately applicable.
That aside, I liked this post entitled “Application Integration and Agility (1): Understanding Agility” because it wove together Agile think very tightly with Lean think, e.g.:
[T]he core of waste in software comes from the traditional approaches to project management.
…
[As one example:] Tighter scope controls convert the “change control boards” into change prevention boards. And oftentimes teams deliver “to the scope” and not to the real business need, producing useless products that need substantial time to be augmented with functionality that is actually needed.
That is, adding extra process to slow down change can be wasteful because it produced software that (a.) the customer doesn’t want and, worse, (b.) that requires lots of work to make worthwhile.
The first items is the core of what it means to be Lean: you produce only what the customer wants. While the second is a consequence of what you might call The Grand Mistake of Agile Software Development Practitioners: the sense of immediacy and minimalism in delivering “only what the customer wants” often causes you to create software that is not flexible, nor easy to change.
That is, despite what the phrase “deliver only what the customer wants” seems to imply, you do need to think of the future: customers always want more, and they want their software to be quickly modifiable to get that more. They just don’t know they want that until it’s too late. Part of being a good software developer — or any service job — is giving the customer what they don’t know they want. Put another way: the customer is rarely 100% right or complete, where “complete” means “can give you a list of every single thing they want.”
Small Groups in One Room
At the moment, my cure-all for all woes of applying Agile boils down to the well-worn Agile precept: small groups of people, all jammed into one room have the best chance, out of all project management strategies, of creating great software. Really, this practice is what you might call a “theory grandchild” of my favorite project management “law,” Conway’s Law, the conclusions of which point towards having as little hierarchy and lines of communication as possible…assuming you want to produce simple, elegant software. (As an aside, those two things are easy to loose track of when you focus on the naive understanding of “deliver only what the customer wants.”)
Sadly, the legacy world of plan-driven, people-heavy, product-based/shrink-wrap software we exist in is effectively anathema to small groups of people in one room. It’s an odd thing that.
Again With the Google!
As an industry, our prime hope is that The People Who Decide start looking to Google as a successful, new way of doing software development. If old GOOG can stay in the $100′s long enough, it just might stick. Otherwise, it’ll just be a flash in the pan, and we’ll stick with the boring, wasteful ways of developing software. Customers will continue to be “happy” because nothing better exists. The bears will dance!
(With Yahoo!’s last few acquisitions and partnerships with small software development shops, the old Y! might be a beacon of project management hope as well. We’ll have to see.)
Wasteful
So, yes, check the post, it has a refreshing interlacing of Lean and Agile.
And if you figure out how to disrupt the boring, legacy way of doing things, drop us a comment below.
Tags: agile, prjmgmt, programming.
