A project director at a client company asked me for help with sprint planning and retrospectives. He said: “I encourage people to participate, but they don’t say anything. It’s like pulling teeth.”

Have you ever had this concern? It’s incredibly common. The following diagnostic questions tend to be helpful… except they weren’t, this time: Are the meetings set up for engagement? Do folks feel psychologically safe to participate? Do they understand the mission and care about it? Have they bought into Agile?

As these questions didn’t uncover any problem, here is more context: the team is building websites through which the company’s products may be sold under partners’ brands. They’ve recently finished the first such website, and are now working on a similar website.

Mindset drives behaviour. Senior management (I’ve spoken with most, including the CEO) genuinely want to adopt an Agile mindset and Agile behaviours across projects. They are explicitly supporting this second website as a pilot Agile project. Yet, what is the de-facto mindset of the team for the work at hand?

Value (= most important): delivering on time. The contract has an explicit date.

Belief (= fundamental assumption): The work for this second website is essentially the same as the work for the one we recently finished.

A team with this mindset (“delivering on time,” “We know the requirements,” and “We’ve done this before”) would not be wrong to take a Waterfall approach. Using sprints won’t matter since the work is known, understood, and mostly preplanned. Demos won’t matter for the same reason.

However, before ruling that Agile is not a fit for this work, it might be useful to challenge prevailing beliefs. In this case, although the team has done similar work before (and delivered it on time), has the work produced the outcomes the company wanted? Specifically, has that first website done a good job converting visitors into paying customers? Can we do better this time?

The same day the project director asked me the question, I was teaching the company’s QA department to do exploratory testing, and we practiced the approach with the customer journey of the first website. While the site is functionally correct and meets all the requirements, we learned that the customer journey has several wrinkles, which made us worry about the drop-off rate.

If an analysis of the first website’s drop-off rate reveals that it’s high, an Agile way of working should help make better design choices for the second website. For such a way of working to matter, a proper cross-functional team (including design, marketing, etc.) should understand their users, work from outcomes, test their assumptions, and explore their product — not just do sprints of coding and testing from requirements.

The project director’s immediate problem was that the team “wasn’t biting,” despite formal support for Agile. The real problem was that all the conversations around the project were based in a Waterfall mindset. I suggested he discuss this dissonance with management and that they determine a strategy (mindset) going forward.

The story ended a few days later with an unexpected twist. He did speak with management, and they paused the project… but for a different reason. They realized that another management habit of theirs — maximizing “resource utilization” by splitting people across projects and obligations — was delaying everything in the pipe. They reduced their WIP by pausing the project and allowing the team members to focus more on their other obligations. Along the Agile journey, this is one of the hardest lessons to learn, so I’m happy for this plot twist!