“Working software” isn’t enough… (Agile Principle #7)

Yesterday, after Lean Coffee, I had a conversation about agile software methodologies with Joe Justice, somebody I greatly respect. I expressed my feeling that the term “agile” has become a loaded one, with many conflicting meanings, and use of it can incite unintended reactions from the community. At the time I didn’t realize that I shouldn’t have said “the community” , as I now believe that it was too narrow in scope and might’ve derailed our conversation a bit. By “community” I meant the software industry as a whole (See: Agile ruined my life and halfarsedagilemanifesto).

We discussed how certain methodologies emphasize the technical team as the boundary for the new way of thinking…emphasizing divisive principles, like protecting the engineers from “the business” so that they can do their best work without interruption. These methodologies overlooks that “the business” consists of people who are also trying to do their best work toward the same goal. I strongly believe that organizational alignment is vital to work satisfaction, and being happy is vital to doing our best work.

I am certain I made some tired arguments about local optimizations that de-optimize the whole, when Joe put us back on track by explaining what “agile” means to him. His guiding agile principle (see:Principles behind the agile manifesto) is the 7th: “Working software is the primary measure of progress.”

I got to thinking about this and it started to dawn on me that this is a very easily misinterpreted principle. The definition of “Working software” can be very broad indeed. If software compiles without build errors does that mean it “works” or if it runs successfully through the happy path?

Let’s say for the sake of argument that the software is bug free; meaning it works exactly as specified and no defects exist. What if the customer doesn’t want it? Or there is no market for this mythical flawless feature? What if that feature was very expensive to produce? We’ve made working software, but was it an effective primary measure of progress? What if the engineering team worked so tirelessly on producing this software that they all hate their jobs? Eric Ries calls the aforementioned “Achieving Failure”: Delivering on time, and on budget a low defect, high-quality product that nobody wants.

I think working software as a goal is a good one, but when we silo the engineering team and “protect” them from “the business” we create an adversarial environment between groups that have the same goal. To enrich the lives of their users by producing an experience so great as to compel the customer to clamor for it and tell their friends.

Maybe a better wording for that principle could be “Delivering amazing experiences to customers at a sustainable pace is the primary measure of success.”

I could go on about the many ways one could misinterpret those words too, but I’ll leave that to the commenters. :-)

This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to “Working software” isn’t enough… (Agile Principle #7)

  1. Andrea Chiou says:

    The first part of your wording for Principle 7 is close to the writings of Steve Denning: ‘Delighting the Customer’. I worked on FEMA projects for many years. We integrated software with other federal agencies and had constant battle over terminology such as for ‘grant’. Sometimes the other agencies wanted a generic term such as ‘funding opportunity’. FEMA could never agree, because a disaster victim doesn’t want to be seen as ‘opportunity’ in a time of pain and anguish (or any other time I suspect).

    Would these same FEMA customers like to be ‘delighted’ in their overall experience – again, it’s an open question on the wording. Yes, in one sense – but in another, they just want to get their assistance in a timely manner – basic needs met.

    Working software was always our goal on that project – so that they could get the payments in a timely manner, and as you may know, that was not always the case, particularly right after Katrina.

    Nice post – and useful to think about the customer and context first, in all cases.

  2. John Quimbly says:

    Sit back and enjoy a 3 minute song. I would imagine this would be a great opener for many presentations.


  3. Dave Rooney says:

    Hey Adam,

    I absolutely agree with the sentiment of your post, but would like to clarify something… I was “doing XP” when the Manifesto was created, and I know that the XP definition of “working software” included acceptance by the Customer. That meant that not only did the code pass all tests, etc., but that the Customer agreed that it met the business purpose it was intended to meet.

    XP is an inclusive process, explicitly bringing the team members and business together. There was no such thing as an “Abnormal Sprint Termination” if the sprint goal was obsolete before sprint end. If something needed to be changed, you changed it. The Customer and the Team tried to avoid messing the contents of an iteration, but it was OK to swap stuff if that’s what made business sense.

    I do understand that there is an attempt to protect the team from meddling management, and I’ve seen plenty of situations where that’s necessary. My experience, though, has been that an inclusive approach coupled with a few iterations of actual progress makes meddling disappear in a hurry.

    It’s amazing how powerful trust can be.


  4. John Hunter says:

    I think one of the problems we keep seeing is that good concepts are not perfect. Working software is a good vision. It is sensible to bring that focus instead of a focus say on writing a book about requirements for 3 years by which time noone wants any of that junk anymore.

    But it doesn’t mean working software is the only thing that matters.

    Your post gets this idea I think. I just see so many arguments against agile boiling down to there is a way you can do agile like things that is totally lame. That means agile is totally lame. I disagree. Agile has some very good principles I think. It is certainly possible to call things agile and have them been lame.

    I do understand people frustrated that agile seems to have become practically meaningless. To me that isn’t much about things like the agile manifesto of decent agile efforts. I still see plenty of value in those things and focusing on ideas like working software. But you certainly can provide working software noone wants and that is lame. I think that really would be caught better in an agile setting as you should try and get working software in users hands really early and see what they are thinking…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s