A Checklist for Agile Success

As a coach, I’m often asked to take a look at how an agile organisation or team is working
and give my opinion as to if they are set up for success. These are they key things that I look
for:

1. The walls talk

You should be able to walk any newcomer round your project space and have them
understand exactly what your project is doing from the walls. Similarly, if you’re just back
from holiday, you should be able to walk your team’s walls to find out what’s happened and
where things are. Everything should be up there – the overall vision, the current thinking for
future epics and things that will be hard, architectural ideas and approaches, user research
insights, and more. Use pictures whenever possible. Encourage everyone to draw, even those
who think they can’t.

2. There is clear ownership and engagement from the “business”

The “business” are fully engaged and own the delivery. If there is a separate technology
department then the delivery has not been “outsourced’ to them. Everyone’s in it together, the
budget is jointly held, and success or failure has an equal impact at the senior levels. Without
this there can be no valid vision, no meaningful prioritisation, and without it none of the
necessary business change activity will happen.

3. The vision is clear

There is a clear vision of the service or product that you are building, i.e. what it will look
like in 2 – 5 years time. It’s documented, visually, on the wall. Remember - a backlog is NOT
a vision.

4. There is a great team

The team has the skills, attitude and experience necessary to deliver the vision. The value that
each individual brings is clear, and each values the others. They are aligned in embracing the
shared responsibility of delivering the vision, and the need for constructive feedback and
learning. They are empowered to make decisions.

5. There’s space to think

The team has a dedicated space in which to hold analysis, design and research sessions and
document the upcoming sprints. This space should be joined to the main team workspace, for
example it may be an adjacent room but with the doors left open to encourage flow. See this
blog post by Richard Pope for how it might look. At a minimum, the space should
include a visualization of the current and next sprint, with stories attached.

6. Discussions are open

It’s important to build a common understanding of the service of product you’re building, and
the approach that you are taking. To make this easy hold all discussions in your dedicated
thinking space and apply the ‘rule of two feet’ allowing any team member to join any
discussion that they want to contribute to or learn from, or indeed to leave it if they realise
it’s not relevant to them at that time.

7. Everyone pairs
Pairing is not just for writing code. You can pair on writing stories, on testing, on designing,
on user research. You can also pair across roles. For instance, a business analyst and a
designer may work together to design a process. Working together forces you to question and
improve things as you go along. You don’t have to pair all the time of course!

8. User research happens all the time

You have at least one dedicated user researcher, they are part of the team. User research
happens continually, that typically means at least once every 2 weeks. Everyone in the team
attends research on a regular basis, the product owner in particular lives and breathes it. You
continuously evolve the product or service based on the insights gained. For more
advice, see this blog post by Leisa Reichelt.

9. Releasing is easy
You’re running continuous integration with great automated tests and the developers are
checking in code multiple times a day. The team is responsible for releasing to live, the skills
to do so are embedded in the team. The business decide when they want things released. You
do not have to jump through multiple political or process hoops to get a release approved, or
rely on an arm’s length central team to do it for you (although a central team who do
it with you can work well). Across the organization things are structured in such a way that
interdependencies are minimized and each team can release code independently.

10. You’re delivering thin slices of functionality, incrementally.

Each sprint you deliver thin slices of the overall solution. The slices overlap and build on
each other. For instance, if you are building an online supermarket you do not build the
ability to add stock to the shelves, then the ability to add things to a basket and the then the
ability to pay as separate things which you then join up later giving you an integration
headache. Instead, you may start with a thin journey that allows the customer you to purchase
a single tomato using one payment method for delivery on a pre-selected date and time.
Future slices might add the ability to select by weight, the ability to remove things from the
basket, the ability to use different payment mechanisms, the ability to change the delivery slot
and so on.

11. Engagement has replaced traditional governance

Your sponsors are engaged in the project, they regularly spend time with the team, ‘walk the
walls’ and attend show and tells. Reporting, where it exists, is lightweight and is of direct
benefit to the team as well as to the sponsors. The responsibility of the sponsors to remove
blockers and support the team is balanced with the responsibility of the team to deliver.
Progress is communicated and understood in relation to the vision and a high-level roadmap
as opposed to in relation to a traditional project plan. There is an acceptance that the roadmap
will change based on learning and experience.

12. You have rhythm

The team has a rhythm which goes above and beyond the rhythm of the sprint itself. It
includes the up-front analysis and design work, and the pre- and post- sprint user research.
You plan how this will work and exactly when the key activities need to take place, and
therefore have a constantly evolving set of stories ready for your developers to pick up. The
rhythm allows the team to feel in control of the workload and creates the time and space for
collaboration. For more detail, see my blog post on setting an analysis rhythm.