"Harry and Rupert present a survey of the cults, sects and heresies they’ve encountered while working with people “doing agile”, culminating in their formulation of a new “ad-hoc” manifesto. Doctrinal purists are invited to be appalled."
Yeah. Seemed like a great precis for a keynote did that, six months or so ago. And we are still going to do that: or at least there will be cults, there will be sects and there will be heresies. Actually, you know, there's only one word in there which is actually wrong: "culminating". The fascinating thing about agile practises, or at least one of the many fascinating things, is how many people who practise them have read so little about them. Us, for example. I/Harry was at a session at UKGovcamp the other week - nice unconference, strongly recommended - and there was a session called "Agile sucks". The majority of people there - myself included - couldn't tell you how many tenets there were in the agile manifesto.
So we could start with a survey, and end with an entirely new manifesto, for sure. However, the more time we spent actually researching what we were going to say, actually looking outside our little bubble of experience, the more we found this.
I mean, it rocks, it really does. It's ace. You need to go back and read it.
We could stop there, but it'd seem a bit of a cop out. Hagiography isn't really my thing, and we given we disciples promise to question, criticise and iterate we'd be letting the prophets down if we didn't. So here goes. A new precis.
"Harry and Rupert critically re-examine the agile manifesto in the light of their working with people “doing agile”, vaguely alluding to the cults, sects and heresies they’ve encountered and mostly dodging the responsibility of formulating a new “ad-hoc” manifesto."
Doesn't really slip off the tongue, does it?
One thing we won't change.
"Doctrinal purists are still invited to be appalled."
Obviously.
Set the Manifesto in its history. It is 2001. When people thought of "famous software engineer", they probably thought "Bill Gates". Maybe Linus Torvalds, if they read Time magazine. In 2001 there was no Minecraft, there was no Big Bang Theory, no IT Crowd. I'll say that again. A world before the IT Crowd.
What are the apocrypha? Well, they are those texts which were around at the same time as holy writ, but did not make it in. Like theologians, we - Rupert and Harry - have no direct contact with the writer. In our case, because we haven't bothered to mail them. So we can't know directly why the content of the agile manifesto is as it is, but we can attempt an analysis, using the tools of literary criticism, and guesswork.
Extreme programming was two years old.
The Psychology of Computer Programming by Gerald Weinburg was already 30. (Go read that. His concept of ego-less programming is ace.)
The essay cathedral and bazaar by Eric S. Raymond was four.
Scrum was fifteen years old. (Yes, we were surprised too. The word itself was six or seven years old.)
| A Heresy: Scrum is a lousy metaphor. |
|---|
 |
| A scrum is two packs, two groups of people, colliding and attempting to push each other backwards. That is not a good metaphor for constructive engagement. Turns out before then it was "rugby", and oh lord is that better... |
We believe time has moved on since the Manifesto, and that's has made this specific wording less useful, to us at least, than it once was. The difference, we think, here is partly in the mainstreaming of geek culture.
Within the community, there was not the cult of celebrity around developers there is now. The Cathedral and the Bazaar had just been written, remember. We didn't have so many devs who cultivated a personal brand... Probably because the world wasn't so small... Social media has a lot to answer for.
We suspect the Manifesto was juxtaposing individuals against an industrialised process. Artisan against menial. That's done now, and while we must guard against a return to cube-slavery, it might bring a new threat.
The flip side (dark side?) the cult of individual brings with it is the glorification of individual effort over the work of teams. The cult of the rockstar developer. Later on we'll talk about collaboration, but it crops up here too. The opposite of individual isn't necessarily only slave, but also team member. For us there's a triangle there: individual, team member, slave at each apex.
Reducing individuals to slaves, production line workers, call them what you will, makes them incapable of their best work. They aren't capable of responding to change in the way agile demands. Their agency has been beaten out of them. That seems pretty clear.
But it's our assertion that reducing a team member to an individual does the same. Over-valuing an individual makes it more likely they'll place their own interests over those of the team. Over-valuing any one skill set means valuing the skills of others less. It breeds arrogance, specialisation and kills the chances of change. Rockstars are poison to teams.
There's an interesting parallel here with external consultants, we think, valued for their specific skills, not for fulfilling a "role on the team". That occasional import of expertise. The danger is that such expertise is valued purely because it is external. Obviously, this is an odd place for us to explore, because we're often just such consultants. if your consultants do not tread gently around your internal teams, do not respect the skills of others already there, if there's any part of the team's endeavour which is "beneath them", then you want to get different consultants. Yes, you have only a sporadic requirement for some skills, but the people who provide them need to be on the team too. They need to be able to shift their weight when demand changes.
Otherwise you lose the team ethos and shared responsibility that makes good software.
| Heresy: 3 front-end devs, 2 back-end and a delivery manager please. |
|---|
 |
