Slicing your way to agility
All too often organisations use Agile terminology, but struggle to get away from the convention of initially defining a ‘big thing’, that is subsequently broken down into a backlog of smaller things, which all need to be delivered for the big thing to work — or even to merely establish if the big thing works.
This process of deconstructing a big thing usually means that it takes a long time to establish if a) the big thing works and b) people actually want the big thing, especially considering the considerable time it’s taken for it to be built. These represent long feedback loops and instil a culture of rigidity, where the delivery of scope and outputs is prized above performance and outcomes.
The concept of ‘slicing’ can be your friend here. The aim is to find slices of value through a system which can be delivered iteratively. The intention is to allow ourselves to not only deliver value early and often, but also adapt our solution based on how users interact with it.
It’s a concept which is often confused with some kind of deconstruction process. So let’s imagine we have decided to create a dictionary. You may even wish to imagine that we are the first people to ever invent the concept of a dictionary.
There are a number of ways we could begin the creation process. Perhaps the most obvious would be to write the words and definitions in alphabetical chapters. Starting with Aardvark through to Azygous, then moving onto the letter B and Baa through to Byzantine and so on.
The problem with this approach is that an incomplete dictionary — however comprehensive the completed sections might be — is of no use to anyone. I struggle to think of any use for a dictionary that finishes at the letter J.
And completing a comprehensive dictionary would be a very significant endeavour, meaning we’d only find out if there was a market for our dictionary once we had spent a huge amount of time and money on its creation. All too often our initiatives run out of funding before we have given ourselves the opportunity to validate (or invalidate) the concept in the marketplace.
So, how might we create a less comprehensive dictionary (i.e. which is quicker and cheaper to produce, and therefore also less of a risk) whilst still potentially delivering value to our customers?
Well, we could consider delivering ‘slices’ through the much larger concept of a comprehensive dictionary. But how would we choose the criteria with which to conduct this slicing exercise?
One option would be to select the most popular, say, 20% of words. It would probably take around a fifth as long to define this subset, meaning we could put this version of the dictionary on sale more quickly and at a lower cost — perhaps calling it a ‘concise’ dictionary.
We would also benefit from the Pareto principle, that 20% of the causes deliver 80% of the outcomes. There is a law of diminishing returns in defining the remaining 80% of words. By definition (no pun intended), of the words in the remaining 80% we have yet to define, those in the 21st centile will be of more value that those in the 100th centile.
How else might we identify a slice through the concept of a fully comprehensive dictionary?
Well, instead of focusing on the ‘functionality’ of the product, we could flip our thinking over to first consider the people who are hopefully going to buy and use our dictionary.
Children have a narrower vocabulary than adults, so we could target them with a dictionary of the words we expect them to encounter. Many of these words are likely to appear in our concise dictionary, but not all of them (swear words, for example). We could even target a narrower cohort of young people by creating dictionaries for specific age ranges.
This thought process then gives us options. We don’t need to create all these versions of children’s dictionaries. In fact, we should probably try out the concept with a single age range to see if it resonates with our target cohort of children — or those who buy the dictionaries for them. Given these options, we might decide to target 10–11 year olds, as this is the age children usually move from a junior to senior school and will perhaps be bought a dictionary as a present.
Assuming we are actually creating a database of words, definitions, etc from which dictionaries can be created, we can then establish a cohort-based roadmap of ‘releases’ (actually ‘publications’) of our dictionaries. Starting with 10–11 year olds then, if the concept is successful, perhaps expanding the database a little to allow us to release for 12–13 year olds. Although it may be quicker and cheaper to simply release a version for 8–9 year olds by including a narrower vocabulary. But equally, if the version published for 10–11 year old doesn’t sell well, we might decide not to proceed with further publications.
Which would of course be a shame. But we would then have found out that there is not a market for our dictionary much earlier and much more cheaply than if we had progressed with the fully comprehensive dictionary.
But let’s assume that our version for 10–11 year olds did sell well. We then need to make a decision on whether any perceived value that might be recouped from the 12–13 year-old edition — over and above the 8–9 year-old version — is worth the additional investment required to expand the vocabulary contained within our database. But equally, there may be a significant cost involved in rewriting the existing definitions so that they can be readily understood by 8–9 year olds. The important point is that we now have options to choose from.
There are an almost infinite number of cohorts we could target with our dictionary concept. From medics, to lawyers, to naturalists, to business people. And of course we are already working within the confines of a cohort that represents people sharing a common language — in my case English. Perhaps the greatest opportunity slicing gives us is the option to not do something — at least for the time being. I suppose that in theory someone could create a comprehensive dictionary containing every word in every known language. But, if there is a use-case for this product (I certainly can’t think of one), it would be so niche as to represent almost zero return on the considerable investment.
When considering cohorts we are essentially identifying the ‘capability’ we are providing these potential customers with. In this instance we might be providing English-speaking children aged 10–11 with the ‘capability’ to look up words they are likely to know or encounter. That’s quite a precise cohort of users. But we could slice this concept even further by thinking about the ‘functionality’ we will provide them with.
Each entry in a dictionary is accompanied by a number of types of further information, which could include a definition, phonetic spelling, etymology, synonyms, etc. Could we produce a version of our dictionary without a definition? Probably not. But do we need to include a substantial list of synonyms alongside every word in our dictionary? I don’t think we do — at least not for the initial publication. We might even decide that we have actually established a different concept that could be sliced off to provide a different cohort with another set of capabilities and functionality — the Children’s Thesaurus.
OK, so I might be stretching the analogy a little far here, but you can hopefully see how slicing against capabilities and functionality allows us to identify options, which we can then select, reject or delay*.
In the digital world slicing can be used as a way to establish a market of new customers, without the initial outlay required to develop the wider product or service offering, as we target our nascent functionality to specific cohorts of potential customers. But equally, in a scenario where a legacy platform is being updated, slices of the new functionality can be served up to specific cohorts of users via multivariate testing.
If we break a big thing down into constituent parts, we have little choice other than to build each of those parts in turn which — however iteratively they are developed — exposes us to all the risks associated with long feedback loops. Slicing provides us with early and ongoing opportunities to learn, pivot, accrue value and derisk our initiatives, which it does by providing us with options — the essence of agility.
* For a more detailed explanation of the concept of capability and functionality slicing, I recommend the work of @neil_killick
