Lessons from the Battlefield of Project Leadership

This article was generated from a transcript of an internal Leading EDJE presentation, "Lessons from the Battlefield: Tales from Project Leadership" (April 29, 2025), and augmented using AI. Quotes have been lightly edited for readability, and client names have been removed.

In April 2025, Leading EDJE's project solutions guild brought a panel of project leaders together in front of a live audience to trade stories from the field. Their answers kept circling back to the same idea: the technology is the easy part.

Embrace Uncertainty

The moderator opened by asking each panelist for one insight most people in their field still don't seem to know. The first answer set the tone:

Embracing uncertainty is probably the one thing I feel like people don't really grasp with agile. … There's more that we don't know than we know.

That panelist cited a data scientist's study of feature experiments at Microsoft, Google, and Netflix:

Two out of every three ideas at Microsoft either did nothing or retracted from the measures that they were supposed to be improving. … At Google I think it was 10%. … And then Netflix, I think it's 90% wrong. So we don't know. … We crave that certainty.

Another panelist reframed estimation with a road-trip metaphor: the 1980s AAA TripTik.

It would tell you this is how long every single page is going to take you to get there. But it was never right. … It's evolved into Google Maps now, but still you don't know what lies ahead. It's always constantly updating. And the estimation is really: we think it's going to take about this long to go where you're going based upon what we know today.

The art of estimation is really just, one, making sure you document the crap out of everything that went into that estimate, and two, being confident in it and speaking with confidence.

For a data-driven way to keep that kind of estimate up to date, see Agile Forecasting: Monte Carlo Simulations and Flow Metrics.

Own It Like It's Your Own Business

A third panelist added focus, empathy, and fun. Focus came with a story from a healthcare client when COVID hit:

When we had to focus on getting the medical version of Zoom up, it was done in two weeks. It would have taken us two or three months before. … People rally around the goal and then they just put all that focus on it.

The fourth answered from a leadership perspective:

We as leaders need to own it, and that is my mantra every day when I walk into a client site. Program and project managers are ultimately accountable for the successful delivery of a project. … We need to own our projects and our programs like it's our own business and as if our future really depends on it, because it does.

That ownership includes tough decisions ("it's important that we don't allow ourselves to let what we think other people think of us drive our decision-making"), emotional intelligence, and mistakes:

It's my job to regulate my emotions throughout the project … definitely through the challenging times, because the teams are going to be looking at us, and if we're unsteady on our feet, the team's going to be unsteady on their feet.

We're going to make them. We need to learn from them and move on and not live in the space of disappointment or regret.

What Made Their Best Teams the Best

Asked about their best teams, the panelists described empowerment, shared accountability, and a little fun. One credited a truly empowered product owner, the gap they see at most clients:

If there is a product owner, it's typically a BA and they can't make the decisions, or they're non-existent, or they're spread on other projects. This was the first one where I felt like we had a true product owner who partnered with the team.

Part of what made that work was treating the product owner as one of the team, including in Jackbox games: "we got to know her more as a person … It wasn't just her giving us items in a backlog."

Another remembered a team that built something from nothing:

We all kind of stood around the room and looked at each other and we're like, all right, we are solely accountable for this. Nobody here fails unless we all fail.

A third described leading a large retailer's first agile transformation pilot, delivering a new warehouse management system. Their list of what made it work is worth keeping as a checklist:

• Executive sponsorship. "I think it's really important to have that top-down support."
• A pilot. "Whether it was successful or it failed, it would have been a success because we would have at least failed on a much smaller scale."
• A lead team of scrum master, program manager, agile coach, tech manager, tech lead, and architect who "was in lock step the entire project" on its top three priorities.
• 100% allocation. "We didn't have to fight with production support."
• Visible energy. "When you're looking to transform an organization and people walk by and they hear that and they see that, it's contagious."
• A collective vision. "How does their role fit into that vision? … It makes it so much easier to hold people accountable when they've committed to the work."
• Guardrails, then autonomy, plus team norms set up front.

Why Agile Becomes "Waterfall in Sprints"

The moderator asked why most companies that say they're implementing agile are really just cutting waterfall into sprints.

It's because that's what companies have control over. … They have control over the scope. They have control over the budget. They have control over the timeline. … It is much harder to try and measure success on: does the customer enjoy our product? Are we able to ship frequently and learn from what we've delivered to them? Is that having the revenue impact?

Another panelist pointed at how companies are organized:

They still see it however many years later as a support organization to the business instead of the organization that's helping to drive the business forward.

And it isn't a new conversation:

The conversations now around agile and waterfall are the exact same conversations we had in 2002 around the Rational Unified Process and waterfall. … "You're just doing mini waterfall." … It's just 20 years later that we're having it.