| You can't body-shop an agile team. You recuit by skills, sure. The idea of "inter-disciplinary team" assumes there are disciplines to be inter. However, if you don't bear in mind the difficulty of team-building, your agility will be compromised." A team is not a collection of individuals. |
An agile team is inter-disciplinary team made out of specialists who have respect for other members, don't assume others' jobs are easy. Human interactions are so complex than you have to make allowances for each other. Keeping that team ethos is hindered by technological tools of communications that intermediate such that nobody gives their anyone their full attention. Keeping that team ethos together when you're remote is difficult, but it's not impossible. It's hindered by pointless adherence to process too.
| Heresy: Please, for the love of god, shut up. |
|---|
 |
| I'm not even sure this is a heresy, but it bugs the hell out of me. If you have nothing substantive to say in a scrum, say nothing. You don't need to prove you are working, we know that, we trust you and we can see what you're doing on the board. If you have a blocker, if something is getting in your way, say so. If someone needs to know what you are doing, then holler. But if all you have to say is "I am a productive member of the team." then please - don't worry about it, we know. |
We have, however, come to value processes and tools. Not the heavy-weight UML modellers that might have been what the prophets were railing against, but some things we've found handy. Stand-ups, prototyping, CLI... "Information radiators" Dashboards.
| Heresy: Post-it (tm) notes not a panacea. |
|---|
 |
