Agile for non-software teams: A summary

By Nick Butler

11 May 2022

Tags:

Team designing their Agile way of working based on Agile for Non-software Teams. Photo by ThisisEngineering RAEng on Unsplash.

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

Graphic summing up the process and mindset laid out in Agile for Non-software Teams.

Mindset matters most

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 Agile values, principles and beliefs

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.

Agile values according to Agile for Non-software Teams

  1. Deliver value early and often
  2. Adaptation
  3. Customer collaboration
  4. Putting people first

Here’s more detail on these values.

Deliver value early and often

Instead of delivering value to the customer when all the work is complete, deliver portions of value incrementally over time, preferably often.

Adaptation

Make changes easy, cheap and drama-free.

Customer collaboration

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.

Putting people first

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:

  • Getting deliverables right first time.
  • Following industry standards.
  • Delivering results by a certain timeframe or within a certain budget.

Agile values in the Manifesto

Agile principles according to Agile for Non-software Teams

  1. Organise people around value creation
  2. Collaborate on a product, service or solution
  3. Produce outcomes of value
  4. Always work on what’s most important
  5. Get feedback frequently
  6. Keep the cost of change low
  7. Constrain the intake of work
  8. Visualise the work
  9. Break work down
  10. Bounded team autonomy
  11. Self-organisation
  12. Collaboration

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

Beliefs

These principles and values are underpinned by a set of beliefs.

People

Competent, motivated, trusted and supported people will do good work. Teams are stronger than the sum of the individuals.

The customer

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.

Work

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.

The approach: people-centred change

Treat the process as a collaborative, iterative experiment.

Answer your team’s concerns

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.

Make it safe and empowering

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:

  • psychological safety
  • respect
  • trust
  • transparency.

How teams experience change — the Satir model

Broza introduces Virginia Satir’s model of change.

Satir Change Curve from the book Management 3.0, based on The Satir Model, 1991. https://www.flickr.com/photos/jurgenappelo/ (CC BY 2.0) https://creativecommons.org/licenses/by/2.0/

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.

The process: an Agile experiment

This is the change process set out in Agile for Non-software teams:

  1. Pick the work you’ll undertake for your first experiment.
  2. Prepare for the experiment.
  3. Design your initial way of working.
  4. Put your new way of working into practice.
  5. Increase the effectiveness and scope of your Agile practice.

Here are the details.

Pick the work you’ll take on for your first experiment

To do this you:

  • inventory all the work you do
  • narrow down the list
  • frame the work
  • check how aligned the results are with the Agile mindset.

Inventory all the work you do

Answer three questions.

  1. What products, services, or solutions do you provide?
  2. What are your other major responsibilities or activities?
  3. And what work goes into 1 and 2?

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.

Narrow down the list

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:

  • Development: e.g. designing a new course
  • Production: e.g. printing material for a course
  • Business as usual: e.g. scheduling, filling and teaching a regular course
  • Support: e.g. refunding a cancellation

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.

Frame the work

For this work, answer the following questions:

Who are your customers?

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?

What is the value of the products and deliverables to your customers and the organisation?

How do they make a difference to the customer groups you’ve identified? Think of the outcomes they enable.

What does success look like — for you, your customers, your organisation?

This makes the previous answer more concrete.

How are you constrained?

These constraints will limit and guide your ways of working.

Which values will maximise the chance of success?

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 our beliefs about the work?

What are your assumptions about the people, the work, the customers and the business landscape?

You can elicit beliefs by asking questions like:

  • What are things we take for granted (but maybe shouldn’t)?
  • Why do we say we value X?
  • What sort of things do we often say to each other about the work?
  • Which issues keep coming up?
  • What kind of changes do we face or get surprised by?

You can also spot beliefs by listening to your team and management talking about the work. And you can infer them from behaviours.

Check how aligned the results are with the Agile mindset

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.

Prepare for the experiment

Choose a good time to start

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.

Get your manager and stakeholders on board

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.

Prepare the team

Agile for Non-software Teams notes some common issues. If you think they might apply to your team, consider how you’ll address them.

  • Motivation: Those who are doing well in the status quo may be less motivated.
  • Interest: Pitching Agile as a more enjoyable way of working is probably going to interest people more than talking about processes, methodologies or frameworks.
  • Empowerment: If people aren’t currently empowered they may be sceptical this will change.
  • Language: Don’t get stuck on the language of the various frameworks if they don’t resonate with your team.
  • The experience of change: People may have heard about the chaos stage, and be wary of going through it themselves.
  • Assumptions about the right way to proceed: Some people may have preconceived ideas about the framework or process you should follow.

Prepare yourself

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.

Understand the principles

Here’s what Broza’s Agile principles mean for the journey into Agile for non-software teams.

Organise people around value creation

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.

Collaborate on a product, service or solution

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:

  • locks the end-users into your processes
  • makes the work a transparent partnership not a mistrustful struggle
  • motivates the team by letting them see the difference they’re making to the customer
  • helps you keep the solution’s lifecycle and the customer’s support needs in mind.

Produce outcomes of value

Keep your focus on outcomes (benefits) not outputs (deliverables).

Outcomes include:

  • addressing a problem, need or goal of your customers
  • mitigating a risk
  • learning or getting meaningful feedback
  • letting your organisation grab an opportunity
  • helping deliver value later.

Always work on what’s most important

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:

  • testable
  • usable
  • lovable.

Once your solution is delighting customers, you can move onto the next outcome.

Get feedback frequently

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.

Keep the cost of change low

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.

Constrain the intake of work

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:

  • plan and execute in short timeboxes (iterations)
  • limit the amount of work you have on the go at any time (work in progress or WIP).

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 the work

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:

  • promotes transparency
  • helps you spot omissions and planning mistakes
  • shows what work would be affected if you reprioritise
  • gives a sense of control by showing what’s coming up and what’s on the go
  • shows any bottlenecks.

Creating a Kanban-style project board

Break work down

Break each piece of work into the smallest chunk that will deliver value.

This is key to Agility.

Bounded team autonomy

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.

Self-organisation

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.

Collaboration

Unlike solo ownership or passing work from one person to another, collaboration:

  • sparks fresh ideas
  • builds the social fabric
  • reduces delays from handoff
  • increases the quality of deliverables by getting more people’s input and attention.

You don’t have to collaborate all day long but you do want a sense of joint ownership of the results.

Design your initial way of working

Here’s how Agile for Non-software Teams breaks down this phrase:

  • Design: Don’t go off the shelf. Consider things like human dynamics, constraints, and culture.
  • Initial: Expect to evolve and improve. Document your choices but don’t turn them into a standard.
  • Way of working: To transform how your team works you need to choose the values, principles and strategies before changing your procedures, tools and standards.

The process below is not linear and may need multiple passes.

Don’t just copy what you’ve seen software teams do.

Choose operating principles

Select your operating principles from these three sources:

  1. The Agile principles discussed earlier
  2. Any you wish or need to keep from your current way of working
  3. Any others you think are important

Try and make your set of principles coherent — avoid contradictions like team empowerment and lots of approvals.

Design the workflow

The workflow is what people do to get from idea to deliverable.

Broza details 12 steps for designing your workflow. You answer these questions:

  1. Who will manage the list of outcomes, and how?
  2. Who will determine and sequence the deliverables, and how?
  3. How small can you make work items?
  4. What does “Done” mean?
  5. How will you handle sensitive or confidential work?
  6. What should the workflow of a typical item be?
  7. How will you visualise the work?
  8. How will you constrain the team’s work intake?
  9. Which feedback loops should you have for work content?
  10. What sort of impediments do you foresee, and what will you do about them?
  11. How will you get finished deliverables into customers’ hands?
  12. Which touchpoints will the team have?
1. Who will manage the list of outcomes, and how?

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.

2. Who will determine and sequence the deliverables, and how?

Rather than the hierarchy deciding, in Agile you might involve customers, subject matter experts and some or all team members.

3. How small can you make work items?

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.

4. What does “Done” mean?

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.

5. How will you handle sensitive or confidential work?

If your team has such work, plan how you’ll approach it.

6. What should the workflow of a typical piece of work be?

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.

7. How will you visualise the work?

For most teams that will be the physical board, described above.

8. How will you constrain the team’s work intake?

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.

