Category: Operating Models & Flow

How software organisations actually deliver: team-of-teams structure, flow economics, cost of delay, and the constraints that decide throughput. Reading the system, not blaming the team.

Agile Lessons from the NUMMI Team Member Handbook
[May 2026] The safety frame I’m reaching for here is what Edmondson formalises as psychological safety and what Dekker grounds in just-culture. Modern Agile’s “safety as prerequisite” has matured into a richer literature on near-miss reporting, blameless inquiry, and learning-organisation discipline.
[August 2026] What the handbook shows is a company that changed the conditions rather than exhorting people to try harder inside the old ones. The line I quote here, “You just don’t see the line stop,” is the contrast Chapter 6 of Come Prepared to Die builds on, where I set NUMMI against Deming on tampering and Seddon on failure demand, and treat a Definition of Done as an andon cord.
I recently came across Mark Graban’s “Highlights from the Original 1984 NUMMI Team Member Handbook” series. Digging through the archives at Ephlin’s UAW office papers were archived at the Walter P. Reuther Library at Wayne State University in Detroit, Mark found some absolutely extraordinary gems, including this one.
Standing on the shoulders of giants, I reached out to the archivists at the library to see if I could get a copy of the full handbook. They cheerfully obliged, and rather quickly at that!
Grab the PDF and peruse for yourself. The first several pages are the most interesting, but even as you explore the rest of it pay attention to how human and reasonable it is. Mark provides an excellent commentary on several key sections, so I’ll try to avoid highlighting the same thoughts. I hope you’ll share your own findings and commentary in the comments below.
Here are some of the gems I’ve found:
Notice that the first objective is “To help [employees] develop to [their] full potential.” In fact, these objectives start with the individual employee, progress to the company, and then ultimately end with the customer receiving the “highest quality automobiles in the world.” This is a notable inversion from the usual objectives, which usually prioritize stakeholders and customers, then the company, then⁠—if at all⁠—the individual employee.
This is extraordinary in two ways. First, employees are given the expectation that they are going to have a greater autonomy and influence over how other aspects of the organization operate. I’ve heard the statistic that Toyota’s 300,000 global employees make a total of one million suggestions annually, 97% of which are implemented. Secondly, note that the employee handbook is characterized as helping the employee “do [their] job better,” a far cry from the usual purpose of this kind of handbook (protecting the company’s interest).
(more…)
23/02/2017
On Doing Versus Being Agile
[May 2026] I now reach for Schein on culture, Westrum on generative-vs-pathological organisations, Edmondson on psychological safety, Senge on learning-organisation discipline, and Galbraith’s Star Model alongside Org Topologies for structure as the more rigorous current vocabulary for what this post calls “structure and culture.” The doing-vs-being distinction still holds; the toolkit has matured. I’ve also since added a fifth box at the cheap end of the diagram, to the left of tools: “terms,” changing the words you use. It’s the easiest change and the emptiest one, and I can’t claim much originality for it. Craig Larman named this years ago in the second of his Laws of Organisational Behaviour: any change initiative gets reduced to redefining or overloading the new terminology to mean basically the same as the status quo. New words, same operating model.
[August 2026] The NUMMI listening questions I set out here, about what changed in the plant and what GM could not replicate elsewhere, are the ones I work through at length in Chapter 3 of Come Prepared to Die. Same plant, read the other way round: the chapter takes NUMMI as the inverse case, where GM copied the production system and left the structure alone. AI now hands you the tools-and-process win almost for free, which leaves the structure you never touched as where most of the remaining gain sits. I came back to that plant from a different angle in the Team Member Handbook post.
Are you doing Agile, or have you become Agile?
The difference seems pedantic at first…
You are doing Agile when you’ve changed your tools and processes. This is relatively easy to do but doesn’t offer much in the way of benefits. You’ve become Agile when you’ve changed you structure and culture too. This is relatively hard to do, but offers significant benefits.
Agile isn’t just a process. It’s a complete framework that brings together a shift in culture, structure, and processes. This framework is supported by tools such as Rally and other Agile Lifecycle Management (ALM) tools.
(more…)
19/03/2016
How Scrum Teams Can Seek Out and Destroy Organizational Impediments and Unplanned Work
[May 2026] I’d now call this the early Planned/Unplanned Velocity instinct. The 2014 practice (track unexpected requests and impediments as a separate signal) has matured into SPC control charts on the two streams (Shewhart, Wheeler) plus a displacement rule that triggers intervention when unplanned work crowds planned work; same instinct, sharper measurement.
[August 2026] The refusal at the heart of this post, that a team landing at 72% has told you something about its conditions rather than about itself, is what Chapter 14 of Come Prepared to Die works through. The chapter carries it into incident response, where hunting the operator who deviated leaves the conditions that produced the deviation untouched.
A team should be able to complete 80–110% of their planned stories each and every sprint without heroics.
Why is this important?
- The work output from this team is predictable. When the team commits to a set of stories at the beginning of the sprint, other teams can rely on them to deliver.
- Predictable output breeds confidence. If a team consistently delivers on their commitments, they are considerably more credible when they need to push back on unrealistic expectations.
- The team will likely feel motivated because they’ve demonstrated a degree of mastery in their craft.
- The team has a stable base. Because they are delivering on their expectations, they can focus their energy on continuous improvement and optimization.
If a team regularly completes less than 80% of their sprint objectives, why does this happen?
- The work tasks do not meet INVEST criteria and thus cannot be estimated accurately.
- New work is given to the team mid-sprint.
- The team faces new and old impediments that interfere⁠—usually unpredictably⁠—with their ability to deliver the work.
It’s not always easy to glean these issues from tools like Rally. Thankfully, there’s a simple solution that can help both individual teams and the program discover the severity and nature of the issues that prevent a team from achieving fast, flexible flow.
The Status Quo
Let’s take the example of a 2-person team working a 2-week sprint. (This isn’t an ideal team setup, but it keeps the numbers easier to work with.) Here’s their sprint backlog a few hours after planning:
They’ve taken on 39 story points, which is one fewer than the 40 accepted story points they completed last sprint. That’s perfectly reasonable.
They’ve added tasks to each of these stories and began work on the first one.
I like to assume 6 hours/day of productivity per developer to account for planning meetings, standups, retrospectives, breaks, lunch, etc. Two developers * 2 weeks * 6 hours/day = 120 hours. Assuming a 25% “safety factor” (some teams use 30%, others use 20%, the truth is that we’re splitting hairs at this point), the team should be able to complete about 96 hours of planned tasks this sprint. They’ve identified 93, so this “smells” okay.
(Note: the team should use story points to gauge how much work to accept into the sprint backlog. Use the task hours as a sanity check.)
Let’s fast forward a week and a half. It’s Tuesday afternoon, and there are about 2-1/2 days left in the sprint:
The product owner accepted 18 points or 46% of the sprint. There’s 36 hours of work left and about 30 hours of time left, so we’re a little behind. Most novice Scrum teams would not register concern at this point.
What happened during the sprint? The development team raised impediments during the standup and worked through them. One developer was out sick for a day. The team had to go to an unexpected all-hands meeting, and they had to do a couple of side projects.
The problem is, there’s no measurement or record of these unexpected requests and impediments. The unexpected requests should not have been added mid-sprint unless they were (rare) “on-fire” issues. The team (and anyone who attended the standups) would know what the issues were, but this knowledge is limited or non-existing at the program level or higher.
This is a missed learning opportunity as we do not have the transparency we need to inspect and adapt.
Introducing the Unexpected Requests and Impediments Story
Let’s rewind and add a new story to the sprint backlog:
Note the addition of “Sprint 5 Unexpected Requests and Impediments” at the bottom. This doesn’t get story points and it’s at the bottom because it’s the last thing you want your team to be working on.
Each and every unexpected request or impediment gets added to this story as a task (with hours) during the sprint, like so:
Suddenly these side projects and impediments become real.
Let’s take a look at that mid-sprint view of the backlog again.
Suddenly, the problem becomes even more clear. We should be able to complete about 120 hours of work in a 2-person, 2-week sprint, but our task estimate is now up to 139. Unless this team works overtime (which they should not do as it is demotivating and ultimately productivity-killing), we’re not going to complete all of our stories in time for the demo.
So here’s where this team ended up right before their demo:
They completed 28 story points or 72%. A “pointy-haired boss” might look at this team and say “you failed.”
That statement in and of itself is a failure. It jumps to the conclusion that the team experienced a performance failure. In reality (with all credit due to Mary Poppendieck), the more likely failure is that of the original hypothesis: that the team could have completed the work in the first place. There’s a major missed opportunity: the opportunity to learn something from our system and adapt.
We budgeted 25% of our time for these sorts of issues, or 24 hours. We wound up with 46 hours of unexpected requests and impediments, 22 hours “over budget.” We had 15 hours of work remaining on the two stories we didn’t complete, so it’d be pretty reasonable to say that had it not been for those extra 22 hours of work, we would have completed this sprint (and perhaps even added a 1- or 2-point story).
Ideally, you’re keeping track of your velocity from sprint to sprint. Add another metric: keep track of the percentage of task hours each sprint that came from unexpected requests and impediments.
So what?
Now we have transparency. Transparency allows inspection, inspection allows adaptation. Here are some ways to use this information to inspect and adapt:
- The team can review the impediments and suggest user stories to the product manager (often spikes or technical user stories) to help address some of the underlying technical impediments.
- The team can use this as feedback that they may need to slow down and refactor to address technical debt. They may not want to create new user stories, but they should at least spend a little extra time on their new user stories to clean up old debt and avoid creating new debt.
- The Product Owner can show stakeholders the cost of unexpected requests and impediments on their predictability. This gives them the evidence they need to hold off on new requests until the next sprint and spend more time building quality into the work that they are doing.
- Engineering managers and program managers can review impediments across teams and look for impediment patterns to solve. For instance, an engineering manager may be able to quantify that the company spends 10-15% of their development time fixing broken environments. This data could justify an much-needed investment: “We lose $1M a year in productivity fixing broken environments [based on salaries multiplied by time lost]. A new VM system would reduce this cost by 50% and cost us $100K.”
There you have it. Regardless of the software you use (if any), you can add the Unexpected Requests and Impediments story to your sprint backlog. You can use the data it generates to gain knowledge and take corrective action.
What are your thoughts? Have you used something like this in your own team? Please share your thoughts!
30/07/2014
Mary Poppendieck’s “The Tyranny of ‘The Plan’”
[August 2026] Mary names a paradigm here that I’ve since written a book around, and she got there well before I did. Her claim is that a schedule rolled up from a work breakdown is a hypothesis dressed as a commitment. Chapter 7 of Come Prepared to Die works that axis and leans on this talk to do it, particularly her reading of Sapolsky on Polaris, where PERT turns out to have been a façade built to keep Congress paying. Her Empire State material runs the other way, toward Chapter 8. They had a fixed date, 1 May 1931, because that was when New York leases turned over, and on the day the contract was signed there was no design. The stone went up in 8 months. The job came in 18% under budget. The Empire State build is also the cleanest case I know for scheduling by flow rather than utilisation; I take that up in Utilisation vs Flow. If your plan keeps going nervous on you, the plan is likely the problem, not your team. Working out which one you have is most of the diagnostic I run. If you want this school of thought as a primary document, the 1984 NUMMI team member handbook shows the same thinking written for the factory floor.
A couple of years ago, my former manager David Denton forwarded me a recorded presentation by Mary Poppendieck, a leading Agile software development expert and co-author of the popular book “Leading Lean Software Development: Results Are not the Point.“
Watching the video on the InfoQ website is a bit kludgey and Mary has lots of wonderful details that are worth hearing. So, with Mary’s permission, I’ve had the video transcribed and included her slides in context. I hope that this will make this very useful knowledge easier to find and learn from. Mary, thanks again.
I’ve eschewed block-quote formatting as it made this transcript a little harder to read. I’ve also edited slightly for readability. Otherwise, everything beyond this point is Mary’s work.
(more…)
20/09/2012
The Customer is the Marshmallow
[May 2026] This argument still holds. Both “ship quickly and often” and “defer commitment” remain true today; cost-of-delay weighting (Reinertsen, Fox & Gregory) and real-options framing are the sharper economic vocabulary that grounds them.
[August 2026] “They build slowly and test often” is the practitioner’s version of an argument I make more formally in Chapter 7 of Come Prepared to Die: a plan held as a commitment kills the learning, and a plan held as a hypothesis invites it. The marshmallow is what a premature commitment feels like when it lands.
Spaghetti and Twine
Many of you will be familiar with Peter Skillman’s Marshmallow Challenge, an exercise frequently given to teams and business school students. Teams of four are given 20 pieces of spaghetti, 1 yard of tape, one yard of twine, and a marshmallow. They are then given 18 minutes to build a free-standing structure that places the marshmallow as high off of the table as possible. The team with the highest marshmallow wins.
If you haven’t seen it already, Tom Wujec’s TED talk is a good place to learn about the challenge. And if you haven’t introduced your team(s) to it, take 45 minutes out of one of your days to administer the challenge and see what revelations you get.
(more…)
01/06/2012
A Retrospective on Managing a Client Services Team
[May 2026] The instincts in this essay still hold; the vocabulary has caught up. I now name the headcount-process-tools progression as constraint-led capacity work (Goldratt), the support team as a feedback loop in the organisation’s learning system rather than a conduit, inter-departmental SLAs as the kind of cross-functional commitment Deming’s “94% systemic” rule demands, and the recipes-for-failure list as a systemic-failure-mode catalogue rather than a list of management mistakes.
About a year ago, I left a job as a Director of Client Services and began interviewing at other firms. I had a great interview with a firm that I’ll call Company Y. After the interview, I wrote up a little essay describing my thoughts on the scalability, people, and operation of a client/customer service team. I hope you’ll find it useful and share your comments and feedback.
Scalability
A support department’s capacity to support work volume is based upon three factors: headcount, process, and supporting technology/tools.In its infancy, the support department gains volume by adding headcount. A department can reliably scale from one to two or three agents. Beyond three or four agents, however, inefficiencies begin to mount and dwarf the marginal gains from adding additional employees. For instance, two or three employees communicate easily about the state of the product and client base. Four or more employees can’t communicate nearly as well.
At this point, adding clearly defined standard operating procedures usually provide more productivity than adding additional employees. We can start this process by identifying and building upon the informal processes that the team and employees found useful. For instance, our team at Company X found notes on client accounts to be extremely helpful. As a result, we added a “you must add a note to a client’s account every time you touch it” to our list of standard processes.
At Company X, we found the most and least efficient parts of our workflow and built scripts and flows that helped employees cover their bases. In addition, we actively involved the team in defining and documenting the processes, giving them a strong sense of participation and ownership. This gave us a chance to reiterate that the processes were being developed to help the team thrive. We also had a chance to let our talented employees capitalize upon their strengths and take a break from the usual routine.
One of the most frustrating parts of developing processes is that the tools to support those best practices often come much later, if at all. Much of the work that the account managers did on a daily basis at Company X was significantly more manual than ideal. This is a source of risk, because if a company adds too many processes and “rubber-stamp” operations without giving employees effective tools, they begin to feel burnt-out and limited. They could feel like mere cogs in a machine because much of their work was simple and repetitive when it could have been automated.
Here’s an example at Company X. First, we established that retaining existing clients was substantially more cost-effective than trying to obtain new clients. So, we brainstormed on ways of retaining our client base. A member of our technical team suggested that we regularly audit each client account so that we could see how well they were using the software and make proactive suggestions.
We put this process into place. A successful audit could take 20-30 minutes: the account manager needed to log into each account and manually review every aspect of the account. Were the client’s users logging in on a regular basis? Create a custom report and find out. Are they using these reports effectively? Look at the page view reports.
Needless to say, this was a time-consuming process and we had limited bandwidth to get the job done. However, it also served an important function; we were able to suffer through the high cost of the process and ultimately determine that it was worth using. We also better understood how our customers used our software and learned of improvements we could make to our documentation and training processes.
Based on the work we did manually evaluating accounts, we were able to develop a utilization metrics system that helped us automatically quantify a client’s use and success with the software. Since the tool was automated, we could quantifiably track customer “satisfaction” over the course of time and even trigger early alerts about major changes in client engagement. We could even sort clients in our administrative interface by level of engagement, making it much easier to triage the clients who were in good shape, hurting but salvageable, or lost. As a team, we moved from need to process to sustaining technology.
Processes are never stagnant – as the landscape changes and additional staff join the team, we need to continually improve upon our modes of operation. However, we will come to a point where the baseline components of our process are stable enough for us to begin developing project requirements and ultimately tools.
There’s a balance of risks – on the one hand, you risk frustrating the team with time-consuming and repetitive processes that could be automated. On the other, you risk spending a good deal of time and money developing or purchasing the right solution to the wrong problem.
These days, I’m more inclined to use open-source or commercial products rather than trying to develop process-supporting tools. My litmus test is simple – do not reinvent the wheel. We would not create our own email server software, but we might integrate Exchange with our application.
There are two components to most process-related technology: general fundamentals (such as allowing a client to interact with a ticket-management system via email and a web interface) and specific adjustments or integrations with existing systems. I’ve found that many of the fundamentals are a) solved dozens of times by other people, and b) contain lots of “devilish details” that make developing your own version more difficult. Most of the time involved in getting two systems to communicate well is in developing an API for each system. Many off-the-shelf solutions include APIs for common tasks, so we need only attach our current software for the existing API.
At Company X, I found that we tried to develop our own tools when we should have purchased off-the-shelf solutions. We often had very limited tools that were tightly integrated with our system. The tools were fairly efficient (we didn’t have to enter data in more than one place very often) but they weren’t particularly helpful, either.
For Company Y, I’d likely recommend an off-the-shelf CRM tool such as RightNow. This gives us early wins (we can start tracking clients, tickets, and custom development more effectively), and we can add tighter integration with our existing back-end systems as we have time.
People
In our discussion together, I identified the best technical support employees as having the following characteristics:
- Early-career (relatively junior employees)
- Naturally gifted problem solvers who enjoy “digging into problems”
- “In touch” with the client base and their overall satisfaction levels, able to spot early problem trends
I also described ideal account managers as being:
- Naturally empathetic to their customers’ needs
- Effective, college-educated communicators
- Able to defuse upset customers
The wrong environment can make these employees feel “crazy,” overworked, and under-valued. Here’s a recipe for failure:
- Under-staff the department.
- Develop processes and procedures without employee input and fail to provide adequate supporting tools.
- Fail to provide adequate problem-resolution tools and resources.
- Fail to effectively respond to early-warning indicators described by the support team.
- Create an “us vs. them” relationship between the customer-care team and the rest of the company.
Conversely, a recipe for success:
- Staff the department appropriately given the workload and tools available. If possible, anticipate staffing needs 1-2 months in advance so that new employees can get up to speed; it’s difficult for new employees if the best trainers (their coworkers) are buried under a mountain of work. Thankfully, a team can tolerate understaffing as additional employees are hired and processes and tools are developed, but the shortage cannot be chronic.
- Use collaborative process mapping techniques to document and understand how employees use tools and go about their work. Follow-up by leading the team in converting the process map into a design map that addresses inefficiencies and waste in the current process, then follow up by actually implementing new processes and tools.
- Provide adequate tools for diagnosing and resolving problems. Ensure that other departments have a faster SLA to the support team than the support team has to the client.
- Evangelize for the customer-care team and investigate their early warnings seriously. Because they have the most day-to-day interaction with the customer base, they know better than anyone how customers feel about the product and its performance. Remember that many account managers have, perhaps to a fault, a very strong sense of empathy for customers and will be the best source of information about how clients are feeling.
- Help foster relationships between the customer-care team and incident engineers, developers, the sales team, and other members of the company. In addition to providing valuable insight, the customer-care team gains support and appreciation for their work.
Organization
Organizational issues are the most difficult to solve because they require a commitment across all functional groups.
A customer-care team is ultimately a conduit between a customer’s experience of a product and the rest of the organization. A customer-care agent cannot succeed unless they can provide the customer with a strong resolution to their problem in a timely fashion. However, that resolution is often out of the grasp of the individual representative.
It is therefore critical that the customer-care team can count on faster service level from escalating departments as they promise to their own customers. For instance, if customer service is expected to provide a satisfactory response within 24 hours but the development team consistently takes 48-72 hours to respond, three negative things will happen: a) the customer is let down, b) the representative takes the heat from the customer and feels equally let-down and overwhelmed, and c) bad blood often develops between the “martyr” customer-care team and the rest of the company.
A strong set of processes is important. For instance, as development requests often come through the customer-care team, we must create a set of processes and controls that ensure accurate communication about the customer’s needs and expectations.
A strong set of tools is also important. For instance, a customer-care representative must be able to see the current status of a trouble ticket so that they can proactively keep their customer informed and up to date. It’s obviously stressful for a customer-care representative to have to hound escalation engineers for regular updates. Any ticketing system developed or acquired should then include other departments as agents so that each issue is tracked from end to end.
03/07/2008
I hate priorities
[May 2026] I still think rigid priority-number columns mislead, but I no longer believe the fix is sitting down with stakeholders to sort the list by hand. Today I’d weight by cost of delay (Reinertsen’s WSJF, Fox and Gregory’s economic framing) and treat ordering as a live conversation grounded in numbers, not as a one-time stack-rank artefact. The instinct toward relative priority was right. The toolkit was thin.
[August 2026] Cost of delay is the variable Chapter 4 of Come Prepared to Die names, and this 2008 post was reaching for it without the word. What I argue here is only that relative order beats absolute priority. The chapter adds the economics that argument was missing: in high-variation work, keeping everyone busy makes the system slower, and queues are what you are managing whether you know it or not. The Customer is the Marshmallow makes the companion argument: defer the commitment and test before you build on top of it.
More specifically, I hate numbers or letter representations of priorities when it comes to product backlogs.
It’s a common strategy, even in Scrum. (Henrik Kniberg’s wonderful scrum book talks about a product backlog where higher priority items get higher priority numbers, preventing the “if this is critical and priority 0, what is ultra-critical? priority -1” issue.)
So why the hate? Simple – they do a lousy job of actually priortizing tasks. How many times have you encountered a product backlog where there were several items that were all of critical importance? How is this truly helpful?
Think of it in this way – what if half the items in your email inbox were of CRITICAL priority? At this point, what value does this tag add? At the end of the day, you’ll have to choose ONE thing to do next. What will it be?
I therefore argue that it’s exactly this hard decision that needs to be made earlier in the process, with the stakeholders who will wonder why this critical priority issue took precedence over that critical priority issue.
The real issue is that priority values attempt to apply a rigid metric of ABSOLUTE priority when the only thing that matters in the real world is RELATIVE priority – what do we do next? Even if you have the ability to complete work in parallel (e.g., more than one developer), you still need to figure out what those n people will do next.
Therefore, I propose that we kill the concept of priority values in the agile workplace.
Take your product backlog, remove the priority column, and sit down with the stakeholders. Don’t walk out of the meeting room until every item is sorted in order of relative priority.
The rest is easy: in your next sprint planning meeting, figure out how many story points you have available and work down from the top of the list. There are only two exceptions:
- When the developers believe that two pieces of work are similar enough to realize greater efficiencies if completed together. If this happens often, you need greater developer involvement in the priority setting meeting.
- When the remaining story points don’t support the next priority item. For instance, suppose there are 3 remaining story points but the next item in the product backlog requires 5. It’s OK to scan down a little and take the next item at or below three points.
What do you think? What has worked well for you?
09/03/2008