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...

Agility is a Business Thing Too.

Question: Which of the following statements are true:

• We only use ten percent of our brains
• We lose most of our body heat through our heads
• If you swallow chewing gum, it will stay in your system for seven years.
• Cracking your knuckles will give you arthritis.

(the above links courtesy of Psychology Today) 

Answer: None of them. 

So why do we believe they're true?

My guess is that somewhere back in the fogs of time, there lived a very credible, plausible person who genuinely thought these were true due to misinterpretation of data, evidence or experiment or anecdote or false logic. That person told their friends or published articles with a wide readership and like any well scattered seeds, such ideas took root and grew and spread. Entire societies now think these statements are true!

Such statements that masquerade as facts yet are not facts are sometimes known as Factoids.

And there's quite a few factoids doing the rounds about what Agile is and what it isn't.

Agile is About Faster Software Development, Right?

This common misconception has its roots in at least one of the following:

• Unfamiliarity with the Twelve Principles of Agile
• Misinterpretation of the Twelve Principles of Agile
• Unconscious bias when reading the Twelve Principles of Agile i.e. paying attention to the bits that appeal/confirm one's world view and ignoring the other bits that challenge one's world view.
• Taking bad advice at face value
• Misconceptions within one's professional and social networks that could be widespread and deeply rooted that they feel like the truth. 'So many people can't be wrong, right?'

One of biggest misconceptions held by individuals and organisations is that Agile is something that only applies to developers. Agile is about more work being shoved through the pipeline. 

It's my personal view that the wording & emphasis of some Agile Principles haven't exactly helped.

Let's look at some of those principles for a minute: 

"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale"

and again here:

"Working software is the primary measure of progress"

Good principles of course but a lot of people who read them maybe bedazzled by the phrase 'working software' then they jump to the conclusion that Agile is just a thing for programmers.

But look at this principle below:

"Business people and developers must work together daily throughout the project"

This is probably the most revolutionary and important principle of them all. 

This principle is the well-spring and foundation of what makes Agile successful.

Within this principle, we see the walls that traditionally separate Business and IT departments being dismantled so that everyone regardless of profession or skillset, puts their shoulder to the same wheel of product vision, development and delivery.

So Agile Isn't Just a Programmer Thing? Really?

There's little point in having the fastest, the most talented development team in the world if it takes 6-12 months for a new story to appear on their product backlog from the day its initially thought off due to onerous, long-winded work intake processes

Agility applies to all stages of the lifecycle, from ideation to delivery and everything else in between.

Every step should be conducted as quickly and as efficiently as possible, with business, marketing, technology all working hand in glove at all stages working out the solution and delivering it.

All skillsets advising one another on what's possible, what's not, what's a better way, how about this idea, let's not do it that way etc. 

A world where UX or Architecture or Marketing don’t cocoon themselves for weeks or months and then present (or throw over the wall) a Document for developers/testers to work off only for a bundle of misconceptions to arise thus frustrating development and delivery.

Agile is from the A to the Zee : Ideation to Delivery

Sometimes, the onus of agility and expectation of speedy delivery is unfairly and wholly placed on the shoulders of the development team while those who work in the business/work-intake side of things, are being allowed to carry on at a leisurely pace like it was still 1978.

So much for speed to market. 

So much for being reactive to changing customer needs in these very fluid marketplace and society.

These days when the vast majority of software being used is customer facing and revenue generating, everyone involved from ideation to creation of software is The Business be you a marketing analyst, account executive, UX designer, coder, tester, product owner or scrum master or architect or whatever your role happens to be.

Handoffs - A Parent of Inefficiency

Handoffs are the mother/father of inefficiency.

The very concept has always been riddled with assumptions and indeed arrogance if we think about it. 

The mindset of a handoff can go something like this:

"I'm going to create a Visual Design for a whole new business flow. I don't need to consult with the developers or the product owner or the testers while I'm writing it. I know best and when I hand it over to the developers/testers, they will be able to code/test perfectly from my Visual Design without any questions because my work is so good. If anyone does raise questions, I become frustrated because I don't have time to answer them or attend their daily stand-ups because I'm too busy working on my next Visual Design"

But We Don’t Need to be Agile, We’re Doing Ok

An organisation that doesn't react to or fulfil its customer's expectations risks being severely & swiftly punished in the market place. Such an organisation would need to  swiftly change how it does things or face the possibility of decline and fall. As we have seen since 2008, no organisation is immortal or immune, no matter how big or old it is.

That said, some organisations are such financial juggernauts that they are well cushioned against the consequences of their products being developed in a less than agile fashion. 

Rich Firms vs Bad Apps

Several well known newspaper and magazine apps are notorious for having poor user-experience. 

Often, they are owned by publishing houses who make a lot of money from long-standing investments, advertisement revenue and sales of paper copy even though the latter is in long-term decline.

This means they feel they don’t need to be that Agile or customer-focussed for products such as their apps but in doing so, they're shoring up a lot of reputational debt.

This will surely come back to bite these companies in the not too distant future. Old world revenue streams may last a long time but online revenue streams are on the march. Just as it wasn't wise for a business to invest all its money in gas in 1920 while ignoring electricity, ignoring customer feedback or being slow to respond to customer feedback in the 21st century is just as inadvisable.

Such products may even not be the organisation's revenue lifeblood. 

They don’t make all that much revenue from their apps yet they still survive and prosper on the face of it.

They feel that they don't need to invest in performance or good UX etc. 

Their apps could even be buggy or lacking in good content yet the money rolls in.

Many people's first exposure to their titles are via the app. If the app gives a poor experience and if the company doesn't respond quickly or at all to customer feedback/low Net Promoter Scores, people will spread negative comments to their friends in real life and on social media. 

They will stop using the app. They would be put off buying the paper-copy version as they would assume if the app is poor, so must be everything else associated with the app and its makers.

So, in conclusion, Agility applies to all stages of a product's journey, involving everyone together. No handoffs, just pure constant collaboration and constant monitoring and responsiveness to customer usage data and feedback.