| This will have me burnt. |
| ...have any of you ever seen a post-it note leaving the office on someone's shoe? Yes. That. |
So we'd replace "Individuals and" with "team" - we value "Team interactions over processes and tools"
We've always found it pretty easy to buy into this, so much so that it rapidly becomes a truism, after all, working software is what your sponsors and users want, right?
| Heresy: Documentation is not a crime against agile. |
|---|
|
| We'll gloss over the faith-crimes committed under this tenet, projects with deliberate no-documentation policies, assertions that good test coverage is, in itself superior to documentation simply because it demonstrates working-ness. |
Let's hurry past the minor sins of omission justified by misreadings of this article. Very few people like to write docs, and not as many people read 'em as maybe should. There's a lot of laziness hiding under misreadings of this item.
I/Rupert is guilty as hell. The amount of documentation I, personally, have not written is astonishing. I'm an expert in the field. But I'm not sheltering under this. I'm just an idiot, a short-sighted, lazy idiot.
When they wrote this they weren't talking about the sort of documentation I don't write. They were reacting against decades of oppression by overwhelming quantities of up-front specification.
We shouldn't confuse the futility of writing documentation of what software should do with the noble and necessary work of documenting what software does, and how and why it does it.
Let's focus instead on "Working Software".
Deciding whether a piece of software is working or not turns out to be a really problematic area...
- If you're building a client for an api which doesn't yet exist can you say it is working?
- If your approach was wrong and you've built an implementation which you intend to discard is that working?
Imagine for a moment that we scrub out "working" and replace it with "useful". Immediately our problems above make more sense.
So, "Useful software over comprehensive documentation". Good.
While we're here lets fix the timing problem which can seduce us into reactionary thoughtcrimes, and at the same time we'll remove the stone under which anti-documentarianism born of laziness can hide.
We're a commercial company. We have customers. We like to have happy customers. And we don't get them by contract negotiation. We even like to collaborate with them.
It doesn't even articulate the complexity within a customer organisation: within the customers' departments, their internal politics, their varied opinions. Even within a "customer" organisation, you are in a multi-party world. If you squint, and you are an external agency, and you have a strong product owner in the customer it's close. Maybe it's simply that, actually. maybe it's the sordid commercial accent on customer, and those in that world have a more sophisticated view of what a customer might be than we do. It's that assumption of supplierness where many more business are now than were in 2001 beginning to understand themselves as software companies: as providers of computerised interfaces to other organisations.
However, it still talks to a bipartite relationship. That's not good enough because it misses out the most important people. The people who will end up using the software you're building. The users. Whether they're direct source; by buying your customers' products, or their your customers employees and it's an internal piece of software you're building, they are the source of value for the software you're building. I mean, we are not the first people to trip over the lack of the word "user" in the agile manifesto, nor will we be the last, but we believe it to be essential.
In order to ensure that user stories are subjected to sufficiently critical thinking I encourage teams to use the variant form:
As a <user type>, I want <function> so that <benefit> . AMEN " (Anonymous sage 2015)
...so that user stories do not become "requirements-by-stealth."
It's not that we don't value collaboration with the customer, and we absolutely, definitely value it over contract negotiation. But we also value collaboration with other folk - specifically, with the people who will use our software. Users. Without keeping them front and central, we do not believe we will make the best software we can. Without listening to their feedback and endeavouring to understand their needs, we will not solve their problems.
Our triangle here is between customer - team - user, with those 2 apexes. We find our best work where we're closest to the middle of that triangle.
So...
And we add to that...
Adding to the Manifesto. Proper heresy. We'll work out some better words later.
Following. Not "being enslaved by..." or "adhering to in the face of all rational evidence to the contrary", or, indeed "having any semblance of"...
Here's a situation:
There's a feature, and it has a user story, in the conversations which formed the user story folk were exemplary in not smuggling implementation instructions into it. The story looks good, resilient. It captures a user need, and couples it to a business objective - most people who read it understand it and can immediately suggest a couple of different ways to fulfil it. Perfect.
At this point someone remembers to add some acceptance criteria, or a definition of done, or somesuch. There's an obvious moment of danger here, the story wasn't prescriptive, but it is much easier for prescriptions to creep into acceptance criteria. But it might be that adding the acceptance criteria at all was the danger. It is hard to write good user stories; writing good acceptance criteria is harder still, since they approach functional specification - which as we all know exists in a quantum state fluctuating between impossibility and futility.
| Heresy: We don't need a plan. We're agile. |
|---|
 |