One panelist had just joined a team that said it was doing sprints. When they did the math, about 80% of the completed work was outside the sprint. Their fix: "It takes somebody sometimes to just step up and be like, 'We're not doing that. We have to do it this way if we truly want to get the value out of it.'"

Why Project Leaders Still Matter

Scrum master and project manager roles are often the easiest to cut "because they're not writing code or producing direct output." The panel pushed back:

There is absolutely relevancy in having strong project leaders. Call them whatever you want. … Anyone who has ever worked on a project that didn't have a strong person in that role, you would say it failed.

The scrum master role was set up so you're in a position where you're trying to provoke change from a position of no authority. That is hard to do. And if you get a bunch of entry-level people into that role … they're probably going to resort back to the easy route, which is probably zombie scrum, just going through the motions.

The problem, as one panelist put it, is measuring the wrong thing:

If you're only focused on outputs, then you might not see the value in a scrum master because you don't see what they're doing. … You're responsible for ensuring the outcomes are what the business needs, and that's not an output-driven role.

That echoes the argument in (Mechanical) Scrum is Dead. On large programs, another panelist sees the role shifting toward risk management and cross-team dependencies: "Yes, AI can be used to identify risks, but I think what AI lacks is the soft skills."

Getting a Project Back on the Rails

Every panelist had a story about a project that went off the rails.

Make the work visible. One walked into a daily scrum that was "purely a status meeting." The first moves were a Kanban board, which "just showed how many things that they were working on at one time," and then limiting work in progress (WIP). The hardest part was above the team: "If you don't have buy-in from the leadership level … it's really hard to become a more mature agile team."

Respect the triangle. On a 180–200 person program five months from go-live, the trend went the wrong way and "the business would not cut scope." Slipping a month meant millions of dollars, so the team worked extra evenings twice a week for months. On a later project the business asked to add scope, the panelist said something else had to go, and the team cut a requested MVP down "to a real MVP" and still delivered on time.

Passionately defend the right plan. Early in their career, one panelist presented two plans: one that hit the date with back-to-back releases, and one with contingency that didn't. Leadership chose the date. The result was three months of production triage, and the lesson came from the CIO:

People never remember when you delay a project, but they always remember when you deploy bad quality.

I will passionately defend the right plan. … It's not going to be me reading the risks. It's going to be me passionately defending it so that I am heard. I could still be overruled, but it's not going to be because I just read the risks.

Beware the watermelon. Another described "the watermelon effect": "green on the outside and red on the inside." On a 30-plus-million-dollar program, with about $20 million spent, the CIO asked what they needed to do:

I said you need to stop. We need to stop. And the reason why is because we have no clear direction of where we're headed.

The client agreed and pivoted. "At some point in time, it's just always best to pause and regroup and rally the team back together towards a common goal."

The Biggest Misses

The last prepared question asked for the biggest misses the panelists see in the industry today.

Not connecting with the vision and the overall goal of the program. … Instilling that purpose into the team can drive so much better behavior when they know why they're doing it.

Projects rarely go off the rails or fail because of technology. They fail because of people and process. … Do you have the right people in the right seats who are really dedicated, working together, collaborating, communicating, and do you have the transparency across the team to be able to feel like you can speak up and call it out?

People don't focus when their managers don't focus, and managers don't focus if they don't have goals. … It's hard to have focus when you don't have goals.

In business, the big things matter. … You may not solve them in three days, but you should have a plan within two to three days for how you're going to solve it.

And one that resonated across the panel: don't delay escalations.

When I first started out as a PM, that killed me every time. You'd be afraid to talk about risks. … But once you got it, it made your life so much easier.

Self-Organization and "the Brent"

A closing question asked how to keep resource allocations from being treated as "100%." One panelist's answer was self-organization: "They know their skill sets better than I do. They know their vacation. … That's empowering people to do the work and to be accountable."

That prompted a follow-up familiar to anyone who has read The Phoenix Project: what if you have a Brent, the exceptional person everyone ends up coming to?

I think it comes down to coaching. … How do you coach that person who is the know-all person to teach other people how to fish, not fish for them?

You want the team to be cross-functional. … If you constantly see them relying on outside teams, that should be a trigger: how do we get that knowledge into the team, or is there a gap on the team where we need to bring someone else on?

Someone in the chat summed up why it matters: "The culture that rewards fire-fighting breeds arsonists."

Closing Thoughts

Across uncertainty, ownership, great teams, and rescued projects, the panel kept coming back to people: leaders willing to speak the truth, teams with a shared vision and the autonomy to act on it, and organizations that measure outcomes rather than outputs. For more on making delivery predictable without pretending to certainty, see The Physics of Predictability.