Religious Rituals in Software Development
Adrian Pickering
Accessible customer communications at scale - sign language, easy-read simplified language, spoken word, readable font, and world languages. Your one-stop-shop to see your messages reach 4,996,466 extra customers.
How often do you pause to question the worth of the processes you practice?
When I think of fundamental, learnt behaviours, I think of Ivan Pavlov's dogs and B. F. Skinner's pigeons.
Pavlov's work is widely known, but in case you missed it, the gist was very simple: ring a bell every time you feed a dog and, after a few repetitions, the chiming noise alone is sufficient to illicit doggy drool as Fido anticipates a meaty treat. B.F. Skinner's work went a little further and used similar animal models of psychology to suggest that free will is an illusion and that even complex behaviours are little more than the mechanical result of robotically following a path set out by neural pathways previously paved by our worldly interactions.
In 1947, Skinner published a paper called Superstition in the Pigeon, describing an experiment he had performed on hungry birds in which he observed operant conditioning - Pavlovian learning whereby the subject modifies its behaviour as a result of the consequences. What made the particular one of Skinner's works so fascinating is that he rewarded the pigeons regardless of their behaviour or environmental artefact and the animals came to associate their immediately-preceding actions as the trigger for their feed. If a pigeon just happened to turn around twice before a pellet dropped into the feeder, it assumed that the merry dance was the cause of this effect. 75% of the animals in the experiment invented their own ways of pleasing the God of Bounty and stuck rigidly to the practice.
One bird was conditioned to turn counter-clockwise about the cage, making two or three turns between reinforcements. Another repeatedly thrust its head into one of the upper corners of the cage. A third developed a 'tossing' response, as if placing its head beneath an invisible bar and lifting it repeatedly. Two birds developed a pendulum motion of the head and body, in which the head was extended forward and swung from right to left with a sharp movement followed by a somewhat slower return. The body generally followed the movement and a few steps might be taken when it was extensive. Another bird was conditioned to make incomplete pecking or brushing movements directed toward but not touching the floor.
Once the habit has formed, breaking it becomes difficult. Indeed, failure of the ritual to elicit the desired result makes the subject try harder and perform the ceremony ever-more diligently.
I see rituals not unlike this across many software development teams. To what end goal is your daily stand-up meeting actually a benefit? I am confident that questioning the Prophet of Scrum (secularly called a scrum master) as to why everyone must speak for five minutes, chanting in turn the Holy Sacraments of What Didst I Do Yesterday, What Shalt I Do On The Present Day and What Blocketh Me will illicit sensible sound-bites such as "It helps everyone know what's going on and allows planning and predictability". Unit testing too has escalated from praiseworthy and righteous into decrees on Test Coverage figures. And code reviews are followed according to The Commandments (sometimes called a checklist) which are rarely as useful or consistently-applied as by static code analysis and always at a greater cost.
Let's have a closer look at a typical daily 15 minute group prayer. Typically, the dogma (or scrum rule set, if you prefer) reads a bit like this:
- The entire meeting must not go on beyond 15 minutes
- All pigs must speak
- No chickens may speak
- Each pig must first describe what they did yesterday
- Each pig must next outline what they expect to do today
- Pigs state what potential impediments may occur
- Stay on topic
- Be brief
- No-one may interrupt
- Erm, except the scrum master if someone isn't brief enough or strays from format or is boring or whatever
and, of course
- Everyone stands
All quite familiar in principle, even if your team differs in a few of the details. Every single one of those points is really quite sensible when examined in isolation but that's no guarantee of operational synergy as a closed system.
Why must the meeting be kept below a quarter of an hour? Well, meetings are expensive - multiply the number of attendees by the duration, then remember that this happens every single day. This can be thought of as a debt of time and the stand-ups, as a net, must reduce your projects' time to market by at least their own sum cost in order to just break even. And that's before you consider opportunity cost. So, of course, keeping the meeting short is really important, but 15 minutes (or ten or however long yours last) is arbitrary. By fixing on time rather than practical result, the scrum master is already unconsciously admitting defeat: "this meeting may not be worth having, but at least it's cheap."
What about the pigs and chickens? I won't regurgitate the bacon and eggs analogy - Bing for it or ask Jeeves if you really haven't heard it before - but this one is a bit of a puzzle to me. Some people need to be heard and need to be heard by everyone. Others just need to listen to everyone. If the chickens are mute for the duration, does this mean that the actions they will take as a result of gleaning the information imparted will be kept secret from the pigs? That doesn't bode well. Or worse, maybe they won't take any action, in which case, one has to question why they even bothered to show up?
The topic of the stand-up is patronising, narrow to a two working day period - obviously programmers have too short an attention span to render anything beyond today and too poor a memory to think further back than yesterday. Putting aside that cynicism, why do we need to talk about the coming day of effort? If it's in the plan, then this is redundant information and those who care to know can find it more efficiently by other means. If there's no such plan (yay for agile!) then who chose One Day and why? Whenever the arbitrary peeps over the pulpit, ask yourself or the appropriate manager who chose that figure and what supporting evidence went into the reasoning. You may eventually get to the answer "because that's what Scrum looks like" which is just pushing the question around without ever answering it.
To me, the most valuable element of the Morning Service is the talk about blockers. If you think something may impede your progress, share that concern with the appropriate people but don't wait until 9am tomorrow when that's 22 hours away. And maybe a discussion, rather than a monologue at the end of your three minute benediction, would be a more productive approach?
Why do we stand up in a meeting? Well, obviously, it makes it a little bit hateful so we keep it as short as possible. But doesn't the scrum master already look after that problem with his stopwatch?
Sprints are another example of the arbitrary (capricious, irrational?) diktat. Every two weeks, we must deliver a thing that offers value. Quite aside from the improbability of everyone in the team climaxing together, what are the chances that all value can be forecast as divided into two weeks of effort at a time? This practices lends itself to redefining value rather than unquestionably offering a true, meritorious increment to the customer.
Much the same criticism can be squared at sprint planning and estimating (of which more in another post). Retrospectives - if they fail to provoke discord of convention - are just another custom sapping your spirit and time.
I am loathed to quote David Brent because the comedic origin may be seen as ligthening the integrity of these words:
Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly.
My take is a little softer than that - process lies somewhere beyond being a short-hand or pattern for a recurring behaviour without the burden of deriving the action from first principles. And it stops nanometers short of being a subsitute for knowing what is going on. If your take on agile is textbook, certified and consistent, I wager your scrum master may lean more to one end of that spectrum than the other.
Our agile rituals are rigidly passed on through manifesto and managerial sermon, preached as the final, unchanging word of god. At least Skinner's pigeons had the imagination to invent their own in the presence of some degree of first-hand evidence.
Credits:
(c) 2016 all words by Adrian Pickering
Book picture by https://unsplash.com/@benwhitephotography
Pigeon picture by https://unsplash.com/@viktorkern
Winner : Queens Award for Innovation 2020
8 年Adrian, You talk complete sense and I wholeheartedly agree. I think that, at a certain point in our careers having seen the merry go round of methodologies come, go and then reappear as the same thing just with a different name, we all come to recognise what's really going on - it's simple commerce. How about you and I create a methodology (let's call it JFDI for arguments sake). It'll be great! A little dash of Waterfall, pinch of Agile, sprinkle of Prince 2 all topped off with a twist of BDD. You write the manual, I'll write the course material for training consultants. We develop a network of sales consultants to sell it into gullible Enterprise clients. This time next year we'll be "millyonairs" Rodney?? Whaddya say?
Entrepreneur and Technologist working on IP Moat, Rehook, Scribe
8 年#peoplenotprocess Great article Adrian, would be good as a session at NorDevCon
Coaching teams to optimize project execution. Just call me!
8 年Very well said. Whether it is, or is not all Scrum (like @Adrian: "not in Scrum's definition"), or Agile is irrelevant. This is what we can observe in many places where people claim to 'be Agile' and 'do Scrum'. A lot of the dances and rituals they think they 'have to' perform are waste, especially once they have become dances and rituals. But apparently people love to perform them. Or, more probably, people are not really different from pigeons.
Thought Provoker / Founder @VXS
8 年Yes, there are a lot of myths about the Daily Scrum. And many of them are slight twists of the original intention. I also wrote on that: https://scrummythsdebunked.blogspot.de/search/label/Daily%20Scrum
Scrum Master at Radian
8 年As Adrian Lander, Lean Agile Transformation / Exec Coach notes, most of what you describe is not really in Scrum. Additionally Scrum is not Agile, it is just a framework which can assist in helping organizations achieve agility. But, it is only a small part of many things which can be done to create an enterprise which can handle effectively the dynamic nature of the environment they create products in. In your defense, there is a cargo cult mentality of people following the rules and not understanding the 'why' of the rules. Unfortunately, your post shows you are one of those who do not understand the why. Not doing something for the wrong reasons isn't necessarily more effective than doing for the wrong reasons.