Better agile ways of working for non-software development teams

I have been fortunate to work with different kinds of agile teams that have missions other than software development. Recently I was surprised when I started a coaching role with a non-software team, and discovered they had been running Scrum for eight sprints, each two weeks long. Besides doing non-effective stand-ups and retrospectives, and showcases filled with over-designed slides; no value had yet been delivered to the customer.

That team was formed by lean experts and human-centred design specialists. Their mission had been to improve customer experience across banking services. They did this by analysing customer journeys, creating value stream maps, gathering and analysing data, hypothesis testing, conducting customer interviews and process simulations. They were religiously running all the Scrum practices, but they were struggling to connect them in any meaningful way to their work. They also forgot the main goal of agile: deliver value soon and often. These were the comments I heard from the team when I first started as their agile coach:

“This process doesn’t suit us”
“I am struggling to break user stories into tasks”
“I don’t think that our estimates in story points are useful”
“These two-week sprints are making us less agile than we could be!”

These complaints were not just pure resistance to change, they were fair.

Even though Scrum has been broadly used outside of the software development world, Agile doesn’t prescribe scrum. But being one of the most known agile approaches and simpler to get started with, it’s frequently the first option.

One of the questions that comes to mind is: if Scrum wasn’t working for them, why did they keep using it? It would be unfair if we put Scrum to blame: yes, Scrum does prescribe sprints, but Scrum doesn’t prescribe: story points, two-week sprints, not even user stories! So, we come to the first fundamental agile principle that this team forgot to adopt: inspect and adapt. They started with a set of assumptions about how they would work, but instead of challenging, validating or changing these assumptions, they kept running.

So, I put forward a proposal to them: together let’s craft an agile process that works for you. One of the items that we always had in our retrospectives was the following question: is the way we work still working for us?

In the spirit of crafting your own agile process, I’ll cover an approach that I’ve been using.

Start with the purpose

As Simon Sinek says in his famous TED talk and book¹, you must always start with why. Understanding the team’s mission will be a stepping stone to understanding the current processes of their work. Some useful questions to begin with, are:

Does the team provide repeatable services?
Is it working on a temporary project with a big delivery at the end?
Are there clear phases that build upon one another?

When I start working with new teams, STATIK² is my preferred approach. You will always get some benefit from asking at least the first two questions that STATIK proposes:

What is the purpose of the service?
What are the sources of dissatisfaction?

The sources of dissatisfaction are frequently related to the current working processes, so it’s a great place to start by understanding where the improvements can be made.

Asking the question ‘what is the purpose?’ will also reveal interesting things. You may find everyone doesn’t have the same view about the purpose, or even that there’s a lack of purpose. If that is the case, you have another problem to solve!

With principles and values, you can never go wrong

With a few minor tweaks to the Agile Manifesto³, the principles can work for different initiatives and not just software development. See an example of our interpretation for that team’s context:

Satisfy customer through early and continuous delivery of value
Harness change to increase competitive advantage
Deliver value frequently
Stakeholder collaboration
Motivate individuals to self-organise around the goals
Improve ways of communication
Value delivery is the primary measure of progress
Maintain a sustainable routine of work
Continuous attention to quality enhances agility
Simplicity — the art of maximising the amount of work not done is essential
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly

Defining value

In the manifesto, at least three principles explicitly mention value. For a software development effort, the concept is very clear: a piece of working software.

For a non-software development effort, the value to be delivered and the measures of progress may not be so clear. The simplest version of what is value in your context could be something that your customer asks for, and something that you deliver to them. In some cases, this definition won’t be enough, so, other concepts might be useful:

Example 1 — Progress (an increment of value or a step towards delivering value): from the point of view of the customer, the full value can only be realised once an entire piece is delivered. Work can be delivered in potential increments of value, which will lead to a delivery of full value (after for example some weeks of work). As an example, for a digital agency the introduction of a blog post can be an increment of value. The full value will only be delivered when the blog is published.
Example 2 — Work item type (different types of services that come into the system and that go out): this is a useful concept borrowed from kanban. A work item type is something that has both a requestor and a receiver (requestor and receiver can be the same). When the request is completed, the work is finished and delivered. As an example, in a legal environment one work item type can be a request for advice. A customer asks for legal advice, the lawyers provide the advice and closes the ticket.
Example 3 — Hypothesis testing or experiments: the nature of which is about uncertainties, and the goal is to validate those uncertainties. In software development, this kind of work frequently receives the name “spike”. An experiment can give you more information to move on or completely discard some assumption.

The question you need to ask is: what are you delivering?

Discovering and visualising the workflow

Now that you know what value is, you can start thinking about your value stream. To do this, the Kanban Method⁴ is your ally. You will define how you receive and prioritise your demand, how it flows through the various active and waiting stages until it is finally delivered. You will manage the flow of work, so the value can be delivered as soon as possible.

When there is no workflow

There is a possibility that the nature of your work cannot be represented as a workflow and you will end up with a simple ‘to-do, doing, done’ board. Maybe it is a project, with a clear start and end including defined phases.

In that case, good project management always worked and will continue to work. Take inspiration from the Agile Principles and see how you can apply this to your context. Other practices that might be useful, are:

Shorten the cycles to deliver as soon as possible and validate learning
Extreme visualisation of everything related to the project
Visualisation of risks and blockers
Stand-ups
Visualisation of important milestones
Running time boxes of 1 to 2 weeks to achieve specific goals
Tracking these short-term goals with the overarching goals
Planning and reviewing how you achieved or how you can do better to achieve the next set of goals

Implementing feedback loops

Feedback loops are the events that support your cycle of inspection and adaptation. Scrum suggests four types of feedback loops, all of them coupled by the rhythm of the sprints. When establishing or improving your current process of work with kanban, it doesn’t require that your cadences are coupled. You can do weekly replenish meetings, fortnightly retrospectives and monthly reviews for example. You can set up your cadences according to what makes sense for your context.

Cadences of prioritisation, strategy, risk assessment and delivery are opportunities for inspection and adaptation. Understand the minimum events that you need to start with and move to the last step!

Inspect and adapt

Finally, in every system of work that you are building, it is never an end state. Keep thinking, changing, evaluating. Use stand-ups, retrospectives, reviews, and service delivery reviews to analyse the performance of your service, how the teams are working and interacting. Analyse if the process is suitable for the work that you are doing and if you are meeting your goals. When doing all of those things, you will probably see your process improving in an evolutionary fashion while you deliver better results.

References: