May 29, 2026
Volume 04 - Issue 21
This week I’m loving
This week we send love out to a piercing essay from Fabio Turel that honestly says exactly what we need to be hearing about AI right now.
Perhaps I identified with Fabio’s visual narrative about blown out umbrellas - as I also come from a place with this problem. I have seen the trees he describes.
Image credit: Kyle Brittain (@badweatherkyle) from Southern Alberta
Honestly, I looked for a way to excerpt the beauty of this piece to help you with it and I couldn’t.
Go read it, please.
From the Practice
This week’s “From the Practice” highlights important advice written by Robert Pieper and featured on the Responsive Advisors blog that covers some important nuances of Scrum that I’ve definitely seen frequently overlooked in organizations I have worked with. Read this to save some pain if you’re working in an environment that has implemented Scrum without improved outcomes.
First up is my personal pet peeve: bad habits with the Daily Scrum. Hint, if you aren’t discussing your Sprint Goal, you should read this.
Next, Robert covers, an important practice with Sprint Reviews that I’ve seen often help a team drift well off the path. Hint, if your team isn’t learning something helpful at every Sprint Review, you should read this.
Third on the list is what to do to make a Sprint Retrospective actually an exercise in continuous improvement. Hint, if you don’t have a task to undertake as a result of your Retro, you should read this.
Fourth on the list is the least understood facet of Scrum: the Increment. If you’ve never really understood what this is and your team continues to fail to produce working software at the end of each Sprint, you should read this.
Finally, one of the most powerful questions the team should be asking during a Sprint that rarely is used. If you are operating in a culture where delivering is more important that actually being “done”, you should read this!
Which problem plagues your Scrum team most often?
An interesting read
A lot of Generalist PMs can spot structural organizational failures, but a frustrating part of the skillset we are equipped with from our professional toolkit is that we may lack the skills to effect change that corrects the problem, even though we can see it. A huge part of why I write this newsletter is to close this gap.
So this week’s interesting read is a clever approach to validating your hunch about the structural problem and a potential way to talk about what needs to change to fix it. In my opinion, one of the most useful first steps is being able to talk about the problem as you don’t have to fix it alone. We sometimes forget that what we can see isn’t apparent to the folks around us. This approach is a great way to achieve shared clarity without getting anyone’s feathers ruffled.
In the article, Rob Lambert (Cultivated Management) introduces a concept he terms “the delivery ratio”. This ratio looks at the proportion of people working to deliver value compared to those organizing around it.
It is a structural observation. The individuals in every category are usually talented, well-intentioned, and working hard. What the ratio reveals is not whether those individuals are doing good work. It is whether the shape of the organisation — the proportions — is pointed at value creation or at something else.
To use it, first - classify every role in the organization into one of 4 categories:
Builders of value
Supporters of value delivery
Organizers
Administrators
Then, compare the number of roles in each category.
In healthy, growing organisations — startups, small teams, companies still close to their purpose — most people sit in categories one and two. The ratio makes intuitive sense. The organisation is lean in the direction of the work.
In large, established organisations, the numbers often invert. Categories three and four grow. Categories one and two shrink as a proportion of headcount. The organisation becomes, by slow accumulation, more focused on organising and reporting the work than on doing it.
There isn’t a right number here, so don’t focus on the numbers themselves. Instead what matters is the proportions.
If most people are in categories one and two — your structure is pointed toward the work that directly generates financial value. The organisation is doing what it exists to do, with appropriate support and organisation around it.
If most people are in categories three and four — your structure is pointed toward control and coordination rather than toward the external transaction. The organisation is spending more energy on itself than on the work that funds it. You have an Idea to Value problem, and it is structural.
Findings will also open the door to discussing how to restructure if necessary. And, importantly, the conversation can initially focus on what changes need to be made to rebalance the ratio, not who. That, importantly, helps in making the decisions about value and not performance which can help immensely.
You may be asking yourself, if we know this, why does it happen?
Control feels safe. It produces visible artefacts and tells leaders what they want to hear. It also produces real enablement value — organisations need structure, and some of that structure is load-bearing.
But only the work that reaches a customer produces the financial value that funds everything else. The organisations that confuse the two — that mistake the visibility of control for the evidence of value — build elaborate systems for watching work, and lose the ability to do it.
A tip
Don’t get me wrong, I am thrilled that PMBOK® 8th edition redefines projects around value as it is something I’ve been advocating for over much of the past decade. But while PMBOK mentions the word value 593 times, it only mentions “value delivery system” 8 times and that illustrates a huge gap in how well project managers are actually equipped to help organizations improve value delivery. The consequence is that many project managers can see the problem, but are left experimenting to try to fix it, or worse, just unsure about how to support and advocate for the changes required.
If this interests you, Generalist World members can attend a workshop I have coming up next week that will examine Value Delivery Capabilities, how to recognize common antipatterns and strategies to work through these problems. Register here. This session will also be recorded and available afterwards for members that can’t attend live.
I’m also teaching a 2-week series building skills for project managers around value delivery in my community for women in project management that is set to start June 8, 2026. Register for this here. Note that these sessions are exclusively for those who identify as women.
A lesson
This week’s lesson combines advice from a few folks to build skills around project scheduling.
Ivaldo Monteiro and Arsalan Adil built a great cheet sheet around the most common mistakes in scheduling projects.
Image credit: Attributed to Ivaldo Monteiro and Arsalan Adil by Ricardo Viana Vargas.
But the real lesson is in Ricardo Viana Vargas’s post that highlighted this cheat sheet.
…scheduling in project management is often treated as precision work, when in reality it is about managing uncertainty.
Pause, and think honestly for a moment, how often you have worried that a project schedule is accurate? How much time did you invest in trying to get the team to give you accurate estimates so you could be sure your schedule was right? How much energy did you focus on making your schedule detailed and pretty?
These are all precision habits.
If we treated the schedule as a risk register and instead looked at all the ways things might go wrong and planned strategies to mitigate those events, the schedule output of that exercise would be far more valuable and probably more accurate to how things will unfold.
A common scenario I have encountered is project managers who ask me how to plan their agile project. The key problem of course being that if you are used to having estimated durations, an agile project can present a whole new level of ambiguity and unknowns.
My answer to this is, just plan timeboxes. Let’s say for example, the team will iterate in two-week cycles. You have 16 weeks until the project deadline, so you have 8 timeboxes.
What’s the goal to be achieved in each timebox that builds toward the project outcome?
A schedule is only useful if it reflects how the project is actually being built, not how we wish it would be built.
After you’ve planned your timeboxes, then look at what happens if those goals aren’t achieved. That might change your commitments or it might give you a narrative for your stakeholders to ensure expectations are managed. Either way:
…simplicity wins over complexity
Because in the field, clarity is what drives execution... not detail.