Last week I presented to my team at Lime Wire Agile and Scrum in all it’s most excellent glory. Jason Herskowitz, Lime Wire’s VP of Product Management, and I ran though all the major Agile elements and vocabulary words. The best part of the presentation was questions asked by developers, testers, system admins, product managers, and even a couple of chickens. Many of these guys and gals have been the victims of bad Agile programs. It seems easy to play the Agile game but it isn’t. The most critical path to successful Agile isn’t to follow all the rules–it’s to follow all the principles.
The Agile Manifesto’s 3rd principle, Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale, seems to be often ignored. You can not really ignore a principle. A true principle is a law of nature, like gravity or the axioms of geometry. If you ignore the principle of gravity you’re going to get hurt. If you ignore the principles of Agile your project is going to fail.
I don’t know why the delivery of working software is often left out of the plan. Perhaps it’s that to recognize the truth of this principle requires more than just a thin patina of Agile paint on a waterfall process. Most Bagile (Bad Agile) processes do not understand that a milestone without working software delivered is a milestone not met. In Bagile working software is mutated into “ready for QA” or “all P1 bugs closed” or “works on my machine”.
I’m not taking an extreme view of working software! It’s just that “done” should mean “nothing more to do!” I’ve lived through the bitter experience of discovering that done doesn’t mean working software. Nothing is more discouraging than having to wait weeks for a so-called completed project to be ready for release.
If you think about it, delivering working software in this complex world of clouds, grids, restful APIs, and P2P networks, is daunting. It may even feel wasteful to go though all the effort to get the components integrated and tested every couple of weeks.
But true working-ness means you can get feedback before every iteration from actual flesh and blood users. Feedback like this is invaluable to avoid wasted effort.
True working-ness means you can focus on the future and get rational priorities for your backlog with each sprint.
True working-ness means if you want to go on vacation, you leave things in a good state and others can pick it up while you are gone.
True working-ness means true achievement. It’s pretty hard to make lasting, solid achievements in general, but delivering working software frequently means you have made a concrete difference in the life of your users today.
There is a 14th century English saying that taught me the same the principle as a kid: “A bird in the hand is worth two in the bush.”
Comments
4 responses to “True Working-ness”
True and makes sense… question is – how do you define that true workingness. I think management that follows any methodology often concentrates too much on the high level, derivative metrics of success. I hasn’t fully formulated that in my head, but feels like ‘if you want to go on vacation, you leave things in a good state and others can pick it up while you are gone’ is very vague and that is where problem often comes from. My understanding of this differs from other people’s understanding of this, as well as my metrics for reliability. While I can say if(x > 0) then x=0 is perfect piece of code, other people will say it is not. It is not commented it is not checking for x to be not null, etc. etc.
So…what I am trying to say here, without underlying, very well defined metrics for workingness, it is hard to achieve it.
IMHO defining a low level requirements for the system that are driven by high level requirements(think workingness) is an important part of iterative development, or even pre-development actually. Very unagile seems like… However this strict underlying level of constraints, when enforced(this is important(!!!) otherwise it doesn’t work) allows to create environment where higher level agile workingness could be actually better defined and thus easier achieved and better tracked.
I agree with your emphasis on working software, and I’d add that software needs to have actually been used by end users, and not just internal users, for it to really be “working”.
Thanks Alex and Patrick for your comments! I’ll try to address them here but they both deserve further thought.
Alex wrote that my definition of true working-ness is high level and vague while Patrick pointed out that nothing is really working until the end user says so.
Both of these comments point out the fundamental flaw in the idea that software is ever “finished”.
I would argue that “finished” and “working” are two different things. Working software is just that–not done but ready for deployment. (I hope that’s what I said in my original blog post!) Finished software is complete in all senses of the word from both inside (requirements implemented) and outside (user acceptance).
Thanks for clarifying my thinking 🙂
[…] covered the idea of working software in a previous blog post but “preference to the shorter timescale” idea deserves some […]