A Manifesto for Post-Agile Software Development

In nearly 15 years since the Agile manifesto was penned, an entire generation of the software industry has grown up having known only allegedly 'Agile' methodologies. Their experience has not always been positive.

The 'new' criticisms made against agile – by those who have grown up with it, not those who opposed it in the first place – are rarely criticisms of the agile manifesto. They are, often, reactions against the (abusive) experience of being pushed into processes, behaviours & relationships which are unsatisfactory; whilst at the same being stripped of any power to improve them.

We should always react against people being pushed about, and made powerless.

A manifesto is a small thing. It can fall on deaf ears. It can be interpreted to mean the opposite of what was intended, it can be misused to manipulate people. But if we make the effort to keep in touch with each other, and to keep trying to re-state what was meant, it can continue to be a valuable guide. And so I propose a 15th anniversary postscript.

Manifesto for Post-Agile Software Development: A Postscript

The agile manifesto was not and is not a prescription for people to impose conformity, nor a tool for controlling people.
There is a deeper theme to agile. At the core it is based on trust and respect, promoting workplace relationships which value people. We oppose methods, structures and behaviours which reduce respect and trust, and which reduce people to assets with no power.
Agile will always demand shared learning and shared improvement. Without critical reflection and learning – both from their own experiences and from the wider community – teams cannot remain agile. Without improvement based on that learning, 'agile' becomes fossilization.

Manifesto for Agile Software Development: A Reminder of the Original

The Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Comment

The phrase and much of the bullet point ‘There is a deeper theme...’ comes from About the Manifesto.
The emphasis on continuous learning is for some so obvious as to need no explanation. But some are stuck in a so-called “agile” process which they are powerless to change or improve. The irony of naming such an structure “Agile” would be funny if it weren't so painful.
Ron Jeffries' response to some criticisms of Scrum was: “The essence of what makes Scrum work isn’t the three roles, the five meetings, the one artifact. It’s Inspect and Adapt. When things are not going as you like, you’re supposed to fix it.”
To cry out that without continuous learning and change there is no agile, can be a powerful tool for the disempowered.
Calling for change in a broken process can become a step towards changing broken relationships.
Beyond “Deliver working software. In a team.”, I see two essentials to agile:
• Treat people well
• Never stop learning
Each of these two is only truly possible when the other is also practised.

Go Further, Do Better

Alastair Cockburn was ahead of the game and has been teaching Heart of Agile for a while. He has four essentials: Collaborate, Improve, Deliver, Reflect.
Ron Jeffries and Chet Hendrickson's post on turning the dials up to 12 starts from, ‘Al Smith once said “The cure for the ills of democracy is more democracy”. We say The cure for the ills of “Agile” is more Agile.”’ and sketches what turning the dials to 12 might mean.
Gabrielle Benefield's “Mobius Loop” uses a different language and stipulates a process. At first glance it is much more achievement focussed. The four “corners” of their figure 8 loop are Why & Who; Outcomes; Deliver; Measure & Learn; and the centre crossover of the loop is Options.

An older bibliography

The 'Deeper Theme' : About the Manifesto
Cockburn, the Heart of Agile
Ron Jeffries, Inspect and Adapt

Draft – Comment & Contribution Welcome. Updated September 2019.

One User, Many Computers

I've tried a few solutions for using multiple computers (mostly one MacBook plus one or two Windows machines) simultaneously and I've currently landed on http://synergy-project.org/ as the One for Me.

It's very good. It's pretty seamless (last year less so, this years seems perfect) : put 3 machines next to each other, move your mouse across the 3 screens, and control and type into whichever computer has mouse focus. It's particularly a good solution when some of your machine are laptops and you want to use the laptop screens.

Alternatives I've tried:

VNC and remote desktop style solutions have worked best for me when I have multiple monitors on a single machine. The irritation is when your local monitor isn't as big as you want for the remote machine and you end up with a scrolling window. The itch that remote desktop solutions don't scratch though is when some of your machines are laptops, and then you want to use the laptop screen. Of the various options, TeamViewer and MS Remote Desktop seem the fastest; I haven't yet seen a fast solution for Mac.
When I don't need a gui, I find ssh or similar is really good. Even a modest monitor easily has room for multiple console windows. A reminder perhaps that guis are not always the bee's knees.

The Known Unknowns Matrix

I.T. is not the only industry to have happily latched onto the the former Secretary of State's famous phrase, "the unknown unknowns". It's a good phrase if you must plan or estimate anything because planning & estimating always involve risk.

But we should really consider the full matrix. There are pitfalls in at least two of the quadrants:

	Known	Not Known
Knowns	Things we know, and we know we know them	Things we know but don't realise we know them. Tacit knowledge that we take for granted. Becomes a problem if we are responsible, and fail, to communicate them to people who don't know. Also a problem when we start work in a new context and do not realise that what we ‘know’ is no longer valid here, so they become unknown unknowns.
Unknowns	Things we know that we don't know. We can record the risk, and estimate a cost for investigation & discovery	Things we don't know that we don't know. This is the quadrant most likely to shipwreck plans.

Concerning the unknown unknowns, my experience with doing novel software is that when budgeting for development you should estimate for development, plus learning time, plus developing the things you learned about, plus solving problems you didn't know you'd have. A rule of thumb for novel systems might be, multiply your estimate by ten to cope with the unknowns. And/Or, have clear “abandon the project” criteria, even months into the project. Don't be a dupe for the sunk-cost fallacy.

Less dramatically, my takeaway from this is to use this quadrant when listing risks and assumptions. Just having a space for the possibility of unknown knowns & unknowns can be an impetus to discuss, “risk-storm” & consult, to help your team discover the as-yet-unknowns.

P.S.

I've just read the brief and brilliant mcfunley.com/choose-boring-technology which points out that you can't afford too much novelty. He suggests that for any new project you should grant yourself a limit of 3 novelty chips. When you've spent them, you get no more.

Well, not unless you really can overshoot your budget and timescales by over 1,000%.

Kudos

A slideshare by Danni Mannes on Agile Architecture pointed out to me all quadrants are worth some of our time.

Estimates and NoEstimates

We had a debate&discussion at XP-Man on NoEstimates for which I did some notes. Reading the NoEstimates stuff, I was most attracted to the sense of "Let's not be satisfied with second rate" and of a thirst for continuous improvement.
I was left with the sense (possibly because I already believed it) that there are contexts in which NoEstimates works, and contexts in which it doesn't. But I was very glad to be provoked to ask in each case, "What value if any is our estimate/planning effort adding?" and "Isn't there a better way to deliver that value?"

What is an Estimate?

An estimate for a Project is (1) a list of things to work on; (2) a cost-range for those things; and (3) a list of risks, that is (3a) of Dependencies that 1&2 rely on, and (3b) of things that might cause significant change.

An estimate or plan for a sprint is (1) a list of things to work on, (2) a "cost" (eg story points) for those things and (3) a list of things we are uncertain about, or (4) need to get help with.

The value of a project estimate is to feed-in to (1) A go/no-go decision and (2) seeing things we want to see sooner rather than later (e.g. should we hire more people, do we need help from specific 3rd parties, is releasing in time for Christmas possible)

The value of a sprint estimate is, to see things we need to ask for in advance (ie external help or resources); to give everyone a sense of confidence about what we're doing; to fail-faster, that is to see sooner what we can't achieve.