One of my favorite aspects of agile development is that there is no one path or course that developers must stick to in order for agile to work. Teams can use scrum, or not, choose the frequency at which they want to hold retrospectives, and iterate at a pace that works best for their project and personnel.
With all of the freedoms that agile grants you, the one thing you generally don’t mess with is the manifesto.
Many of agile’s biggest supporters find the Agile Manifesto just as infallible as any other sacred document in the world, and to its credit, the values and mantras found inside of it are hard to argue against. “Helping others,” valuing “individuals and interactions,” and “responding to change,” are what any developer should be working toward. But one of the Agile Manifesto’s primary focuses has some in the industry a little confused.
Deliver working software frequently…
What exactly is working software, and do development teams run the risk of severely disappointing their customers if an agreement of its definition isn’t met before iterations start rolling out? When “working software is the primary measure of success,” you better make sure that “working” means the same thing to everyone developing the software, and the customers who are paying for it.
I’m a huge fan of Adam Yuret’s blog, Context Driven Agility, and in a fantastic post, he boldly states, “’Working software’ isn’t enough,” and then explains why.
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?…Eric Ries calls the aforementioned “Achieving Failure”: Delivering on time, and on budget a low defect, high-quality product that nobody wants.
If you’re defining “working” as primarily meaning being defect-free, or even simply meeting requirements—you’re coming up short against your competition that believes “working” means much more. Yuret explains:
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.
Agile expert Scott Ambler touches on each of the Agile Manifesto’s twelve principles, and he does a great job concisely explaining what working software will always contain, no matter what overall definition you and your customers agree on. Ambler writes that working software, “…meets the changing needs of its stakeholders.” Not only is Ambler’s brief statement entirely accurate, it explains why there is no single definition of working software—because your customers’ needs may change, and when they do, what constitutes “working” changes, too.
There are numerous blogs and LinkedIn discussions that attempt to define working software, but in nearly all of them, the answers are so concrete that they completely fail to be agile—which is one requirement that you don’t have to worry about ever changing. Yuret and Ambler both understand this, and their definitions of working software are just as agile as the software they’re working so hard to build.
