Agile Ice Cream
Agile is a lot like Ice Cream. Delicious and evangelised by some, a bit hard to the teeth for others
// This (long) blog builds on @ChrisCovell (CallCredit) guest presentation to the NHS Digital Agile Community of Practice in November 2016. Agile advocates have a habit of mentioning established techniques and methodologies and forgetting those new to Agile don’t know what they mean.
// You will find this useful if you are new to Agile or need a reference for some of the terms you may hear banded about.
Hello #mynameis Andrew
To draw out a metaphor, Agile is a lot like Ice Cream. Delicious and evangelised by some, a bit hard to the teeth for others. It also comes in many flavours. This blog will take you though some of the flavours you might like to try or suggest some combinations to be avoided.
THE BASIC RECIPE
The ingredients of ‘modern’ agile were laid down in the Agile Manifesto in 2001 and haven’t changed. They are:
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.
What follows are interpretations of this, where academics and organisations have tried out and evolved delivery process to become popular flavours of Agile; Starting with the Big 4.
Note: Common mistakes
Given such a (intentionally) limited recipe, it is not surprising that people have miss-conceptions about how it is followed. Agile has become the Bake-Off Technical Challenge of Software delivery — and it shouldn’t need to be. The ideas are simple if time is taken to understand them, else confusion arises and everyone thinks Ice Cream is bad for you.
“Individuals and interactions over processes and tools” — This has been simplified to “NO DOCUMENTATION!” It doesn’t mean that. It means use collaboration effectively and be self-organising.
“Working software over comprehensive documentation” — This has been simplified to “NO DOCUMENTATION!” It doesn’t mean that. It means iterate, fail fast and learn.
“Customer collaboration over contract negotiation” — This has been simplified to “NO DOCUMENTATION!” It doesn’t mean that. It means put your user at the centre of your team.
“Responding to change over following a plan” — This has been simplified to “NO DOCUMENTATION!” It doesn’t mean that. It means vary scope rather than time and resources and have autonomy within teams.
There’s a pattern here and it means Agile (“Fragile”) has a bad reputation. If you judge all Ice Cream by the value 99p for 5 litres from the supermarket that is 80% water, then you are missing out on a world of enjoyment.
Agile is a soft-scoop ice cream through, it has no set form, it can easily be carved up and served. People have added fantastic things to it, but at the heart is a simple recipe.
THE SPOTIFY MODEL — Chocolate Flavour
The popularity of the ‘Spotify Model’ owes much to the instructional videos viewed over 250 thousand times on YouTube:
It describes how the music streaming service have developed a delivery model that works for them including Squads, Tribes and Internal Open Source. It is practice mirrored by the likes of Sky and has built on the matrix management systems operating in modern business.
However, it works for Spotify because they built it. They are not only in control of the Ice Cream production, but the Ice Cream sellers and the manufacturing machines. They were able to start from a ‘Greenfield’ and build their own industry. They applied Agile to achieve their core guiding principle, Autonomy.
There is no Spotify Model (https://www.infoq.com/news/2016/10/no-spotify-model) other than to start up, fail fast and see what works. It is very difficult to take the idea of Tribes etc. say you are doing it and expect it to work and be fully ‘Agile’. The best you can get from Chocolate is knowing if you like it, feeling comforted that others like it and gaining a little weight.
The Walking Skeleton — Just a Plain Cone
The Walking Skeleton has the principle of delivering working software first at its core. Building a complete delivery pipeline to live (“Hello World”) before adding Ice Cream (features) to the cone. It is predominantly for infrastructure projects and was brought to prominence by Alistair Cockburn’s book “Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams”
It is still used, but has been superseded by “free” off the shelf frameworks such as Amazon Web Services. Enhanced versions (with a flake!) have been developed such as The Walking Skelton on Crutches (https://gojko.net/2014/06/09/forget-the-walking-skeleton-put-it-on-crutches/) that start with a front end solution and build services behind it.
Dev-ops — Neapolitan Flavour
Dev-Ops is flavour of the month. It is hard to go past an Ice Cream parlour (or technology conference) without seeing it FOR SALE. Atlassian (JIRA), Accenture and HP will all make you an offer to install it in your organisation.
The Challenge is that it has almost as many flavours as Agile itself, and none of them taste as good as the original (http://www.jedi.be/blog/2010/02/12/what-is-this-devops-thing-anyway/). At its core is collaboration in a way palatable with those familiar with IT Operations and Service Management. Simplified it means that those responsible for maintaining and scaling the solution are based in the same team that delivers the idea. It has many benefits, especially for mitigating the risks of change to existing services.
It can fall down though where sysadmins struggle to speak the language of developers after generations of working in silos, both of whom then struggle to talk like users. That half scoop of Chocolate, half strawberry always tastes a bit funny. It works well though in small start-up teams where the developer has to be the sysadmin, business analyst and tester; because resource constraints mean everyone is cross-functional.
Communities of Practice — Pick Your Own Strawberry Flavour
Communities of Practice are a methodology for improving performance, not specifically Agile. It is popularised by the writings of Wenger (not that one) who describe it as:
“A Community of Practice is a group of people that share a concern, a set of problems or a passion about a topic, and who deepen their knowledge and expertise by interacting on an ongoing basis”
– Etienne Wenger (1991)
http://wenger-trayner.com/introduction-to-communities-of-practice/
http://blog.ispe.org/communities-of-practice-whats-that.
The community are not just interested in Agile, they also deliver the improved tools and techniques that define an organisation’s best practice.
It is by talking with other people that you can go into the Ice Cream parlour, see all the choices in the 3-scopes-for-£1 offer, and know which 3 will taste nice together.
For this to work though the community needs 2 leaders (or one person with 2 roles). Firstly, someone who is responsible for the network, bringing the group who have a common interest together. Secondly an enforcer to get the group to make a decision on their favourite flavour and get on with ordering it (produce the deliverables). Without deliverables, you just have a group sat in an Ice Cream parlour chatting.
This applies well in large organisations where many flavours already exist and there needs to be improvements. In smaller organisations it’s more important to just get on and deliver something (JFDI).
Good Old Vanilla
These are the big 4, they are popular and include most of the core ingredients. There was once a time though that people only had vanilla, or variations on vanilla that pre-dated the Manifesto and were the popular flavours of their day.
These are the Pure Methodologies and are best described in the book I first read about them in nearly 20 years ago, Avison’s “Information Systems Development: Methodologies, Techniques and Tools”
Such methods include:
· RAD (Rapid Application Design)
· DSDM (Dynamic System Design Methodology) — currently the basis for AgilePM training
· XP (Extreme Programming) — seen now in ‘#mobprogramming’
There are also the Kaizen (Continuous Improvement) / Lean methods that build on the iterative mantra of Agile including:
· Scrum: https://www.scrumalliance.org/why-scrum — where the stand-ups come from
· Kanban — where those boards on the wall come from.
An Eton Mess Ice Cream Sundae
Just as people have experienced Agile as ‘No Documentation’ they have also seen is as ‘Make it up as you go along’. This happens when people take delicious vanilla and contaminate it with unexpected things.
For those familiar with gated delivery models (waterfall, v-model etc.) the replacement of a Prince2 textbook with an Agile coach, who appears to be the only one who knows what is going on, is difficult to comprehend. Unless you join an Agile team or project at its inception your initial experience of the process can only be change (perceived as chaos). This is because week on week the team will be learning and improving, the ceremonies taking place one week may be cancelled the next.
What could be a beautifully presented Pavlova then appears as a mess called ‘Wagile’, where tools and techniques are misappropriated to supplement failing iterative or gated methods. Combining Waterfall and Agile, or more significantly not sharing knowledge of what is going on, is risky. GDS have had some success with this with their gated service manual and service assessments. However, it is not a magic bullet.
Many blogs, most longer than this, can be found describing what is wrong with current trends in delivery approaches (e.g. Michael Church), but it’s more effective to learn yourselves.
Will someone one day create a flavour that tickles your umami taste buds and makes all other flavours redundant?
No. Success looks like you finding the flavour of Agile that is right for you, sometimes only after learning what is wrong with the other flavours.
Best wishes and happy collaborating
Andrew
Andrew Palmer CITP is a quality expert and a Champion for Change at NHS Digital. He has been coaching agile teams since 2008 and is an advocate for continuous improvement in the workplace.
@MRAJPalmer
