The Fragile Manifesto

With more and more companies subscribing to and press on the “Agile business” movement it makes sense to go back and take a look at how Agile is applied in software product development and why very often it leads to fragile software and fragile businesses.

Disclaimer: with Agile I mean the exact opposite of Lean, by definition. You will find a lot of debate on this and a lot of people showing everything between the notion that they are the same thing, interchangeable under some conditions or complementary. Hereinafter there is no doubt that Agile is in each and every way orthogonal to Lean. With that out of the way:

Good things first

The Agile methodology brings an immense improvement on product and project management over the methodologies that existed before. It answers very simple questions in a very simple manner. Every person that ever built a product must have had these questions:

Q: What is the scope of the product?

A: What the user needs

Q: What is the priority of the tasks?

A: What the user needs now

It’s actually quite simple, yet until the time that the Agile principles were stipulated, people wasted their time in improvising on the features that they thought users want, on the priorities they set at the beginning of the project and never looking back, ending up with overcomplicated products that nobody wanted, overshooting budgets and release dates multiple times. Agile was known to the business and especially operations world before it became a hype in software development. However, at a time when most companies exercised the Waterfall model, Agile came along to overcome typical patterns like the 9 sins of product development

The 9 sins of product development

Agile responds to these in a simple manner: ask customers what they want and let them prioritize. Focus on constant paced continuous delivery and not a single launch date. Whenever it is needed, pivot: redefine and reprioritize the backlog. Forget titles and structures; the self-organizing team is the center of the development process. Sales and marketing plans are embedded in the process by building together with the customers. Change is embraced and business people are part of the development process on a daily basis. So 8 sins are out of the way, what could go wrong?

The Ninth Sin

The neat and refreshing behavioral pattern of Agile development misses a critical component: the learning process. The learning process creates structural elements at all levels: the individual, the team, the product or the company. Agile manifests simplicity as the art of maximizing the work not done. This largely excludes learning and architecting. Architecture and design emerge in Agile, rather than being designed into the system. Agile leaves little room for the team to step back and consider the System and how it fits to the whole. The Agile team focuses on the sprint and the dailies: namely execution.

Agile also neglects one of the main principles of product management: inclusion of all stakeholders. It focuses on the Voice of the Customer and forgets the Voice of the Business. Admittedly, this works great when the team needs to deliver products of varying design but on a well understood technology stack or prototypes in a contractual (fire-and-forget) manner. Software contractors love Agile. It moves all responsibility to a – usually uninitiated – user, that ends up with something working, that was actually requested but not necessarily what was intended. Here’s a parable:

“Once upon a time a user wanted a shoe factory.

The user visited an Agile team and asked them for help.

After elaborating on what the factory should do, the first user story was defined:

As a user I want a machine that produces left white sneakers no. 46 with laces.

After the promised period, the user was supplied with a machine that produces left white sneakers no. 46 with laces. When the user asked the team about the right shoe, other colors sizes, stripes and so on the team responded that each requirement should be precisely defined and they would be happy to deliver machines that produce them.

The user, underwhelmed, suggested he could have bought a machine that produces any shoe when tuned to do so, but the team responded there’s nothing Agile in that.”

The short parable describes how Agile leads in delineating user requirements in such a manner that solutions deprive the system from the bigger picture and from the general architecture that is required. Stories are vertical and independent.

But stepping back, looking at the system as larger than the sum of its parts that can be well described is mandatory for anything slightly more complex than trivial. Systems architecture is not to be neglected. This is work that is not simple, non-emergent, perhaps not required at the specific point in time, but essential in an existential manner. It allows the team to build the infrastructures that are required to support the system, look at lower priority and future requirements that may not be so well defined as to make it into the sprints.

Agile focuses on technical excellence but this is also a short-lived promise. The current user story produces non-reusable and often non-maintainable code. For contractors, this is again a non-issue. But for product companies it is detrimental. Documentation, i.e. learning, is not Agile. Specialists are not Agile. The company is deprived from continuation and knowledge. The Resource Based View of the firm teaches us that the company is built up from its resources and capabilities. Agile seems to erode these.

The Agile business

Agile businesses also focus on market embracing change and customer requirements here and now. Competitive advantages are ephemeral and can be discarded as long as they do not sustain profits(?). I have argued before that the purpose of the company is to remain separable from its environment while at the same time adapting to the information it receives from it. Remaining separable is done at the cost of spending energy to maintain an identity.

Not every single company operates at the edge of chaos. Rather, sometimes, I have the impression chaos is self-inflicted. Hyper-competition collapses once strategies could deliver sustainable competitive advantages that create market imperfections.

This is architecture and planning at the company level. It is not Agile, but divesting the ability to acquire sustainable competitive advantages is not necessarily the right way to go. However, as companies move towards a short term view of themselves, investing in long term survivability seems more and more banal. Companies seize to invest in knowledge and only care about short term profitability.

Bottom line

Agile is a great tool that, just like every other tool, needs to be used wisely. Ask yourself: do you actually need it? How can it be combined with other methods that deliver on the architecture level? Is the product or market environment so chaotic or do we enjoy being the weather vane?