November 2, 2009
The Death of Agile
Agile is Dead, Long Live... what? I'll get to that in a moment (and to spare you the drama I don't have the answer), but first I want to clarify that this post will not cover the entirety of why I believe Agile is Dead, but why I disagree with Joshua Kerievsky and the Gilb's is part of my belief in the death of Agile, so I'm going to start here.
They (the Gilb's and Joshua among others I presume) think that the Agile manifesto is wrong because it does not list maximizing stakeholder value as an explicit, fundamental principle. I think that to make that change would drive a stake through the movement's undead heart and hasten its relegation to software history.
Joshua summed up his position on a twitter response to Alan Francis this morning:
@alancfrancis The manifesto needs this headline: We Value Delivering Value to Customers/Sponsors over Making Working Software.
And Kai Gilb says in his emerging series on the ills of Agile:
Not long before this Kai takes issue with the developer-centric nature of the manifesto and correctly identifies that the items listed in the manifesto are not why we as programmers get paid by the stakeholders. But his conclusion (that its about the stakeholders stupid) doesn't follow from recognition of the developer-centric nature any more than saying that it must follow from the desire for owners and media moguls to make billions off of professional sports franchises that the motivation and drive of the players should be based on those stakeholders' willingness to pay them lots of money.
I had the good-fortune to work closely with some really gifted and visionary executives in my last position at Redbox, and I learned a lot about maximizing shareholder value -- and for those executives this was their motivator. But, it would've been a mistake for them to assume -- and to base their incentives -- on the notion that every employee is motivated directly by that same goal. I always felt uncomfortable with that goal because while I understood it and worked hard to achieve it, my intrinsic motivation was different. And recently -- now that I am back to programming and no longer with Redbox, I understand why:
What drives me to excel at software development has nothing to do with why I get paid to do it. However, long ago I learned the value of making sure my drivers were aligned and complimentary with those of the stakeholders so that we weren't at odds and they would love my results and continue to pay me to do what I loved to do. And it turns out -- at least according to those of us who bought-in to the XP (and later, Agile) value prop -- that maximizing quality can do wonders for stakeholder value, so it was a great way to achieve a win-win.
And it is this notion, namely enabling software craftsmanship is a better value proposition for stakeholders than having the programmers directly focused on delivering value that was the sellable message of XP and Agile.
But why Agile sells isn't why I liked it. I liked it *because* it put the programmer at the center of the effort of programming (crazy notion that), I didn't need the manifesto to tell me that I had to find ways to make the person paying the money delighted with my efforts, what I needed was a way to tell them that I would gladly do so, if they would just let me.
That the message of the XP and Agile community was once "professional programming is about the programmers and customers stupid" was what gave the movement teeth, and ever since then, the community has been trying to soften that blow, include all the specialist roles from CEO to janitor so that no one feels left out, or that their political interests aren't being served. The resultant watered-down drivel has resulted in Agile becoming synonymous with 'good' moved 'development practices' into a footnote in some Agile systems (I talking to you Ken Schwaber and the Scrum folks) and once again made software development about non-technical goals and practices. To once again quote Mister Stephenson I call bullshytt.
So Long, Live, what? Michael Feathers and I started to have this conversation at Agile 2009, and I hope to continue it some day soon. The conference by the way gave me feelings of being on Trantor in the first Foundation book. And like the foundation maybe the answer is that Agile's fall is inevitable, and we need to look at nurturing what was valuable and try to preserve it so that the dark period is shortened.
In the meantime, I've gone back to basics: I'm focusing on being the best programmer I can be and building the best software I can. That I also know to do that in the context of making sure I meet or exceed stakeholder's expectations is simply my way of upholding a symbiotic relationship, not my end goal. My end goal is to write beautiful, useful software. And if I choose to put my name on any other manifestos they won't be ones that subordinate that to anything.
Great post Will. While I don't agree that Agile , or at least Agile principles, are dead, I do agree that software craftsmanship is extremely important and that development teams need to focus on it.
Each person in a company has their own motivations for doing what they do. As you say, as a developer, yours is producing the best software you possibly can. And working within a business context, that means delivering the best software that stakeholders will value. As a developer though, your job isn't ensuring that what is delivered is what users value. In Agile, that's the job of the Product Owner.
No single Agile role - Product Owner, ScrumMaster, Scrum Team - can work in a vacuum. It is the symbiotic relationship of all these that enables businesses to continue and make money. It's the job of a business to have a singular vision, help everyone be on the same page, and motivate everyone accordingly. After all, a business is nothing more than a group of individuals traveling their own paths toward a common goal. With many things though, it's easier said that done.
Posted by: Robert Dempsey at November 3, 2009 1:29 PM"My end goal is to write beautiful, useful software."
But if your goal is to write useful software, does not that mean that your goal is to ALSO meet stakeholders' expectations ? IMHO, meeting stakeholders' expectations = useful
I like to look at it as not delivering monetary value, but as simply making things work as they are imagined they should work.
In that sense, you can write beautiful code because that's what we enjoy most, but also deliver a useful application pretty quickly.
I wish one day I'll be able to spend my time writing non-profit projects, taking my time to make it just right, but never-the-less I'll try to deliver value, lots of nice value.
Posted by: Raimond Garcia at November 3, 2009 7:09 PMHi Bill,
If you are going back to basics: and focusing on being the best programmer you can be, and continuously improving, I'd say you are being pretty agile.
Great post. Always enjoy hearing your thoughts.
Cheers - JR
Posted by: Jonathan Rasmusson at November 4, 2009 3:17 PMAgile's fall is inevitable, but not because it's intrinsically flawed. The IT industry--moreso than say, the accounting industry, or the graphic design industry-- has always been obsessed with trends in techniques, technologies and processes, and Agile is only the latest wave. Software Craftmanship is probably the next.
I think you're hitting on something more fundamental than process industry trend changes, though. You've realized that a project's success (in whatever sense) isn't necessarily dependent on the degree to which all parties are driven by the same thing. That idea is a holdover from the industrial revolution and the factories that defined it. In that world, creativity is not even a desirable attribute of a worker.
In the modern world, all parties need to have *complimentary goals*, but they needn't have passion about, or be driven by the same things. Creativity is now a critical requirement, and people have unique, personal creative drives. For example, a chemist in a chemical company may be driven by a quest for knowledge and scientific discovery, and couldn't care less about the income he'll generate for his employer. Despite that, they have a successful symbiotic relationship: the company provides colleagues, lab facilities and funding for equipment and supplies, and he provides discoveries from which they'll earn money.
XP is 'good' in the sense that it treats developers like people, not cogs in a hierarchical process. You see Agile failing in places where it's been co-opted by factory thinking.
Posted by: Aaron Longwell at November 4, 2009 5:23 PMApplying Technology is not Technology (July 5, 2006)
Knowledge Nodes (April 2, 2006)
How to Start an Interplanetary War (February 14, 2006)
XP Exaggerated Redux (February 10, 2006)
Job Postings (February 2, 2006)
Competition (January 31, 2006)
Automatic Discipline (January 26, 2006)
Free Features (January 25, 2006)
Asking about Trust (January 24, 2006)
(All Entries...)