Through my company Product Science, for the last three years I’ve been working with Growing Communities a non-profit organisation set up in the 90’s to get good, fairly traded, organic food to people in a neighbourhood, in an environmentally, socially, and financially sustainable way. In the summer of 2015, during a strategy planning workshop together we used Simon Wardley’s Value Mapping technique to help think through the strategy for a key part of the organisation’s activity: their weekly veg scheme. With their permission, I’m sharing this write-up to help build a body of public examples of using Wardley Maps in the wild.
This post uses assumes some prior knowledge of Value Chain Mapping (also known as Wardley Mapping). If you’ve never heard of this technique before, I recommend reading his primer post , or if you have time, brewing up a cup o’ joe, and reading through the book Simon’s writing on Medium. If have heard of Wardley Mapping, I’d love some feedback on making this post clearer, as intend to post more – please leave a comment below.
Setting the scene
Over 2014, I started working with Growing Communities, an NGO committed to making affordable, organic food available in Hackney, creating long term relationships with farmers around London, and creating jobs in the local neighbourhood. This short video below gives an idea of what they’re about. They’re a lovely bunch.
That’s nice. What does this have to do with mapping?
As mentioned in earlier (and in the video) Growing Communties runs a weekly veg scheme, but over time the technology powering it had grown long in the tooth and hard to make changes to. Also, as new veg schemes had gone through the Growing Communities start up programme and set up in other parts of the UK, they were reaching a volume where they too needed an automated system to support that activities. What could they do? Build their own bespoke system? Use an off-the peg system? Should we build an open source version for everyone to use? It wasn’t clear.
So, we organised a half day workshop, and tried using Wardley Mapping to develop some situational awareness, to see if it could give us a better idea of what our options were.
After running through a short deck introducing the concept, a handful of us had a go at mapping out the veg scheme’s value chain together, with some post-it notes, markers. It looked a bit like this:
Tidying this up a bit
Tidied up and put it into this template, it looks a bit more like the diagram below:
At the top of diagram, we had a user need for “ethical fresh veg“. To help meet this need, we relied on:
- a) a website for people to see what’s available, and place orders,
- b) a veg bag of produce,
- c) a newsletter we used to tell members what was in the bag this week, with some links to recipes, and
- d) for publicity and to help people pick up their bags, printed matter which we referred to as ‘signage‘.
On order to deliver the veg bags, we also needed a way to deliver them. In this case, it this was a job done by Maisie the Milkfloat, shown in the video above – see delivery (Maisie) – as well as fruit and veg from the farms. Growing Communities isn’t a traditional box scheme – you pick it up from a specific place instead of having vans drop it off to you, so we needed somewhere for members to pick up the bags of produce. In this map you can see this as Cafes and Community spaces on the map, some of which were rented (hence the rented premises).
The website was more than a brochureware site though: there was a hand-rolled CRM using a very
hacked extended version Django’s admin, which also helped generate a packing list of who had ordered what produce in a given week. This packing list is what staff use to work what product they should put into the bags to be delivered, but this packing list is also what is used to work out what to order each week, and also what to collect from customers via a payment processing system. Other staff would put the numbers of active customers each week into a custom ordering spreadsheet, and then use these numbers of people ordering in a given week, as a guideline for what kind of budget they had to spend on ordering product from local farmers and wholesalers.
From data recorded in a packing list each week, you could generate data for checking in an accounting system, and yes, because we had a fairly complex website and a number of automated subsystems powering all of this, we relied on some servers in the bottom right (this is a Wardley Map, after all).
So that’s our map, abridged.
Representing our own stack in this map
I referred to a few automated processes and a website in the previous section. While these were different activities, the reality was that a single monolithic Django application powered all of them, and to represent, this, I’ve shaded it it grey.
Building an app as a monolith when starting out tends to help you deliver features quickly. Over time though productivity when working on them drops off, as you end up managing an ever growing ‘ball of mud’. This is compounded if you are running an application on a ‘snowflake’-like server set up, which is the only working version of a given site.
Lots of the Growing Communities stack was custom, and had been built by a developer who was no really longer around to work on it. When the this stack was originally built, lots of this had to be done as custom one-off work, because there were few suitable products to do some of these jobs for you.
However, everything evolves
While a Wardley Map nice for giving a point in time snapshot of the activities of an organisation, being able to show movement over time is extremely useful for helping people in a room understand how common ways of carrying out an activity may change over time.
I’ve represented this in the map below – as I mentioned before, the shaded grey area represents a big ol’, hard to change custom django application, and the arrows highlight areas of the value chain, where there are clear examples of evolution to a more well understood, commodity-like offering. I’ll cover websites and delivery below in more detail to explain this in more detail:
Evolution in websites
Over the last 5 years or so, it’s safe to say building websites has become a more commonplace activity, and popular products, like WordPress have grown to be much more capable, sophisticated and well understood. If you compare the WordPress of 2008, to the WordPress of 2017, you’ll see a much more powerful product, but also a vibrant ecosystem of hosting services, products built on top of it, and companies who provide bespoke development, which means you have a wider range of suppliers to choose from.
WordPress is one clear example we were thinking when making this map, but it’s not the only one. There are a number of closed source and open source products available now if you want to get a website online, and you don’t want to be tied to a single supplier.
Evolution in delivery
You can also see evolution in the delivery area, where I’ve added another arrow – hiring cars, or small vans on a per hour basis has become much easier, and more commonplace thanks to companies like Zipcar and so on, This might not be as charming as Maisie the Milkfloat, but operationally, it’s much simpler, and finding spare parts for milkfloats isn’t getting any easier or cheaper. Also utility-like pricing means that you end up only paying for the time you’re using it, and you’re not committing for a long term either – good if a vehicle isn’t in constant use all week, or your usage patterns change.
Sketching out a new world
So, we were able to use maps to sketch out our own value chain, and we were able to use them to identify areas of evolution that we might want to take advantage of, when thinking strategically about our future.
In addition to using a map to talk about what changes have taken place, you can also use maps to describe a possible future shape of a value chain, and talk about the pros and cons of these different approaches.
If we were to start a new veg scheme tomorrow with no legacy infrastructure
If you were setting up a veg scheme tomorrow, and you already had years of experience running one, you might not build everything as a single monolithic system straight away. In general, I agree with Martin Fowler’s advice that monoliths are good to start out with when you’re exploring a problem or building a first pass at something. Once you’ve identified the main jobs a system is doing, there is an argument for breaking this into smaller services, and letting specialised tools do specific jobs.
A sample map, without building a website CMS yourself
The map below, outlines one possible approach we considered. While some parts of running a weekly veg scheme, were unique to Growing Communities, other parts, like maintaining a website, and letting people sign up to the scheme weren’t, and we explored having two separate systems – one well understood product for the website, like WordPress or Drupal, and where the special recurring billing, and specific delivery rules were needed, we’d continue to build this in-house.
This is why in the map below we no longer have the amorphous blob representing a huge, old do-everything django app, but instead we have two separate shaded regions to represent the two systems at work. Further to the right, in the ‘product’ area of the map, we see the more commoditised, commonly understood CMS-powered website. The idea for pushing this to the right, and treating it like a product is that you’re no longer tied to a single supplier for a system, and it’s easier to change.
Still in the left, but smaller, we see a more bespoke system handling billing, generating packing lists for customers. The idea here is that if you have components in your value chain that are unique to your system, they will often effectively quickly end up as legacy IT, that’s expensive to work with in future.
If you have a smaller custom system, there’s less code to manage, and hopefully fewer concepts for a new developer or team to understand before they can be productive on it – your exposure to all the risks associated with legacy code/components are mitigated somewhat, and you’re less dependent on the few suppliers who understand it.
How the map informed the final strategy
If you go to the Growing Communities website now, you’ll see a website powered by the Drupal CMS put together by an agency that specialises in creating websites in Drupal. This speaks to Boxmaster, a commercial product designed specifically for organisations running veg box schemes.
This replaces a single hard-to-change, monolithic django application, which was appropriate for exploring the problem and building a service around, but was only really understood by two people, who were not core parts of the staff, nor were they working on building veg box scheme software full time.
This new configuration for Growing Communities went live early last month, so its a bit early to tell what the results of this are, but when discussing IT strategy, I found the maps useful for explaining what our options were, and how treating something as a product versus bespoke affected the trade-offs we would make.
This post is getting pretty large now, so I’m wrapping this up here, but there’s still a lot cover more here. We carried out some experiments with trying to manipulate the map, by open sourcing parts of the Growing Communities system. If there’s interest, I’ll cover them to the extent that I can in another post.
When I’ve done consulting work for clients, I’ve tried to use tools they can continue to use after I’ve left, and in this case, everything was done with Google Draw – it’s not perfect, but it is effectively free. I’ve shared my Wardley mapping template for others to use here.
If you have any questions, I’m happy to answer them in the comments below, until they’re closed.