Some riffs on sustainability

Recently, Amitai Schleier, top software development coach, has started re-visiting episodes from his fantastic podcast, Agile in 3 Minutes. If you’ve never listened to it, I will forgive you if you follow that link now, and only return once you have gorged on it. This week, in Pace, he discusses his own sustainable pace and the consequences of exceeding it.

Sustainability of pace is, of course, enshrined in the 8th principle of the Agile Manifesto:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

As Amitai pointed out, sustainable pace is personal to each team member. He noted that he finds it easier to manage his in an environment focused on outcomes rather than hours worked. I suspect this is the case for most of us.

A focus on hours worked is usually symptomatic of a cost mindset. Those who focus on outcomes frequently have a value mindset. The difference is fundamental, but that is a rant for another day - and Darling Wife ™ has Views on the very notion of mindset of her own.

Amitai’s remarks on pace also reinforced for me that describing our usual way of working with the word “sprint” is rather misleading. You cannot, by definition, sustain a sprint. (I’m not entirely sure that I can sell changing “sprint” to “stroll”, though — maybe an “invigorating hike”?)

Anyway, since Amitai has done his usual masterful job with “Pace”, let’s have a look at other aspects of sustainability in software development.

To begin with, I’ve heard some very accomplished scrum masters say that their success with a team is transitory. Over time, a team’s practices will decay. I have taken to describing this phenomenon as “The 2nd Law of Agile Thermodynamics:.

Much like the real 2nd law assumes a closed system, my agile entropy law assumes no corrective inputs, such as would be provided by the coach, or scrum master (or whatever non-denominational title you choose for this role). Given the default tendency of practices to decay, we can conclude that software development sustainability requires change activities: Inspection; Adaptation.

These activities sound awfully familiar, don’t they? The 12th principle of the Agile Manifesto states:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This is congruent with what the scrum masters identified as the solution: The team needs to rediscover health, either through coaching, or finding new ways of working.

Sustainable systems are also easy to evolve. They exhibit the loose coupling and high alignment that enables continued pertinence and increasing business value.

The best known ways of promoting these characteristics are the time-honoured practices of Extreme Programming. In short: Technical excellence.

Appropriate and relevant test coverage, for example, enables you to change the system fearlessly and quickly, evolving the architecture, design, and implementation to accommodate new business needs.

Evolution and diligent housekeeping also keep the dreaded “technical debt” beast at bay.

The manifesto has something to say about this too:

Continuous attention to technical excellence and good design enhances agility.

And this leads me to further reflect: How can you sustain technical excellence if your own professional excellence isn’t enhanced over the lifetime of the product, and throughout your career? How would most managers react to seeing one of their developers reading a book or watching a video tutorial? Shouldn’t we, as an industry, fully own that professional development is something that rightly happens on company time?

I believe it’s our responsibility as practitioners — especially those of us who are looked to for leadership — to emphasise the need for sustainability, to highlight patterns detrimental to it, and to model and advocate patterns and practices that promote it.

One final “no shit, Sherlock!” thought: Software development must sustain itself financially. It has to deliver enough value to your customers that they continue to fund you.

Quoth the manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

What are your thoughts on sustainable software development? Have you seen something done especially well?

Edit: just to prove I’m not a hypocrite, this post was sustainably written with 100% recyclable electrons.