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’re set up for agile 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. At a minimum, the space should include a visualisation 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 don’t 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 organisation things are structured in such a way that interdependencies are minimised 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.