In my experience working with teams ranging in size from a few developers to large enterprise development projects, one of the recurring themes I’ve seen is that of process.

The best teams I’ve worked with have processes in place, but they are streamlined, honed routines without the overhead of decision making or heavy ceremony.

When I first started working in an Agile environment, it wasn’t one I was dropped into, with a well-defined way of managing the process. Rather, it was a company-wide initiative to move to an Agile methodology from a strongly-ingrained waterfall one. The company’s digital arm started a division-wide initiative to certify all of its developers, project managers, QA staff, and leadership with the goal of making SCRUM a first-class citizen in the organization.

As with most large transformations of this sort the change management process was a long, arduous one. SCRUM coaches were hired, every member of staff was trained and certified in all things Agile, and several team sessions were held with our internal SCRUM knowledge expert to practice these new techniques. We were all excited about the promises that Agile would bring—who wouldn’t be? Especially with shiny new Certified ScrumMaster notches in our belts.

Agile’s Broken Promise

Unfortunately, in a company not quite ready for the change, Agile isn’t really all it’s sold to be.

You see, Agile has to be adopted from the top down. Leadership has to get on board with the changes that Agile brings. And when I say leadership, I’m not talking about director-level or even VP level and below. I mean all leadership—all the way up to the president and CEO of the company.

You see, without full adoption, at some point someone in leadership is going to want to see a GANTT chart. Without full adoption someone is going to want to define set-in-stone delivery dates with resource plans, user flow diagrams, and detailed specs before an actual line of code is written. This overhead trickles down to the developers and any level of non-adoption creates an unavoidable rift in what should otherwise be a holistic effort.

Waterfall isn’t perfect; but it’s a hell of a lot better than scrummerfall.

A broken Agile strategy doesn’t just introduce complexity in delivery and tracking. It causes a painful and frustrating disconnect between developers and upper management. It’s a modern-day language barrier that prevents the people building the project from effectively communicating with those sponsoring and paying for it.

But There’s Good News: Agile Works, If You Do It Right

The companies with the worst adoption of Agile are the ones who aren’t willing to embrace the simplicity of it.

Agile is best when you focus on the essentials.

At its core, Agile is an incredibly simple concept, which is why it’s both easy and confoundingly difficult to execute. Where I’ve seen teams try to adopt a simple project management concept like Agile and fail, I’ve noted two diametrically opposite problems:

1. They try to use too little of the framework, and end up just labeling their work items “stories” and “defects”, and doing obligatory “standup” meetings which provide little or no actual value.
2. They try to use too much of the framework, and end up exhausting team members with more overhead and ceremony than they care to deal with.

So how does a team find a happy medium and implement Agile project management in a way that works?

The answer lies in dissecting the two points above and finding where the problems of one are solved by the benefits of the other. And no matter what anyone tells you, this will differ by team. Some teams work better together by having longer standup meetings with slightly more discussion and planning, while others benefit most by keeping standups punctuated and focusing instead on swarming outside of meeting time.

First, holding daily standup meetings and calling yourself Agile is a waste of time (not to mention that a traditional standup format really doesn’t provide much value in the first place.) Effective project management requires a set of tools, not just a single one.

Second, there are several tools in Agile that complement the standup, and each one has a special and specific place. But don’t keep doing something just because you’re supposed to follow the framework, especially if it’s not providing real value. Adjust things to work, and drop them if they don’t, but do this with intention and care.

So What’s The Solution?

Agile works best when it becomes a routine. It should be a strategy, not a process.

What does that mean? Let me put it another way:

Seek to uncover the essence of Agile and what works for your team; don’t just do a bunch of shit so you can check off the boxes and say “we do the Agile things.”

Agile is never going to work for a team that holds all the prototypical meetings and never considers whether they’re helpful or not. Every retro meeting should be an opportunity to discuss what elements are working for the team, and how they can be improved. Like in code, the adoption of Agile is a long-term effort and best done iteratively.

One of the big wins built into Agile is its predictability. Team members must be given core time to focus on their work and a limited set of well-defined, scheduled meetings with clear objectives is the best way to grant them that.

Retro meetings at the end of every sprint are invaluable and yet many teams don’t even have them.

Standup meetings should be timely and pared down to the essentials, but more valuable than “this is what I did yesterday, this is what I’m doing today, and I have no blocks” (but please, save technical details and solutioning for a parking lot discussion.)

My point here is that we work best with routines in place. That’s just how the human brain works—always working to optimize and move problems into background processing, and routines allow that to happen.

Decision fatigue and context switching are productivity killers, and a streamlined (read: well-defined, predictable) Agile routine is your best tool to combat them.

Want to see team productivity and individual happiness levels skyrocket? Eliminate wasteful process, create predictable routines, and pare project management down to the essentials.