Anti Agile Patterns Part 2 : The Handover

The Handover

Think about the times when you opened a self-assembly kit and looked at the instruction sheet/pamphlet. How often did you understand it in full without scratching your head and being confused?

This is a classic example of what happens when something is handed over without end-user input in its creation.

• You mightn’t understand it because it’s written in a way that makes sense only to the author but not to anyone who needs to read it.
• You might try to follow instructions but hit a roadblock because an instruction was wrong or left out.
• You need to contact the author to get the clarification and information you need (the info that you should have got in the first place

Your work comes to a standstill while you wait on the info you need from the person who wrote the instruction manual.

• Sounds like an impediment.
• Sounds like your planned work may not be completed within the Sprint.
• Sounds the perfect ingredient for a carry-over i.e. a sign of over-commitment OR a commitment that was prevented from being realised because of bad things getting in the way.

Also, the person who wrote the handed-over artefact is now interrupted from what they’re doing because they’re now being asked questions they didn’t expect or plan to be asked. Their planned work is now being compromised.

We see how a falling-domino-line of frustration and delays arises.

That instruction manual is an example of what happens when work is handed over to you so that you can start/continue/complete your own planned work but without you ever having been involved or consulted with while that document was being created/ developed. 

Imagine all the good feedback you could have given even if they touched base with you while it was authored.

Typical Examples

We can think of many things are typically handed over to or within development teams:

• Wireframes/Visual Designs for entire Epics
• Architectural Diagrams for entire Systems (and see Conway’s Law which states that solution structures match the organisational structure of information flow in an org. in other words, system structures match the org’s departments)
• Code given to QA/QC to test
• Stories presented at Backlog Refinement. This too is a form of handover. Much better that PO/BA conducts informal grooming sessions with a select group of Devs during Story creation so that the Story is continuously and collaboratively created in a way that makes constant sense to the Dev team so that when the Story is presented to the wider team during Refinement, the Refinement process can be as smooth, efficient and effective as possible.

Anti-Pattern Root Cause(s)

The concept of the handover has its roots in physical manufacturing.

The manufacturing of physical objects in the real world is a  repeatable process.

One can imagine handing over a ton of bricks to a team of builders without any problems because the brick is a known quantity and hasn’t changed in composition or size from all the previous buildings the builders have worked on.

Software however different. Every artefact is different from the last one. 

There are two UX designs alike, there are no two code branches alike, there are no two tests like and there are two releases alike even if they are successive releases of the one product. 

Strictly speaking, each release is a different product from the previous release, even though they may share the same title e.g. Booking.com, Paypal or any other app we care to mention.

How To Address

Let’s work with those who hand over artefacts to us on a regular basis and explore the possibility of having regular check-ins, working sessions, work-in-progress reviews so that we or even a subset of the Team so that artefacts are collaboratively developed.

This also means that by the time such artefacts are completed, the Team will be so familiar with them  and that they can pick them up and run with them this as smoothly as possible with as few impediments and much fewer questions to the author as possible.

Less back and forth, increased productivity, a much smoother way of working, **fewer impediments, quicker turnaround, increased velocity with little additional effort.

A win win for all concerned.

***Few does not mean zero!!! 😊

Anti Agile Patterns Part 1 : What is an Agile Anti-Pattern?

What Are Agile Anti-Patterns?

Anti-Agile patterns are processes and behaviours and activities that compromise Agility.

Some are obvious but some are less obvious. This blog will take each one in turn over a course of articles where the format will be :

• What the Anti-Pattern is
• Why its an Anti-Pattern
• The Motive/Mindset Behind Anti-Pattern Advocates
• The Consequences of the Anti-Pattern

The information contained can serve as the basis for coaching people & teams out of anti-agile pattern mindsets and behaviours

Advice to Coaches (Big 'C' Coaches and Small 'c' Coaches)

A small 'c' Coach is anyone and everyone who works within an Agile paradigm and indeed anyone with an interest in Agile delivery. 

All of us can coach and educate one another. 

A big 'C' coach is someone who is employed as an Agile Coach.

The advice below applies to everyone so listen up...and leave our egos at the door:

What’s important is to recognise them when anyone suggests or enacts an Agile Anti Pattern, that we engage with them sympathetically, empathetically, politely and professionally.

Sending people emails and documents explaining why they're wrong seldom works. There is no substitute for face to face conversations or even conversations over the phone.

99% of the time,  people who do things or make decisions that act against Agility actually have good intentions. Such actions/decisions arise from past experiences and learned behaviours. Perhaps such activities were successful or seen to be successful and indeed rewarded when software was delivered in a non-Agile way. 

The tricks that impressed the audiences of yesterday may appear old hat to audiences of today.

When we identify either the intent of or the actual enactment of an Agile anti-pattern, we should positively engage with the people concerned and have a conversation, asking them what they seek to achieve, what their concerns are.

Then we coach them to help them understand to why it’s an anti-Agile pattern, how such things are counterproductive and work with them to get them what they need in an Agile-compliant manner.

Never treat such people with disrespect. As I said, they mean well and remember there was once a time when even the most experienced Agilists were not ourselves aware of Agile principles.

Agile is a journey for everyone, including coaches. The most fundamental Agile anti-pattern is not being given the opportunity to learn in a safe environment.

We hope you enjoy the series...