Most of the stories we write on our blog is focused towards the “how to” aspect of software development and we have purposefully restrained ourselves from writing about our opinions. We believe in having weakly held strong opinions. But there comes a time when expressing your opinions saves keystrokes.
The question we get asked often is -
Do you do agile?
Now that is a very difficult question to answer. While I wholeheartedly agree with the “Manifesto of Agile Software Development”, we do not do agile. We believe in being agile. While this topic has been done to death on several other avenues, I would like to give my take on it as well.
Photo by Keenan Constance on Unsplash
According to webster, agile (adj) means either
marked by ready ability to move with quick easy grace
(an agile dancer)
or
having a quick resourceful and adaptable character
(an agile mind)
The manifesto of agile software development is an affirmation of common principles formulated as we value X over Y and was never meant as a prescription. However, we now have several interpretations of these principles which are packaged as prescriptions meant to be palatable to larger organizations that are seeking answers to questions from their Project Management Office. It is extremely ironical to see that something as benign as the manifesto for agile software development can lead to Scrum certifications and things as incomprehensible such as the Scaled Agile Framework or Disciplined Agile Delivery.
Agility is not about process but about the mindset. When we train a machine learning model, we have our objective and then derive a loss function. We then take an algorithm like gradient descent to take small steps towards the objective while evaluating the loss function and minimize the loss. Developing an agile mindset for software development is no different. Once you adopt the agile mindset, you will not only practice it for software development but also for customer development, operations and so on.
Agile software development cannot be formulated as a process as it is highly contextual. It depends on the project, team, the problem being solved, the time and the audience for which it is being solved. So I have qualms in treating “agile” as a methodology but not when being agile while we build software. The difference is subtle and the wording is very important.
Failing
Arthur Sasse / AFP
Anyone who has never made a mistake has never tried anything new. — Albert Einstein
When we are little, we learn from our failures. We fall down when we walk and we pick ourselves up. Failures provide us feedback loops which we can use for course correction. This also is the way the scientific method works. Given a hypothesis, conduct experiments or observations that refute the hypothesis and based on the results or observations, refine the hypothesis and finally draw conclusions. Failure and correcting for failure is extremely important for complex open systems. I would submit that the exercise of building software is an open complex system. While we value simplicity and simple software, it is about the most complicated thing we can do.
Embracing simplicity means making choices and not providing choices. And each choice we make is a potential path to failure. The way out is not to avoid failure by providing every option possible but to embrace it by testing options with your users and choosing the one that makes the most sense given the context of the problem you are solving right now.
The earlier waterfall model envisioned a closed system where the requirements were well defined and the means of production were standard and development was equated to a mechanized process. As we know, this is far from reality. Most successful software succeeded not because they produced something that is perfect or had the requirements clearly known but because they were Anti-fragile. Linux is a great example of anti-fragile software. It started out being imperfect and down right useless but now is the most popular operating system on the planet. It did not have a cathedral style central planning and scaled agile processes but it was about creating options and grabbing opportunities as they arose.
In the same manner, the software we create does not exist in vacuum. It exists in the context of a business which is solving problems for its customers while the needs of the customers, offerings from its competitors and the context in which they operate are under constant flux. There is no other option for businesses, but to be agile.
Being Agile
But what does it it mean to be agile? It is not about cargo culting ceremonies such as daily stand-ups, retrospectives, story walls, iteration planning or reviews. It is also not about artifacts such as epics, stories or backlogs. It is about being anti-fragile.
Hercules slaying the Hydra — Hans Sebald Beham, 1545 (flickr)
Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better. — N. N. Taleb, Antifragile
Being agile is a pre-requisite for being anti-fragile. A good software is resilient and robust. For example, a resilient software would not crash the underlying operating system in case of an exception. It would have saved the user’s work and let the user resume from a point when it crashed by probably routing it to a functioning server. This by itself is hard to achieve.
Anti-fragile software will notify the development team about the crash. A crash reporting software will then be used to aggregate the impact on how many users were impacted and based on it will prioritize the fix in the next iteration. The continuous delivery system would then perform a canary deployment to the affected user segment and when it passes the threshold, it will do a rolling update for the rest of the deployments.
Being agile enables us to be anti-fragile as well. Certain user behaviors cannot be predicted at the outright. Imagine you wanted to roll-out a new feature but you are not sure if users would use it. You have three choices,
a) build the feature and roll it out hoping your users would discover and use it
b) ask your users if they would use and how they would use it and then build it
c) build an option and expose the option to launch a feature it to a percentage of your users and then measure how many users who got exposed to the option actually chose to invoke it.
Option c) is harder to build but is not as much effort to build a) or rolling the dice with b). Most of the tooling you build around option c) is something that you can reuse for testing other hypotheses. So it in the sense of maximizing options, it makes sense to proceed with option c).