What’s the Problem? #

Problem? What problem?

Maybe your project is running smoothly. You know exactly what needs to be done, you’ve split up the work into sprints, and everything’s falling into place. Great! Fantastic!

Maybe agile wasn’t even necessary because you have a clear vision and a well-defined path to reach it. Perfect!

But the agile approach wasn’t created for projects where everything is straightforward and well-defined from the start. It was designed for the other type of project—the ones where things aren’t so clear. Where the vision or requirements keep shifting as development goes on, or where the end goal isn’t entirely understood right from the beginning.

Historically, those situations led to a lot of stress and strain on teams. Projects would run over budget or off schedule, and developers would get frustrated as they tried to hit a moving target. Agile was developed to help teams handle these types of projects more effectively, to adapt and evolve without derailing everything.

So, What’s the Problem? #

The problem is that, over the years, agile has drifted from its original intent. When the Agile Manifesto first came out, it sparked great discussions among developers about how to make it work in real-world projects. Early on, some teams began incorporating agile practices, making adjustments along the way. But somewhere down the line, agile started to lose its way.

Many teams have reverted to old habits. They’ve held onto agile’s terms and ceremonies but have forgotten its core principles. Instead of creating flexibility, they’re back to rigid processes, making everything efficient but not necessarily effective. The very problems agile was supposed to solve are creeping back in!

Now, many people think they’re “doing agile” because they use the buzzwords and go through the motions. But at its core, they’re still not fully embracing change or recognizing that quality and adaptability go hand in hand.

The Role of the Project Manager in Agile #

Interestingly, many agile coaches and Scrum Masters might not realize that some of the original founders of agile disagree with how it’s being taught and practiced today. Agile was initially designed from the perspective of the software development team. It didn’t aim to replace project management but to focus on a self-managing team that builds and delivers software with minimal outside interference. However, agile teams still need someone to help clear obstacles, facilitate meetings, and coordinate between departments.

A good project manager can play a crucial role by handling these broader responsibilities without micromanaging the team. Think of it like a restaurant kitchen: the kitchen staff—the chefs—know their craft. They organize themselves, handle different stations, and work together to ensure every dish comes out just right and on time.

Where’s the project manager in this scenario? Well, they’re like the restaurant manager. They don’t need to be in the kitchen telling the chefs how to cook; the chefs already know what they’re doing. Instead, the restaurant manager makes sure everything outside the kitchen is running smoothly: customers are happy, orders are being taken correctly, and the equipment is all functioning as it should.

Empowering the Team #

In the same way, a project manager doesn’t need to be deeply involved in the day-to-day work of the developers. The team should be empowered to collaborate, solve problems, and figure out the best way to meet the project goals on their own. When issues arise, like missing resources or tooling problems, they should escalate them to the project manager only when necessary.

If developers run into a question about requirements, they can talk directly to the business analyst, who acts like the waiter in our restaurant analogy, bringing the customer’s “order” to the kitchen. The goal is to keep things flowing smoothly while letting the experts do what they do best.