Focus on results, not activity. Focus on navigation, not agility.
Agile is facing reality. Concerns are being raised on how it’s led to “feature factories.” Elsewhere, going by job advertisements, organizations are looking to diversify out of the Agile whirlpool and are asking for experience with other methodologies — including waterfall!
Agile and “agile”, have misled people across organizational hierarchies. They are seductive. Like any siren call, they seem too intuitive to ignore — until reality transpires.
Activity
Ceremonies, story points, burndown charts, velocity. The minimalist origins of Agile are today replaced by jargon-filled existence. People scrunched up in small spaces for “stand-ups”, Product Owners “grooming their backlogs”, and continuous releases.
Agile teams are always busy shipping features. Managers are expected to make the leap of faith that this activity will result in the outcomes they are paid to ensure; that doing “Agile” with its set of rituals, will result in a more “agile” organization. Except that it does not.
Why? The answer is in the Manifesto itself:
Individuals and interactions overprocesses and tools
Working softwareovercomprehensive documentation
Customer collaborationovercontract negotiation
Responding to changeover following a plan
The left-hand items are all activity-oriented. Plans and tools are on the right. The original Manifesto declared these to be still important albeit relatively less than the left-hand side. This got interpreted as these items not being important. Activity thus became the focus.
Agile is a chaotic bureaucracy that substitutes activity for outcomes. The result — feature factories are only a natural consequence.
On top of that, in contrast to its ethos of being developer and development-centric, Agile now includes a lot of non-technical “overhead”, extinguishing the productivity gains envisaged by the Manifesto.
MVP
MVPs are a way to get to market faster and reduce market risk. The developer or producer cares about this. Not the customer. Customers want finished products — not MVPs.
MVPs work in circumstances where the customer does not have a choice. Want a free email from Google? It was in Beta for years. Customers accepted that — because they wanted free email and an entry into the Google eco-system. High-end software vendors often roll out products that are not fully formed (or are to be “collaboratively developed”).
Early adopters are given various concessions and their experiences are used to refine the product. Outside these two cases, customers always have a choice — and march away from MVP-type offerings as soon as something better arrives.
MVP is a developer-centric construct, as is Agile. This creates a fundamental misalignment with the customer-centric orientation that organizations profess, or desire, to have.
Lean
Agile today is a nebulous fad that has embezzled and (mis)appropriated Lean terms and concepts. I’ve written in more detail
Agile has completely distorted the concept of “
Let’s take an example. Say you’re eating two fruits — a watermelon and a grape. You will cut a watermelon before eating. But will you slice the grape also? No — not normally at least. A grape is eaten whole. Slicing a grape before eating is not “agile” or “value-adding” in any way.
A goal or result is slivered into user stories, which are then delivered in “sprints.” This piecemeal approach totally loses the holistic picture. Instead of delivering value, only features are delivered. Indeed, iteratively delivering extra-finely sliced user stories actually adds waste. The specific waste here is overprocessing. It’s the subtlest of the 8 wastes (TIMWOODS) to detect, and one of the most damaging!
Agile got nothing to do with TPS-Lean, no matter how much it tries to (mis)appropriate Lean terms.
Scalability
Agile is over-extended to the point where it’s presented as a panacea for everything. Agile started in software.
The Agile Manifesto states:
“We are uncovering better ways of developing software by doing it and helping others do it”
The original focus was software for the newly ushered
Today, we see frameworks for scaling agile — across the enterprise!
The ethos of Agile was to put more control in the hands of developers. It was/is software and developer-centric.
This is why “overhead” activities like plans and documentation were given secondary importance, and hands-on factors like autonomy, and self-organization were given precedence. Agile cannot be scaled to an enterprise because it simply does not link to established “systems” for enterprise governance like project management, cost control, risk (documentation), or legal (contracts).
The ethos of Agile is directly opposed to enterprise-grade scaling. SAFe frameworks superimpose enterprise terms to feign comprehensiveness and validity. What they hide is the fundamental philosophical incompatibility between the two.
Waterfall
Agile’s appeal is based on it being the antithesis of the Waterfall model. Waterfall is not the draconian demon it’s made out to be. It works — and has worked in the past.
The rise of Agile coincided with mostly front-end developments for online apps and businesses, valued mostly on paper money. When the systems get more complex, real money is involved or something is mission-critical, the iterative (and nebulous) approach of agile falls short. Traditional methodologies are required. It’s like solving problems.
Some problems can be solved in an unstructured manner. However, more serious, complex, or significant problems always benefit from a
Waterfall represents a systematic way to solve a problem.
It reflects that standard problem-solving approach, adapted for software development. It bakes in a lot of rigor, which is indispensable for crucial projects. It also ties in seamlessly with systems for enterprise control like project management, budgeting, risk, legal, etc.
Most importantly, Waterfall it is not, and was never, purely linear. It embraces iteration and flexibility when required. The horror stories of Waterfall, exaggerated to justify Agile, are mostly sensational tall tales.
Agile = Agility
Doing Agile does not make an organization agile.
Agile only enables faster iteration. Iteration is just one component of agility. This is similar to how clock-speed, the most popular specification of a microchip, is only one indicator of its processing capability.
Agility is the foremost buzzword today. It’s seductive and impossible to argue against. Everyone wants to be seen as being agile. This has totally overshadowed the nuance of agility. To illustrate, take the example of sailing. A windsurfing sailboard navigates very differently from an ocean liner. Both are agile, but in very different ways — which are neither interchangeable nor generalizable.
Pivots, MVP, iteration, Agile.
Agility has been reduced to a homogenous and formulaic imperative that can be applied universally. It’s not.
Agility is one attribute of the broader and more strategic ability of an organization to navigate. Agility has been conflated with navigation, and portrayed as the rulebook for it. It’s not.
By promoting activity and movement over outcomes and navigation, Agile and “agile” induce myopia and destroy organizational efficacy.
Product (and software) development is a means towards an end.
That end is sales (product -> revenue) and satisfaction (customer -> market).
Managers need to understand this. They need to prioritize outcomes over activity and navigation over movement.
The dogmatic push of Agile, agile, and agility, has only created feature factories and avoidable flux. Managers and organizations need to stop being misled by these seductive fuzz-words(fads + buzzwords).