| You are giving us a bad name. :-) Stop it. Agile can go on and on without clear end: it needs more discipline and a commitment to manage proactively. What agile give you the Manager is more places to monitor. (Don't tell'em, for heaven's sake.) Smaller steps. More chances to see things aren't right. |
Next off some development gets done, some snags arise, approaches are attempted and discarded, conversations are had. All good.
Later some testing gets done. And the feature doesn't pass for all sorts of reasons. Some of which are that the acceptance criteria have failed to keep pace with the rate of change in the approach to delivering the story.
So how many things are wrong in this picture?
What is happening here is a fine example of ritualized "agile" ceremonial.
Envisioning an end state, in this case in the form of acceptance criteria, has contributed this team's return to the false comfort of counter-revolutionary departmentalism. Within the lifespan of this user story there has been a reconstruction of the old scheme - requirements were gathered, a plan was made (which would have looked very old fashioned if we'd not been distracted by the fact that it omitted every thing between A and Z) and then the work was pushed from analysis, to development to test in a micro-re-enactment of the broken waterfall sausage-factory. The development of the software was driven by documentation... just incomplete documentation.
That the testing specialist was unaware of the changing landscape of the story suggests that the team hasn't understood what inter-disciplinary can really mean and is still organizing itself by specialization and processing tasks according to the logic of the waterfall - that one stage cannot begin until a prior one has completed. Imagine that this team had reformed their notion of "working software", that they had set their cap at usefulness rather than compliance. Imagine that they had included the test specialist in all the conversations around the feature. Imagine that the tester had been given the authority their expertees merits, to evaluate the software against the user story without their approach being prescribed by a prior department. Imagine, in fact, that the program of agilism in this team had fully corrected (by which I mean effaced) the uneven power relationships which tend to assert themselves when we relax our vigilance.
It is worth recalling here that we are reading a manifesto. A properly politcal document which aims at fomenting kaizen-revolution. A process which is necessarily incomplete if vestiges of old-think are allowed to shelter underneath rituals and mystifications.
We think we're agile - are we really? The good news is, most of us are a little agile, of only because when your waterfall process goes wrong - all you have left is ruthless focus on the most important things remaining. Most of us do respond to change, because your functional specification will get ripped up when you can feel the winds of deadline rushing past your ears. That's really interesting to me. I don't know about you, but the moments I loved about software development were the best crunches. Absolutely loved them - with the minor caveat that they break you in the end. So when I heard about agile, I looked at it and thought... "Oh, it's crunches but lots of them, and they're all smaller and so less scary. Ace. Sign me up." Get some feedback that needs a change, have a quick chat, get the change in and tested? Great.
| Heresy: Those conversations that aren't. |
|---|
 |
| The ones that leave "agile" as a fractal version of waterfall. A series of very small, badly mapped, waterfalls. That's not bad. Well, it's not as bad as really really big waterfalls. But you need to do better. You need to include the relevant people in the team for example, not just you and another dev, and you need to document what you've said somewhere, and if you use "Oh, we're agile we don't do documentation" as an excuse, I will find you, and I will install IE6 as your only browser. I don't think that's unreasonable. |
Taken to a conclusion - Agile is constant upheaval. It's just not good enough to just respond to change, you have to bring it on yourself.
You have a "definition of done"? You're screwed. Just the word "done". Definition of done limits continual improvement that makes great software (And I nearly wrote great user experience there...) . You are never done. You've just shipped today's best guess, well tested. (You did test everything you shipped, right?) Look, if you want to be "done" have you considered an alternative career? Cabinet maker, maybe? Or possibly a different century? Find a better word for done.
That's it for me. Recognising the absolute inevitability of change, and not just responding to it, but embracing it.
Here we are at the end of a journey of sorts.
We aimed at a new manifesto, we aimed to poke fun at sects and heretics and the fuddy-duddy aged, the set in their ways, the defenders of cant and ossifised process masquerading as agility. The Cargo Cultists. And we have done that a little. But... We were missing the point. When we critically examined the original doctrine, we found what we had expected to rail against just wasn't there. Our solid complaints turned out to be our misconceptions. Damnit, I might even get me one of theose scrum mast er certificates. What we actually found is that try as you might: it's a damned good thing, is the Agile Manifesto. Maybe a tweak or two. Or four, as we've tried for for reasons of neatness really. Oh, and cheap rhetorical flourish, of course. But it's a damned good thing, and if you check back against it often, you'll be OK.
A manifesto for our software development.
- Team interactions over processes and tools
- Useful software before comprehensive documentation
- Collaborative delivery over contract negotiation.
- Something something something users something something
- Embracing change over following a plan.
If we have any wisdom at all, any slight heresy to proclaim as new orthodoxy, then it is these two:
Retain humanity (Remember you serve your software's users as well as your customer...)
Distribute power, don't re-position it. (Remember not to swop the tyranny of process, for the tyranny of individualism. Remember you are part of a team, you are not a rockstar.)
If you can balance those, then you're doing very well indeed.
And always, always, return to the source. Critically re-examine it, re-emphasize it, if you wish. Do not treat it as an orthodoxy, for it is not. We've binned our efforts at creating a new manifesto, and suggest you do too.