Wednesday, 4 February 2015

Fragile, Agile, AntiFragile

I have read Nassim Taleb's "AntiFragility", determinedly making way through the dense foliage of maths and philosophy. He seems to classify systems into three types based on their response to stress.
Type 1: Fragile systems break down when stressed, he terms it as negative response
Type 2: Systems that remain robust under stress exhibit neutral response
Type 3: Antifragile systems benefit from stress, this is a positive response to stress

In the world of software projects, I would like to think about those which use agile development methods as belonging to the second type, projects that remain robust under stress. Any project using a BDUF approach; probably would be Type 1.

Change is the quintessential stress in software projects.
How do agile development methods enable robustness under the stress of change?

In my opinion, the Separation of Concerns of business and development and identifying their collaboration as explicit practices (Product Backlog, Sprint Demo, User Stories, Metaphor, Acceptance Test Cases etc.) are the biggest factors that enable the robustness. The separation only attempted to channel the tension between these concerns creatively, and the effect was phenomenal.

Thinking further, are there any software development methods of the third type; the type that enable the projects to benefit from change?
Think about the competitive advantage the project may have if it can benefit from change.
What may be the characteristics of such methods?

I think, the Separation of Concerns of creativity and control could be the basic theme of such methods.
The different activities in a software project can be batched in one of these two categories. Thus story telling, design, coding, pairing are creatively oriented activities where as system testing, regression testing, automation, metrics analysis are controlling activities.

As it is in agile, to benefit from the separation, it is required to identify the principles and practices of their collaboration.

My take on the principles of this method are as follows:

1) Only pigs (from the "Ham-N-Eggs" restaurant) allowed:
The members of the team that create software should at least have their skin in the game.

2) Allow small mistakes. Build resilience.
Use your creativity, even if you end up with small mistakes rather than hold back and lose it altogether.

3) Avoid soccer mom management. Self organize.

4) Employ bar bell thinking. Be mindful of the disproportionate advantage at the extremities and seek to benefit from it.

5) Prefer natural measurements.

6) Use time tested solutions. They have better probability to succeed.

Some practices based on these principles are

a) Tinkering:  Short feedback loops of coding & developer testing.
b) Pairing: Like "teaching to fish", touch base and sit back.
c) Shared incentives: This is a collaboration practice between the creative & control teams where they share the pain & gain, for e.g. on time deliveries, customer delight, (lack of) defects etc.

Other agile practices (including but not limited to) story telling, metaphors, visual management, AT, Rapid Test, Automation, CI/CD and kaizen are also very suitable for this method.

The creative cloud (provisioned as a cloud where any one external don't want to figure out what's'up) will share the time/feature boxed software increments to the control block (provisioned for visual control). Automated regression tests & AT will help the control team to decide about accepting the increment. The control block can plan the version release cycle using their own cadence.

This method will also help in making your cost of control explicit.