Ask Me Anything: What questions do you have for expert Mike Griffiths about alignments and disconnects in Agile and predictive approaches? 

Arguably the most effective agile process is the retrospective, since it is the vehicle for review, experimentation and change. Starting with just retrospectives, you could analyze your project team’s current ways of working and pain points then start addressing them.

We do not even have to call them a retrospective, if that might be considered controversial in a predictive (waterfall) environment. Schedule a “team review meeting” and ask how things are going? One retrospective format asks team members to think of things we should start doing, or stop doing. Any activities we should be doing more of, or less of?

Then, prioritize two or three suggestions to try for a couple of weeks. Meet again and review how these experiments are going. Do we want to make the changes permanent, or try something else? When people see their suggestions have an ability to change how we work (if even as an experiment to start with) they often get more engaged and motivated in their role.

Maybe we introduce periodic lunch-and-learns to show-and-tell what we have been working on to the business and discuss what’s planned next (that’s the essence to an iteration demo.) We can incrementally try other portions of agile processes, capitalizing on what works and adjust what needs attention.

An agile delivery approach works well with fixed fees and fixed deadlines, providing there is some flexibility in the scope. Agile teams can work towards delivering all the must have, high priority features towards budget and timeline limits. Because the customer (via the product owner) is in charge of prioritization, there are no surprises in what gets delivered with these constraints.

So, this would be called “Fixed-Price with Agile Scope Management” where the fee and deadline are fixed. Scope is variable. The client prioritizes the most valuable features in each iteration. Work is delivered incrementally; the contract acknowledges that not all wishlist features may be delivered. It is sometimes called “Fixed Price for a Product Backlog Budget”. Best for: Clients who care more about outcomes and who trust the team to maximize value.

Other options include “Incremental or Rolling Fixed-Price Contracts” where the work is broken into fixed-price increments or phases (e.g., per sprint, per release). Here, each increment has a defined goal and cost. This allows reprioritization and re-estimation between increments. Best for: Projects with evolving understanding, but milestones that need budget certainty.

This could morph into a “Target Cost (Incentive-Based) Contracts” where the client and vendor agree on a target cost and share savings or overruns. The team works in agile fashion, but incentives are aligned to stay within cost/time. Scope remains flexible, and collaboration is encouraged to reduce waste. Best for: Partnerships built on trust and shared goals.

Finally, I have also seen “Time and Materials with Cap (T&M NTE)” type contracts work well. Here billing is based on time and effort, but with a "not-to-exceed" cap. It allows agile flexibility while protecting the client’s budget. Best for: When actual scope is uncertain, but budget risk must be controlled. Such as many of today’s AI projects.

Thanks Jenny, I am happy to be here!

One of the most common challenges I’ve seen when organizations adopt agile is a misalignment with client expectations. This is especially true in services or consulting firms that are used to fixed-scope, fixed-cost projects. These clients expect detailed plans, clear milestones, and defined deliverables before work begins. Agile introduces a more adaptive and iterative way of working, which can feel vague or risky to them.

To address this, successful teams begin by educating clients. They explain how agile contracts can still offer predictability, just in a different way. For example, some use fixed-price discovery phases or time-and-materials for development. Others define clear outcomes rather than locking in features. Starting with a small agile pilot builds trust and helps demonstrate value.

Another challenge is confusion around roles and internal resistance to change. Traditional delivery models often rely on project managers who assign tasks and control the timeline. Agile shifts that model to shared ownership and self-organizing teams. People sometimes feel uncertain about how their role fits.

Organizations that navigate this well offer coaching for each role. They help team members see how their skills apply in an agile setting. They also create a culture of psychological safety. This allows teams to try new ways of working without fear of blame. Some set up internal groups where Scrum Masters, Product Owners, or team leads can share what’s working and learn from one another.

A third challenge is how success is measured. Traditional metrics like utilization or percent complete don’t work well in agile. They can even create pressure to focus on the wrong things. Agile teams need to measure outcomes, not just activity.

Better metrics include value delivered, story cycle time, or client satisfaction. These can be supported by qualitative insights from retrospectives. Many organizations now involve clients in defining what success looks like. They check in regularly to see if that value is being delivered.

Thank you for the kind words about my book, much appreciated! You're right that retraining everyone from scratch is rarely feasible or well-received. Instead, here are some ideas to raise agile understanding across a large organization where inconsistent practices or misunderstandings may already be embedded.

1. Facilitate Peer Learning Circles
Instead of creating a formal network of champions, invite open peer learning circles where anyone interested in improving agile delivery can join. These can be facilitated by someone with experience, but the focus is on open discussion, and shared challenges. Rotate who facilitates. Feature topics like “What agile means to us,” “Where we're improvising well,” or “Things we do that might not be agile.” This removes hierarchy, builds psychological safety, and gives people a voice regardless of title or role.

2. Use Visual Models and Practice Maps to Clarify the Confusion
Many misunderstandings stem from vocabulary confusion or partial understanding. A great way to level-set without formal training is to use simple, visual maps of agile practices, life cycles, or roles and responsibilities. Show where current practices sit on the agile spectrum, what's working, what's misapplied, and what’s missing. Visual comparisons (e.g. contrasting waterfall, Scrum, Kanban, hybrid) help reduce ambiguity without blame. Invite teams to locate themselves on these maps and reflect on opportunities for evolution.

3. Create Internal “Myth-Busting” Workshops or Agile Clinics
Instead of long workshops, offer short, focused “Agile Clinics” or “Myth-Busting” sessions. Each one tackles a real scenario or misunderstanding—for example, “Why Scrum Doesn’t Mean No Planning” or “The Role of the PM in Agile.” These sessions should be informal, practical, and grounded in real team examples. They work well when co-facilitated by someone from delivery and someone with coaching experience. Over time, this format builds shared understanding without requiring wholesale retraining.