{
Adam Ard
}
Three Pillars of Agile
The world is full of agile implementations — especially the world of software engineering. Sadly, the term ‘agile’ is so ubiquitous that it is at risk of losing all meaning. In an industry where everyone practices ‘agile’, how can you deduce anything about the quality of specific processes? What criteria can be used to measure true agility?
The most obvious place to turn is the agile founding documents — the Agile Manifesto and the Twelve Principles of Agile Software. But these are just guiding values and principles, nothing specific. And organizations have taken these documents and gone in many conflicting directions. Some clarification would be helpful.
Below are what I consider the fundamental tenets of agile.
1. Distributed Decision Making
Agile should wrest control from the corporate hierarchy. It should push decisions out and down to software developers. We have moved to an era of knowledge work where managers are the least qualified to make technical decisions, because they are furthest from the day to day operations. Some would even argue they are the least qualified to make product or strategy decisions.
When a group of developers met in Snowbird, Utah in 2001 and decided they valued “Individuals and interactions over processes and tools” and “Responding to change over following a plan”¹, they were talking about distributed decision making. Today, managers are still determining processes, tools and plans. Software is too complex to have anyone other than software developers making technical and product decisions. Agile was meant to stop these decisions from going up and down the chain of command.
Is there value in management? Absolutely. But their role must be modified. They must let go of the industrial-age controls they have retained for decades. It will be an ugly battle. The fact that agile is universally adopted is a bad sign — power never gives up that easily. Clearly, organizations are only partially implementing agile solutions, leaving too much power in the hierarchy.
Some forward thinking companies have grasped this idea, however. For example, “It is not uncommon for Google managers to have 30 direct reports”², rendering micromanagement impractical. At Google there simply isn’t enough time or energy for managers to intrude on the distributed decision making below them.
Morning Star³ is another example. In order to prevent managerial interference, they have removed managers completely. Duties such as hiring, purchasing, setting salaries, strategy and firing are distributed among all workers . This and other manager-less experiments underway today are worthy of study by the agile community⁴. They are literaly showing agile practitioners how to implement their own credo.
2. Close to the Customer
I have heard it countless times: “the business decides what to build, and engineers decide how to build it”. But this is the opposite of how it should be. Agile pulls developers closer to customers and much deeper into the sphere of the “business”.
The practice of assigning a customer representative to engineering teams (sometimes called a product owner) is a disaster. A product owners is a barrier between developers and customers, not a facilitator. He eliminates the direct line of communication. The result is far less useful.
Collaborating directly with customers is uncomfortable for some developers. But, this needs to change. Developers cannot quietly let the product organization take this responsibility. In an agile organization, customer collaboration is the very essence of a developer’s job.
A shining example of proper customer collaboration is explained in the Valve employee manual:
…when you’re an entertainment company that’s spent the last decade going out of its way to recruit the most intelligent, innovative, talented people on Earth, telling them to sit at a desk and do what they’re told obliterates 99 percent of their value. We want innovators, and that means maintaining an environment where they’ll flourish.
That’s why Valve is flat. It’s our shorthand way of saying that we don’t have any management, and nobody “reports to” anybody else. We do have a founder/president, but even he isn’t your manager. This company is yours to steer — toward opportunities and away from risks. You have the power to green-light projects. You have the power to ship products.
A flat structure removes every organizational barrier between your work and the customer enjoying that work. Every company will tell you that “the customer is boss,” but here that statement has weight. There’s no red tape stopping you from figuring out for yourself what our customers want, and then giving it to them.⁵
3. Release Early and Often
To quickly respond to change, you cannot spend long periods of time down erroneous paths. Getting intermediate results in front of customers is the agile way to avoid this pitfall.
Many of The Twelve Principles of Agile Software also supports this assertion:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Working software is the primary measure of progress.
Simplicity — the art of maximizing the amount of work not done — is essential.
Developers should meet often with customers to present their progress. However, the practice of sprints or iterations is a perversion of this principle. The distinction is subtle, but important.
Sprints or iterations (which are used in virtually every agile implementation I have encountered) miss the mark. Software should be released often so the status of software projects can be evaluated, not to impose artificial deadlines or scientific management techniques to optimize developer output.
To “deliver software frequently” only implies a demonstration every “couple of weeks to a couple months.”⁶ It does not require a delivery cadence or a target scope — as is the case for sprints. Sprints are an attempt to restore the unhealthy planning and estimating practices the agile movement condemns. The many ceremonies supporting sprints are agile anti-patterns (Burn-down/up charts, cycle time calculations, story points, estimations, and velocity).
The most compelling example of releasing early and often comes from the Open Source software movement, one of the most impressive examples of a distributed volunteer enterprise in the history of the world. Thousands of developers write and release incomplete software every day to collect feedback and even solicit help from their users — the epitome of “customer collaboration”. The amount and quality of free and open software in use today is breathtaking.
Conclusion
Is there hope for ‘agile’ practices? Will a new movement rise up to eradicate these issues — under a different name? Or will developers invoke the “true” meaning of the Agile Manifesto to lobby for changes in their current processes? Only time will tell. Meanwhile, we can only hope that companies like Google, Morning Star, and Valve and the Open Source community will continue to show us enlightened practices that bring us closer to the original intentions of the Agile Manifesto.
Notes
[1] https://agilemanifesto.org/ [2] https://hbr.org/2013/12/how-google-sold-its-engineers-on-management [3] https://hbr.org/2011/12/first-lets-fire-all-the-managers [4] Many other examples are spotlighted in Frederic Laloux’s Reinventing Organizations and Ricardo Semler’s Leading Wisely podcast. [5] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf [6] https://agilemanifesto.org/principles.html