Agile Is About People and Results

Cognitect has a post on their blog titled “How We Work: Agile is an Attitude.” One phrase from it stuck with me: agile is “a focus on people and results.” I think that’s a better definition than most of what gets sold under the name. Agile is an attitude about how a team works. The stand-ups, sprints, and story points are only useful when they serve that attitude, and a team that adopts the ceremonies without it ends up with all of the overhead and none of the benefit.

What the manifesto says

In 2001, seventeen software developers met at a ski resort in Snowbird, Utah, and wrote the Manifesto for Agile Software Development. It’s short. The core of it is four values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The authors follow that list by saying that while there is value in the items on the right, they value the items on the left more.

Read the list again and look for the word “stand-up.” It isn’t there. Sprints and story points aren’t there either. None of the four values prescribes a practice. The manifesto is a list of priorities that tells you what to care about when two good things pull in different directions, and it leaves the practices up to you.

“A focus on people and results” is a good summary of those four lines. People are the individuals and interactions, and the customers you collaborate with. Results are working software, and the ability to change course when you learn something new.

Rituals without the attitude

In the sixteen years since the manifesto was written, agile has turned into a set of things a team does. You can get certified in it and buy software to track it. Neither of those is bad on its own. The trouble starts when the practices become the goal.

Here are a few patterns I think most developers will recognize.

The daily stand-up turns into a status report. Everyone faces the manager, recites what they did yesterday, and waits for their turn to be over. Nobody is talking to anybody else on the team.

The sprint becomes a two-week waterfall. The plan is locked on the first day, and a change in priorities is treated as a disruption to push into the next sprint. Responding to change was supposed to be the point.

Story points become a productivity metric. Someone compares velocity across teams, or asks why it dropped this sprint, and the estimates start creeping up. Velocity goes up. Nothing else does.

The retrospective becomes a venting session where the same complaints show up every two weeks. I wrote about this in Start Your Retro by Reviewing the Last One. A retro that never checks on its own action items has stopped changing anything.

Each of these keeps the shape of the practice and loses the reason for it.

Ceremonies have a cost

These meetings aren’t free. Take a team of eight with a fifteen-minute daily stand-up. That’s two person-hours a day, or ten a week, before you count planning, the sprint review, and the retro. If the stand-up helps the team spot a blocked story or two people working on the same thing, ten hours is cheap. If it’s a status report nobody listens to, the team is spending ten hours a week to look agile.

Process also costs attention. Every required field in the tracker and every rule about how a card moves across the board is something a developer has to think about instead of the software. The manifesto puts processes and tools on the right-hand side for a reason.

Ask what each practice is for

Most of these practices exist for good reasons, so I wouldn’t throw them out. I’d ask what each one is for, and judge it by whether it’s doing that job.

• A stand-up exists so the people doing the work can coordinate and unblock each other. If it isn’t doing that, try walking the board from right to left instead of going person by person. A small team that sits together and talks all day may not need one at all.
• A sprint review exists to put working software in front of the people who will use it. If no customer or stakeholder is in the room, the team is giving a demo to itself.
• Estimates exist to help someone make a decision. If nobody is deciding anything with the numbers, stop spending an hour a week producing them.
• A retrospective exists so the team can change its own process. One of the twelve principles behind the manifesto says nearly that: at regular intervals, the team reflects on how to become more effective and adjusts its behavior.

That last one matters most. An agile team owns its process and changes it when it stops working. A team that runs the same ceremonies the same way forever, because a book or a certification course said to, is following a plan. That’s the item on the right-hand side.

People and results

I spent a few years as a consultant at Test Double, and consulting means joining teams that already have a process in place. The name a team gives its process says very little about how the team actually works.

If you want to know whether a team is agile, skip the question about which framework they use. Ask two others instead. Are the people on the team talking to each other and to their customers? Is working software getting into users’ hands on a regular basis?

A team that can answer yes to both will usually work out the ceremonies it needs on its own. A team that answers no won’t be fixed by adding another meeting.

Keep the focus on people and results. Keep the ceremonies that help with that, and drop the ones that don’t.