But if it’s such a great system, why isn’t every organization an agile one? The culprit is hiding in plain sight: It’s the prevalence of agile projects.
Individual agile projects, as opposed to dedicated agile teams, undermine the effectiveness of agile practices and turn them into a pale imitation of the real thing. A project-centric approach to agile also accelerates burnout, leaving people hating the word agile.
While there are certainly other factors that influence the success or failure of an agile transformation, this is the one thing that I’ve seen derail more agile efforts than anything else in my years as an agile coach. Here’s why projects are agile’s kryptonite, and how to avoid getting pulled in by them.
Most organizations structure the flow of work around projects. Some projects recur; others only happen once. Some last multiple quarters, or even years, while others end after just a couple of weeks.
Ultimately, projects are finite. And this is often the basis of their appeal as testing grounds for agile ways of working. It’s easy to draw lines around a certain amount of time, a particular group of people and a specific set of tasks and say, “This is where we’ll test.” It feels safe, simple and obvious.
The problem is that it flies in the face of how agile was meant to work.
Agile delivers faster time to market, improved operational efficiency, happier people and a host of other benefits, not by requiring a different set of meetings but by creating focus. It brings together a group of people and dedicates all of their time and energy to accomplishing a shared goal. In the project world, however, there’s never this level of commitment.
People work on multiple projects simultaneously, juggling demands and priorities as best they can. Agile teams, on the other hand, devote all of their productive time toward their team’s goals; they don’t need to navigate multiple stakeholders or guess which task is most important.
It’s this focus that creates the magic of agile, not its meetings or tools or jargon. Those all help, but without focused, dedicated teams, those changes don’t make a real impact.
Let’s take one simple example: the daily standup. This is a 15-minute meeting that usually starts off an agile team’s day. Team members talk about what they did yesterday, what they plan to do today and any problems that are slowing them down. After it’s done, the team spends most (if not all) of the rest of the day actually working.
If I’m on an agile project, however, the daily standup isn’t even close to my only meeting. I have meetings for all my projects. Instead of getting seven hours and 45 minutes of productive working time, I get a tiny fraction of that. I can’t get any more work done than I usually do.
So at the end of my agile project, nothing seems different. It took just as long, needed just as many revisions and delivered exactly the same results as my regular projects. It looks like agile didn’t work, but it never had a chance.
In some cases, the proposed antidote to one agile project is more. Sadly, this just compounds the problem.
I recently had a client who set a target to increase the number of agile projects they were running by 25% year over year. More work being done using agile frameworks could only be beneficial, after all.
When we arrived, it was not going well. Despite more work being “agile,” the teams were near their breaking points. Team members were in so many meetings that they had no time to work, and every time they got put on a new agile project, it just got worse. Let’s use our standup example again to understand why.
Each agile team has a daily standup that lasts 15 minutes; each agile project team needs a standup. If I’m on five teams, I now have to attend 75 minutes of standup every day. And that’s not including longer meetings, like sprint planning. It’s easy to see why more agile projects meant less time available to work.
As with a single agile project, trying to roll out agile to all projects doesn’t enable focused attention on one priority. It spreads people thinner and often convinces them that agile itself is to blame for their overwork.
If you want to truly test agile’s potential (and not have everyone hate it), you need to build dedicated agile teams. This means they work 100% of their time using agile and are striving together to achieve a goal.
Let me be clear: this doesn’t mean every agile team works on just one project.
There are multiple projects that will contribute to the team’s goal, and they work on them all. They have a leader who prioritizes the work based on the team’s goal, and the team tackles projects based on their importance.
As an example, agile marketing teams often align around goals tied to the customer journey. At the beginning of most journeys is an awareness-building phase, so one agile team spends all its time increasing brand awareness. Members of the team only do work from their backlog (prioritized to-do list).
In this model, everyone can focus on a small number of activities. They can confidently commit to a delivery date, support struggling team members and generally devote their day to doing valuable work. Team members are more likely to be happy and focused, work proceeds smoothly and the operational and financial benefits of agile can be finally realized.