In the previous posts I described how we designed cross-functional squads aligned around strategic goals. A key benefit of alignment is that it automatically delivers an increase in speed of delivery by dramatically reducing, or eliminating, the dependencies and bottlenecks which so often slow us down. By aligning people around goals and outcomes you essentially streamline your organisation and expose the bottlenecks in resource.
However, beyond alignment there is further opportunity to optimise speed by leveraging lean and agile working practices to optimise individual workflows and value streams. The practices I’ll describe will be familiar to many — anyone that has coached a software development team will recognise these tactics. However, as this series is about adopting business agility, I’m going to focus on how we introduced these practices to squads outside technology.
Flow Efficiency
Flow efficiency looks at how long an item of work takes to move through your workflow — in other words how long it takes you to create value. The more efficient your workflow, the quicker you can learn and the quicker you can deliver value. Cycle time is the measure we use to understand how efficient our workflow is.
From concept to customer, optimising flow efficiency helps us learn and deliver value faster
In the product engineering world this was nothing new — we’d been measuring cycle time and optimising work flows for some time. However, outside of technology, these were new concepts. I wanted to start optimising all our workflows, so irrespective of whether we were delivering physical products or marketing content, we’d be optimised to deliver as quickly as possible.
Minimum Viable Agility
In 2018 I had the opportunity of attending a course on how Spotify approach agility, facilitated by Joakim Sunden. One of the many great takeaways from the course was the concept of “minimum viable agility”. Spotify seek to create an autonomous environment with just enough constraints to avoid chaos. One of these constraints is minimum viable agility.
Spotify don’t advocate any particular methodology, but they do have certain things they expect every team to do. Inspired by this concept, I came up with my own version of minimum viable agility. I believed each team should:
- Visualise workflows
- Hold a daily stand-up
- Hold a retrospective at least every two weeks
These were to be the three cornerstones of agile working for any team at Moonpig. Over and above this, I planned to measure cycle time for each team, and to use data to identify bottlenecks in the workflow to help the teams optimise their processes.
Introducing agility outside product engineering
Workshops
As most people outside of product engineering had little or no experience of agile working practices, I ran workshops with various squads to introduce them to the key concepts and benefits.
I used various games that will be very familiar to agile practitioners. We played the coin game to understand the value of working in small batch sizes. We also played the name game to demonstrate the importance of work in progress limits.
The biggest part of the workshop was dedicated to playing getKanban — one of my favourite tools!
The getKanban board game
If you’ve not come across it, getKanban is a board game which simulates a kanban workflow. The main advantage of it is that it demonstrates cause and effect in a short space of time, which helps teams understand the consequences of the choices they make. I have found work in progress limits to be one of the most difficult concepts for most people to grasp, and getKanban really helps people conceptualise the benefits of this. It is also a great way for people to start understanding the benefits of communication, collaboration and swarming.
Visualising workflows
Having familiarised the teams with what agile working would look like, the next step was to start visualising workflows. Jira happened to be the tool we were licensed to use, so it made sense to create the workflows there.
I’m often asked why we didn’t use physical boards instead, and there are two reasons. Firstly, lack of space! We simply didn’t have enough free wall space to accommodate boards for all the different squads. Secondly, for me there is little point in visualising a workflow if you’re not going to optimise it. Measuring cycle time and bottlenecks manually across 14 squads simply wasn’t viable, so we needed an electronic solution.
The biggest resistance to using Jira was the perceived admin overhead of raising the tickets. However, the same people that were concerned about this were also the same people that cited lack of process and visibility as some of their main frustrations. I suggested that using Jira would provide the visibility and support a better process.
Most teams need a coordinated effort in order to complete a single task. Creating a website landing page, for example, needs a content marketer, a designer and a copywriter. A visualised workflow supports coordination because it provides clarity around the progress of each individual task — what has been done? What is left to do? Who is working on what?
Sample workflow for the Content Activation Squad
In reality, having persuaded the teams to try Jira, they realised the advantages very quickly!
Improving collaboration
With workflows up and running in Jira, I introduced stand-ups to the team. This ensured that at least once a day the whole team was reviewing their workflow and discussing priorities. This helped foster collaboration and encouraged the squads to start working as a team. In the pre-squad world, most people worked individually. Stand-ups helped cement the idea that delivering work was a team effort and that there were benefits in communicating regularly.
We also supported this collaboration by seating squad members together. Whilst stand-ups are a great way to have a regular team catch-up, putting people together automatically starts to build a rapport between team members and greater communication and collaboration are a natural side effect of this.
Optimising workflows
While daily stand-ups provide great visibility on day to day issues and blockers, and provide a regular opportunity to focus a team on finishing work, retrospectives are the cornerstone of process improvement. I’m a great fan of using data to focus retrospectives as it helps teams understand what’s slowing them down — it bridges the gap between perception and reality.
We had long since created data dashboards for all our product engineering teams, and I now created equivalents for non-tech squads. The dashboards included:
- Average cycle time over the past two weeks
- Throughput (number of items completed)
- Workflow graph — the average time in status of each stage in the workflow
- Tasks completed in the previous two weeks
Sample dashboard
We’d begin each retrospective by reviewing the dashboard, starting with cycle time. Calculating an ideal cycle time is not easy, but my rule of thumb is to get the team to estimate how long it takes them to a standard task, and then to compare that number to the actual cycle time. There will normally be quite a gap between the team’s estimate and the actual cycle time, and this is good! It helps the teams realise that there is room for improvement, and they start to take the idea of cycle time seriously.
To deep dive in to cycle time we would then look at cycle time for individual tasks to understand which ones were pushing the average up.
In addition to cycle time, we’d look at the workflow graph to identify bottlenecks in the workflow.
Reviewing and discussing this data helped the team understand where improvements could be made, and this helped drive useful discussion and actions.
As I said earlier, the value of limiting work in progress is difficult to grasp. Using data to illustrate the impact of WIP on cycle time helps teams to understand the benefits and they are then much more likely to start respecting the limits set.
Sound familiar?
If you’ve ever introduced lean and agile working practices to a software development team, you may well have read this and thought “Well that’s nothing new!”. And that’s precisely the point. Agile is too often perceived as a “technology thing”, but in fact it’s a set of principles that are agnostic of technology. Therefore, introducing agile working practices in to a content marketing team isn’t any different to introducing it to a software development team.
The one additional challenge is around expectation and perception. Today agile is widely recognised as the “right” way to develop software, and most software developers will expect to be asked to adopt agile practices. Outside of technology there is much less knowledge of agility and its benefits, and there is no expectation that it should be adopted. To that end you do have to work that little bit harder to persuade people to give it a go.
I should also point out that what I have described in this post is merely the starting point. Most of the non-tech teams, while having adopted minimum viable agility, are a long way from having really optimised workflows. That’s really down to a lack of coaching resource — as I was the only coach at Moonpig during this time, there simply wasn’t enough of my time to give the requisite dedicated attention to the half dozen teams that needed it. However, the basics are in place and with the right support there is no reason those teams won’t be able to improve their speed.
What’s next?
Hopefully this post will have helped describe how a non-tech team can start to leverage agile working processes. In the next post I’ll describe how we started to encourage a more data-driven, experimental approach to increase the value of the work we were doing.
If you missed it, you can read Part 1, Part 2, Part 3, Part 4, Part 5, Part 6 and Part 7 here.
