Is there value in the transformation of Agile?

Agile has evolved to an interesting state where team members are constantly “driving through the fog” while constantly sprinting.

Surely if this approach was utilized for a long road trip in a motor vehicle it would lead to a devastating crash (driving fast through the fog is simply dangerous). Yet, I see teams at clients and vendor partners being tired from the fog never clearing up and the constant sprinting. More attention needs to be paid to this!

I recently asked one of my teams, who has been working in an Agile fashion at a client for the last four years, about when they last paused from sprinting, took a breath, and started on something new that wasn’t another mundane story in the infinite backlog of requirements. They said it’d been about four years since they’d done that; essentially working on delivering in a mundane fashion every two weeks for an eternity. Sure, they take vacations to rest, but return to the same rat race when they left.

I’m going to do a little “back in my day” spiel. Back in my day, I grew up during the times when the Rational Unified Process (they call it “Waterfall” these days) was the industry’s preferred methodology. You would start on a project with a team and go through phases to complete the project. When you were done you took a little break, looked back on what you’d accomplished, felt great and rejuvenated, and started the next project as a new, stronger person ready for the next bigger challenge. All of that is gone today after a spree of Agile transformation initiatives.

We later incorporated aspects of Agile into Waterfall. Basically, you have a map of where you want to go with a finite amount of money for the road trip (the Waterfall part). But the details of which road you take to get there, considering how much time you have and money to spend on fuel and hotels (the Agile part within a contained timebox/budget), are still very much present. The sprinting wasn’t infinite, because we recognized that (just like when an athlete sprints) it’s a short duration with a big recovery period in between.

After the recent Agile transformation revolution, this is gone. Agile team members are often caught in an infinite rat race, working on an infinite backlog. There is no pause between projects — it’s all just one big never-ending project — and it shouldn’t be this way.

We were recently joking around the watercooler about Agile slogans and someone said “Agile — just sprint, don’t think!” And it’s often so true at big organizations. But it can be better.

So what’s the solution to this?

1. Divide the backlog into projects (a set of minimum viable products or MVPs) with a timeline and an end state.
2. Visualize a way to get to the end state — meaning think through the high-level design (both functional and technical) and how many sprints we can afford/need to get there.
3. Make implementation decisions with the end state in sight. Don’t assume there is infinite budget and time (or that more will be alloted) to simply add more to the backlog as you encounter obstacles on the journey.
4. Make sure to rest after delivering the project (or MVP) with ample recovery time. While resting, enjoy a healthy lifestyle for maximum recovery (sometimes easier said than done). My advice is to save at least two full days to relax and get back into a healthy, circadian rhythm before returning to work. i.e. Don’t return home from a holiday trip on Sunday night only to have to be at work on Monday.

As part of the journey, we have to overcome obstacles and still be at the destination relatively on-time and without having to regularly dip into our “savings” for emergency situations. This means look ahead. If you can’t see through the fog, look at a radar or a map of what’s ahead — think it through, visualize, and don’t just sprint with only two weeks in sight. And when you’ve completed a project (or MVP), take a vacation, reflect upon yourself, and take a moment to bask in the euphoric feeling of recognizing what you’ve built.