By Nick Butler
Tags: Agile
Agile for Non-software Teams by Gil Broza is a popular guide to the Agile way of working. Unlike most other guides, it’s written for people outside the IT world that gave birth to Agile. This post is an adjunct to the book, not an alternative. It gives you an overview before you dive right in.
Agile for Non-software Teams, Broza says, is “a pathway for considering, designing, starting, growing, and sustaining an Agile way of working.” As the subtitle says, it’s “a practical guide for your journey”. It shows you how you can tailor an Agile way of working to your team and your context.
Buy the book, view a sample chapter and get additional resources
The key to Agile for non-software teams is not implementing an Agile framework, but embedding an Agile mindset. It’s best to treat Agile as a philosophy, a set of beliefs, values and principles, not a methodology, process or set of practices.
It’s about knowing what you want to achieve and intentionally making different choices that will enable this.
This means you should tackle the change process with an Agile mindset, and based on the Agile values and principles.
The values and principles that underlie the various Agile frameworks like Scrum, Kanban, XP and Lean were first laid out in the Agile manifesto.
In Agile for Non-software Teams, Broza restates these so they’re less tightly tied to software development. If you’re reading other guides to Agile, it might help to be familiar with how they’re expressed in the Manifesto as well.
Here’s more detail on these values.
Instead of delivering value to the customer when all the work is complete, deliver portions of value incrementally over time, preferably often.
Make changes easy, cheap and drama-free.
Let the delivery team collaborate with their customers, customer proxies, users, and stakeholders — both internal and external — to determine outcomes and deliverables that move all parties forward.
Enable people to bring their best selves to work in service of the outcomes. Treat customers, staff, and management as you would want to be treated.
Broza contrasts these with non-Agile values common to many organisations, such as:
You can find out more about these principles below.
Broza suggests that you don’t need to follow all the values and principles, but that the full Agile package is more powerful.
Agile principles in the Manifesto
These principles and values are underpinned by a set of beliefs.
Competent, motivated, trusted and supported people will do good work. Teams are stronger than the sum of the individuals.
The customer is what the work is about. You should focus intently on what the customer needs right now, but keep options open for the future.
If the work is complex or complicated, adaptation is better than detailed upfront planning. Fast feedback drives adaptation. Adaption assumes frequent change, so you need to keep the cost of change low.
Treat the process as a collaborative, iterative experiment.
In Chapter 3, Broza identifies a number of common concerns, and shares possible responses.
For example:
Isn’t Agile just for IT? How is adopting a way of working that software developers use relevant for us?
It’s the mindset that matters not the practices and techniques, and the mindset is relevant outside software.
We are not empowered to make decisions, we always react to others’ requirements.
That can change especially if you have an influential supporter or show the value of empowerment through little wins.
What if it doesn’t work out?
Treat it as an experiment. Make it safe and easy to undo. Don’t change titles, reporting lines and so on.
Chapter 5 of Agile for Non-software Teams looks at how to bring the team along for the ride. They need to be ready, willing and able.
Work collaboratively throughout the process. Start by coming up with a compelling vision for the change you’ll make together. That way you’ll build buy-in along with a shared understanding of what you’re trying to achieve.
To do this you need:
Broza introduces Virginia Satir’s model of change.
The initial status quo is interrupted by a foreign element — the change. This triggers a period of chaos which continues until people take on board a transforming idea, a lightbulb moment. Putting this idea into practice produces ongoing improvement until a new, higher-performing status quo is reached.
Because you know it’s coming, you can prepare your team, managers and stakeholders for the chaos period.
This is the change process set out in Agile for Non-software teams:
Here are the details.
To do this you:
Answer three questions.
Unless you’re doing a full Agile transformation, Broza advises that you focus 1 and 2 on areas that have a chance of making it to the first Agile experiment.
Agile is all about delivering value. So, if your work doesn’t deliver value to customers or the business without input from others, try to bring in those other groups. You need a cross-functional team that can turn out finished goods.
Broza recommends focusing on those undertakings that need a meaningful chunk of the team’s effort in order to make the experiment real, and to create useful learnings.
Break your work into these common (overlapping) categories. The examples are for a training team:
Work with a strong development component is a good candidate for the Agile experiment. It’s simplest if you just focus on one piece of work.
For this work, answer the following questions:
Whom do you serve? Who uses your deliverables? Who pays for them? And who benefits from your work (or loses if you don’t deliver results)? Whose outcomes does your work support?
How do they make a difference to the customer groups you’ve identified? Think of the outcomes they enable.
This makes the previous answer more concrete.
These constraints will limit and guide your ways of working.
Agile for Non-software Teams offers these other ways of asking this question: As the team works, what should they optimise for? What are the top 3 to 5 values that should guide all choices? What is non-negotiable? And what is critical for success?
Don’t just parrot the company line. Be aspirational.
You may have to juggle conflicts between values and constraints.
What are your assumptions about the people, the work, the customers and the business landscape?
You can elicit beliefs by asking questions like:
You can also spot beliefs by listening to your team and management talking about the work. And you can infer them from behaviours.
Compare the values, constraints and beliefs you’ve identified with the Agile values, principles and beliefs covered earlier.
If they don’t line up neatly, you may need to go for a hybrid way of working. If they don’t align much at all, Agile is probably not for you.
You’ll need people to be available and to have the headspace to engage with the change. So a good time to start is just after a project has finished.
The more involved they are, the better understanding they’ll have. As much as possible, bring them into the collaboration so you can bring them along on the journey too. And they’ll understand the importance of making the process safe to fail.
For those stakeholders you can’t collaborate with directly, it’s better to over- than under-communicate.
Agile for Non-software Teams notes some common issues. If you think they might apply to your team, consider how you’ll address them.
To lead an Agile transformation, you have to lead in an Agile way. The Agile approach to leadership is “empowering and supportive team-level leadership, psychological safety, and true collaboration.” You’ll need to be ready to lead more than manage, to put people first, create a safe environment, help the team develop a compelling vision of the change, be transparent, and be open when you don’t have the answers.
Consider getting outside help. Broza’s process involves making many decisions, and these will be easier with the support of someone who’s been there before.
Here’s what Broza’s Agile principles mean for the journey into Agile for non-software teams.
In Agile you want to deliver value early and often, so you organise your team to make this easy. You make sure your team has all the skills needed to give your internal or external customers a valuable product or service.
This is often a change, as most organisations group people by function, role or speciality. If the people needed to deliver value aren’t part of the same team, you get delays and confusion as work is handed over.
Rather than delivering one-off projects or deliverables, think of your work as an ongoing collaboration with your customers on a product, service or solution. Work with customers to make sure the solution is just what they need (see Get feedback frequently below).
This:
Keep your focus on outcomes (benefits) not outputs (deliverables).
Outcomes include:
Identify the most important or valuable outcome and complete that before you move onto the next most important one.
You may achieve an outcome through a set of what Broza calls “evolutionary milestones”. Each step is more finished and gets you closer to realising the full value of the work. The stages he suggests for a deliverable are the earliest versions that are:
Once your solution is delighting customers, you can move onto the next outcome.
These evolutionary milestones are driven by wanting fast feedback.
You need to find practical, actionable ways to check that the solution you’re coming up with actually fits the bill. The more uncertain you are about this, the sooner you want to get feedback. This lets you learn fast and change course if the feedback suggests you’re missing the mark.
Getting fast feedback is a key way to keep the cost of change low. And you’re able to get fast feedback by always aiming for the simplest possible solution.
When planning work, consider how hard it would be to change a deliverable.
The more work you have on the go, the less you get done. You get delays, quality issues, missed commitments and stress.
To avoid this you can:
Crucially, you also switch from pushing work on the team, to the team pulling in the work they can complete in the days ahead. This creates a reliable flow, boosting both productivity and predictability.
Visualise all the work of your current iteration on a visible board (physical or digital). Set up your board to show the different states the work can be in. A simple version might be Ready > In progress > Done.
Update the board as each piece of work moves through the states.
The board:
Creating a Kanban-style project board
Break each piece of work into the smallest chunk that will deliver value.
This is key to Agility.
In Agile, the team decides how it achieves the desired outcomes, but not necessarily the priority of the outcomes themselves. In other words, tactical decisions are made by the people closest to the work. But the team is still bounded by things like organisational culture, policies and strategic choices.
This autonomy includes deciding who does what when, within each iteration. Ideally you do this by consensus.
To enable this, it helps for people to broaden their skills so they can pick up and complete more types of work.
Unlike solo ownership or passing work from one person to another, collaboration:
You don’t have to collaborate all day long but you do want a sense of joint ownership of the results.
Here’s how Agile for Non-software Teams breaks down this phrase:
The process below is not linear and may need multiple passes.
Don’t just copy what you’ve seen software teams do.
Select your operating principles from these three sources:
Try and make your set of principles coherent — avoid contradictions like team empowerment and lots of approvals.
The workflow is what people do to get from idea to deliverable.
Broza details 12 steps for designing your workflow. You answer these questions:
First, identify where outcomes come from and when the team first learns about them.
Who will decide the priority of the outcomes? You’re looking for someone who is customer-oriented, available, knowledgeable, confident, a great communicator and truly empowered.
If you need more than one person to do this, ensure they have a transparent process for making their decisions.
Think too about how often they will revisit the list of outcomes and re-prioritise them. In addition to reprioritising based on feedback, this might include changes that come from your organisation’s planning cycle.
Rather than the hierarchy deciding, in Agile you might involve customers, subject matter experts and some or all team members.
People struggle with this. It takes practice. So consider having a go at some of your existing work.
Broza advises that you avoid making them too small, though analysis by Lean expert Don Reinertsen suggests it’s actually quite hard to go too small.
Broza says that in Agile, finishing is more important than starting. But how do you know you’re finished? You want explicit, transparent criteria. What attributes or qualities should work have to allow the team to move onto the next thing, without having to worry about loose ends?
In Scrum, this is known as the Definition of Done.
If your team has such work, plan how you’ll approach it.
What is the sequence of states that work moves through to get from “ready” to “done”?
The more states, the easier it is to see bottlenecks on your board. But keep it simple.
For most teams that will be the physical board, described above.
Agile for Non-Software Teams says that people are often sceptical about the need to limit WIP. If so, monitor WIP initially, and revisit how you limit it later.
How, when and who will help you validate you’re on the right track. How do you make it safe to get and give feedback? And what will you do with the feedback, including when it invalidates lots of what you’ve done.
The Scrum review is one way to do this. At the review, you demo the work you’ve completed — and the value you’ve created — this iteration.
Approval is a specific form of feedback. List all your approvals and note which ones delay or demotivate. For these, try replacing approval with:
Build the habit of noticing blockers and finding fixes. Talking to people is a good first step to finding a fix.
When and in what form will you deliver your solution, and how will customers know it’s ready? How will you know they’ve got it and are benefiting from the results?
When will the team get together to plan ahead or to look back in order to identify ways you can improve. Having a cadence or heartbeat can help create good habits.
Many teams have a daily touchpoint or stand-up. This is to plan the day’s work and clear blockers, it’s not a status update for the boss.
Another useful touchpoint is the retrospective. A regular retro lets you look back at your workflow and teamwork and see where you can do better.
Broza shares the 10 criteria he uses to assess the likelihood a team will take to Agile:
He suggests rating the team as a whole for these criteria, using a scale of 0, 0.5 and 1. If they score below 7, that’s a risk. You could adjust team members, team size and availability to improve the score.
Try to keep the same members throughout the experiment.
List the responsibilities the team needs to work well.
Add ones you’ve noticed from these 12 steps for designing your initial way of working above, such as:
To this list, add:
Now decide who will take on these responsibilities. Anyone can do any of them and you can share them.
A standard approach is:
Note that managers no longer assign tasks or track status: the team does this themselves.
Try to create a collaborative space. Broza notes that having people push against this setup is a red flag. Talk to people about why they’re reluctant.
Here’s how Agile for Non-software Teams suggest you put your plans into action.
Mark the start and build a shared understanding with a kick-off meeting.
Broza suggests this agenda:
You’ll have quite a list of values, beliefs and principles, so you’ll need to remind people of them.
Broza suggests this mantra as a way of distilling them into something memorable:
Finish small valuable work together.
You can also put the full list up on posters.
Agree and document how you want to work together. Also known as a team charter, these help make your team culture transparent.
You want a good flow of work in your system: a good balance of work in and out. Visualising work helps you spot issues. You can then:
Broza describes common issues, including:
To resolve these issues, explain why they stop you delivering value early and often.
The book suggests you follow an ORID process in your retrospective meetings. You gather:
Agile for Non-software Teams lays out 10 ways you can do this:
For each principle, assess how well your tactics implement it.
Gauge your success and any costs that come with it. Broza reckons a rough, qualitative assessment is fine.
While Agile for Non-software Teams doesn’t include continuous improvement in its list of Agile principles, it is a fundamental goal.
To continuously improve your Agile practice, the book recommends you consciously look to:
You can now apply Agile to more or bigger undertakings. This could include:
Looking back at this whole process, you might think that Broza is suggesting a bigger chunk of work than is ideal.
If so, consider following his advice and breaking it down into smaller units of value. What’s the smallest thing you could do to start following the Agile principles and building an Agile mindset?
For example, you might talk through the Agile values and principles and identify a couple of simple ways you can follow them in your work. Then repeat a few weeks later. This would develop the team’s familiarity with the ideas before you tackle the full-blown transformation.
Good luck and bon voyage on your Agile journey!
