Sign up to get our featured articles delivered straight to your inbox every month or two.
RSS feed of all articles
Follow us on Twitter
Buzzkill
Alternate dimensions
An Insurgency of Quality
My vision of Agile
Lots of ivory tower software experts cheerfully follow their own muse, but in the world of business, the dreams of money-makers are usually in conflict with the dreams of geeks.
In the business world, software developers have always been the whipping boy. In commerce, the delivered-software never matched the envisioned-software, and the technologists got the blame. Executives have always been unhappy about their inability to effectively direct and exploit software development. The only tool that seemed to get results for managers was to keep programmers on a ridiculously short leash by allocating resources in tiny increments. The results weren’t good, but they tended to prevent colossal disasters, which was, apparently, good enough for business.
Over many years, in self defense, programmers increasingly hunkered down to protect themselves. They aggressively lowered the expectations of their managers. They tried to commit to the least possible performance to avoid blame. All they really accomplished was to avoid good performance.
Nobody was really very happy with that situation, but it was good enough to provide most programmers with a decent living and some self-respect.
But many programmers are more ambitious than that, and most of them are used to higher levels of achievement than just “good enough”. All of that mediocrity has generated a lot of frustration for many programmers. Extreme programming was one method whereby developers could force business people to view the consequences of their decisions.
Extreme programming showed developers that there was power in self-determination, and in reaction to all that old defensive stuff, many programmers have finally said “Enough is enough”. They emerged from their bunkers to become proactive in *guiding* the development process rather than just doing what they were told (and then getting blamed for the failure that results). And agile is the mechanism they used.
I’ve long been an advocate of such technological-craftsman-self-determination. It’s just that I advocated it via the “interaction design” point of view. Therefore, agilists and I are on the exact same wavelength.
Now, there are some agile programmers who think that they are dealing with *technical* issues rather than social ones. If you ask me (no one ever seems to actually ask me), these people are trying to take TWO steps backward: they don’t want to return to the hunker-down phase, so they want to reinstate its ivory tower antecedent, that small-world-coding-happy-place that existed before software went big time. That place has never existed in the commercial world.
To my mind, agile means taking responsibility for making a good product. Even if you used test-driven-development, pair-programming, retrospectives, stand-ups and all of the detritus of “agile” but then built a product that nobody liked or wanted, then it wasn’t agile.
One of the responsibilities of software development is to assure that the right product is being created, and then to create it in the right way. The only way to accomplish this is to apply the best practices of programming, design, and all of the other associated disciplines and crafts. *TRUE* agile means integrating these crafts into a joyful, unified, productive whole.
Filed under: Agile
Comments
Mr. Cooper,
One of the most salient points I recall you making (circa 2002) was the division of labour into architect, engineer and programmer. In my experience, the Agile methodologies still conflate these, with architect still taken to mean engineer and/or programmer with the most scars (the contemporary distinction between engineer and programmer is often one of style, or at most demeanour, and completely devoid of function). Much of the design is still treated as an engineering problem. When we finance software projects up front with lump sums of cash and race until they run out, we are manufacturing an engineering problem indeed.
I have been following your work for a number of years, and have become interested in what appears to be a recent reconciliation on your part with the principal proponents of Agile process models. I agree that to do so was an important move.
I think, however, that to complete the absorption of the Agile methods into a mature, post-industrial model of knowledge product acquisition, there are still elements to address. The outstanding components I perceive include the formal delineation of the architect, engineer and programmer and the relationships between them*, the design of the capitalization and organizational models, and the design of design itself.
(* this was a really good idea!)