9. Which feedback loops should you have for work content?

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:

  • collaboration
  • peer review
  • early and frequent feedback from customers
  • explicit acceptance criteria detailing what’s needed to satisfy the customer.
10. What sort of impediments do you foresee, and what will you do about them?

Build the habit of noticing blockers and finding fixes. Talking to people is a good first step to finding a fix.

11. How will you get finished deliverables into customers’ hands?

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?

12. Which touchpoints will the team have?

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.

Structure the team

Membership

Broza shares the 10 criteria he uses to assess the likelihood a team will take to Agile:

  1. Communication
  2. Relationships
  3. Equality
  4. Collaboration
  5. Motivation
  6. Leadership
  7. Finishing
  8. Delays
  9. System
  10. Change

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.

Role and responsibilities

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:

  • managing intake
  • proposing solutions
  • processing feedback.

To this list, add:

  • looking after the way of working
  • looking after team health
  • removing impediments
  • facilitating team meetings.

Now decide who will take on these responsibilities. Anyone can do any of them and you can share them.

A standard approach is:

  • Product owner: Responsible for managing and prioritising outcomes, clarifying stakeholder requests and giving feedback on deliverables.
  • Team leader: Responsible for looking after the way of working, team health, removing impediments, facilitating team meetings. Works as a servant leader or coach.
  • Team members: Responsible for the rest.

Note that managers no longer assign tasks or track status: the team does this themselves.

Space

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.

Put your new way of working into practice

Here’s how Agile for Non-software Teams suggest you put your plans into action.

Start with a kick-off

Mark the start and build a shared understanding with a kick-off meeting.

Broza suggests this agenda:

  1. Provide context.
  2. Restate why you’re moving to a new way of working.
  3. Remind people how the new way was designed
  4. Go over the initial workflow and structure.
  5. Restate that it’s an experiment.
  6. Answer any questions.
  7. Address any worries (“What if it doesn’t work”, “What if management don’t like it?”)
  8. Gain commitment.

Finish small valuable work together

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.

Make working agreements

Agree and document how you want to work together. Also known as a team charter, these help make your team culture transparent.

Stabilise the system

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:

  • put WIP limits on some or all individual workflow stages
  • fix chronic waits and blockers
  • clear temporary congestion in workflow stages
  • decide how to handle rush jobs and emergencies (watch out for fake emergencies).

Watch for attitudes and behaviours that hamper agility

Broza describes common issues, including:

  • reluctance to break down work
  • giving work to specialists
  • team members handing off work to each other, not collaborating
  • managers overriding planning and prioritisation
  • managers shoulder-tapping team members to do other work.

To resolve these issues, explain why they stop you delivering value early and often.

Reflect and improve frequently

The book suggests you follow an ORID process in your retrospective meetings. You gather:

  • Objective data
  • Reflections on or reactions to the data
  • Insight and interpretations, then make
  • Decisions based on what you’ve gathered.

Lead intentionally

Agile for Non-software Teams lays out 10 ways you can do this:

  1. Have a clear vision of what you’re aiming for.
  2. Support people through change.
  3. Start and end with outcomes.
  4. Draw and defend clear boundaries.
  5. Watch the work, not the workers.
  6. Reduce the load of approvals and reviews.
  7. Set behavioural expectations.
  8. Look to the system, not the people, for explanations for problem behaviours.
  9. Notice how you communicate and act.
  10. Seek allies and support.

Assess how it’s going

1. How well are you following the principles you’ve chosen?

For each principle, assess how well your tactics implement it.

2. How, and how much, is your team more successful now? What sort of downsides accompany that success?

Gauge your success and any costs that come with it. Broza reckons a rough, qualitative assessment is fine.

Increase the effectiveness and scope of your Agile practice

Effectiveness

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:

  • simplify
  • eliminate waste
  • tighten the workflow
  • make opportunities for learning
  • improve the team space
  • question assumptions.

Scope

You can now apply Agile to more or bigger undertakings. This could include:

  • the same team doing more kinds of work
  • taking on more of the value stream
  • more teams, doing different work
  • more teams, doing mutually dependent work.

Starting small

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!

Make a bigger impact tomorrow

Talk to us today