The Myth of 100% Utilization

I have gone into many a company whose managers brag to me about their 100% utilization of their people. They have all the techniques down pat and know just how to do it. I see opportunity. If they are willing to listen, I can improve their productivity 20-50% by not trying to get 100% utilization.


First, some terms need to be defined. Availability is the amount of time someone is available to do the job you hired them for. If they are a programmer, they are programming. If they are tech support, they are working with customers. If they are a tech writer, they are writing. Utilization is the amount of the available time that the person is actually doing the work. Many companies count utilization as the percent of hours a person bills to a project. That is merely how someone charges their time, not a measure of what they were doing in that time. To improve utilization, you have to improve both availability and utilization.


To know the actual time someone is working at their job requires observation. Many of these studies have been done for knowledge workers of all kinds, where the researcher follows someone around all day, tracking the time they spend on everything they do. They do this for maybe hundreds of people (multiple researchers of course) over an extended time. Companies pay for this research because they are looking for inefficiencies in their processes. Fortunately a lot of this research is published and the results are very consistent. This means you can use averages instead of paying for the research at your company.


The highest availability anyone has measured was 80%. Your most productive people are available at best 80% of the time to do their jobs. This is actually a good thing! They are not doing nothing in the other 20% of their time. The other time is spent on things such as company town halls, training, meetings with their boss, meetings with their team, and so on. When you think of all the things that pull people away from their work, 20% is a quite reasonable number for those kinds of activities. You want to allow your people time for career development.


You think that the contractors you hire must be at 100% availability. Of course they are 100% available for the hours they bill you. If they are billing you at 40 hours a week, they are almost certainly putting in about another 10 hours a week on their own time (or their staffing company’s time) for these other activities.


If you really had 100% availability, you would have unhappy, burned out employees who quickly leave for better opportunities.


So far, we know we cannot have 100% utilization of people’s time because they need about 20% of their time for activities other than the actual job you hired them to do (programming, writing, tech support, etc.). But what about 100% utilization of the 80%? We can use all our management tricks to get that number; we do it all the time!




Let’s consider all the things that prevent people from working 100% of their available time. Start with task switching. If you assign people to two or more projects at a time, you are losing on average 10% of their time every time they switch between projects due to having to switch their brains from one project to the other. Averaged out, this amounts to about 20% loss of productivity for each project you add (because people don’t usually just switch once between projects). This number is extremely well established based on about 90 years of research. It is real, it is going on, whether you want to admit it or not.


The first step then is to focus your people on one project.


But you say you have specialists and they don’t have that much work to do on one project. Then cross train them. The specialist model has been well studied and shown over and over to be inefficient. It looks appealing on paper, but actual measurement in real life shows that specialists lose most of their time to task switching. You are not getting much actual work out of your specialists anyway, so leave them in one place and teach them new skills.


The second step is help your people gain additional skills so there is more work that they can do.


A final common cause of lack of utilization is the huge number of interruptions due to telephone, e-mail, instant messaging, texting, and so on. For best utilization, you want to focus your people’s time on one project and you want to focus their attention. Get rid of the sources of interruption for some number of hours every day and add practices that help them focus on their work. Since you only have 80% availability, make that 80% as interrupt free as possible. For 6 hours a day, no phone, email, texting, or IM. Seat the whole team together so they do not need to use phone, email, texting, or IM to communicate with each other. Have them work in pairs to stay focused on the job.


The final step is to put people who work together in one place, remove interruptions for 6 hours a day (phone, text, email, IM), and have them work in pairs as much as possible.


There are companies who have taken these steps and watched their productivity soar. Companies who deliver products to market at 1/10th the cost of their competitors. Maybe you don’t get that much lift, but what is the value to you of a modest 10% gain? What if it was 20%? Is that worth changing they way you staff your projects?

Different Ways of Managing Work

Managing Work

Inside your company, many different kinds of work are being done. Rather than examining the work and then deciding how to structure it, most companies take a one size fits all approach. Many companies have decided that everything has to be run as a project, so they hire a lot of PMPs and set up systems to track the progress of a project. Other companies see success using Scrum in software development so they decide that everything has to be run using Scrum teams, and they hire a lot of Scrum Masters, and usually still try to account for the work as projects (though more enlightened companies fund Scrum Teams instead). Other companies fund product teams and all work is accounted to the product.

The fact is that all of these approaches work (as do many others). Where we make a mistake is treating all work the same way. The reason it is a mistake is that when we organize work in a manner not appropriate to the work itself we introduce unnecessary overhead and cost. You can keep doing everything as a project or everything as Scrum, just know that the work of your company is more expensive than it needs to be.

A Fluid company will look for the best way to do work based on the type of the work itself. In this post, I will examine three primary ways of managing work and discuss the kind of work that fits each management technique. These three ways of managing work are: project, product, and workstream.


Many companies structure all their work in the form of projects. What they do not realize is that for most companies, about 10-25% of the work of the company fits a project framework. For everything else, the project framework introduces a lot of unnecessary overhead.

First, what is a project? A project has a beginning, middle, and end. A project is completed and there is no work left over. A project is formed to achieve a specific goal or end state. A project has a schedule and budget. The schedule and budget of a project are measured throughout to show the progress of the project. Companies using an Agile methodology for software development (such as Scrum) add a regular measurement of the progress of the actual product being developed to the project metrics.

To run work as a project, you have to define the goal or purpose of the project, estimate the total cost, assign people to work on it, get everyone up to speed (project kickoff), estimate the tasks to be done to achieve the goal, run the project measuring schedule and budget throughout, and finally deliver the results of the work and close down the project.

Work that is “one and done” fits the project model very well. Things such as buying and installing third party software, upgrading all the workstations in the company to the newest version, converting a 40 year old system to new technology, and building a new company cafeteria are all examples of things that fit a project model.

Work that is repetitive and demand driven, or planned and ongoing, does not fit a project model very well. This is for two reasons. First, each repetition of the work requires defining, estimating, setting up and tearing down the project. That is a lot of overhead over time. Second, by dividing the work up into projects, you lose the long term vision of the work and almost always this results in suboptimal short term decisions leading to long term inefficiencies and cost.

Things that are repetitive and demand driven include customer support, setting up a work area for a new employee, releasing a product, or emergency response. These things should have standardized procedures and be managed as workstreams.

Things that are planned and ongoing include adding features or fixing non-critical bugs in an existing product, initiating a new product that you expect to have a lifetime longer than a few months, creating and regularly delivering training, doing competitor research, and any ongoing work that is not demand driven in nature. This kind of work should be organized around products or systems

Products and Systems

Products and systems are things that your company is responsible for maintaining over some lifetime. Systems are inside your company and generally exist to support the work of the employees. Products are things that you provide (or could provide) to customers, partners, or vendors outside your company. The important thing is not whether something is a product or system, but rather is this something that your company has to maintain over time.

Products and systems can be things such as computer hardware, computer software, business processes, training, and reports for a few examples. While products and systems do have a beginning, middle, and end, the lifetime is generally measured in decades, not months. There are products in the market today whose lifetimes are measured in centuries. When managing products and systems, the important measurement is the lifetime cost of ownership. Projects focus on the short term cost, often leading to decisions that make the product or system more expensive to maintain over time. Products and systems should not be maintained as a series of projects; over time that is far too expensive.

To manage work as a product or system, you form a product or system team. This is a small number of people whose job it is to create, maintain, and manage the product or system over time. This could be as small as 2 people (never one – you do not want to depend on one single person knowing the product or system), or for large products being actively maintained you may have 20 or 30 people on the team (or more). The product or system team is responsible for the long term vision of the product or system, the architecture or design of the product or system, the development of the product or system, the maintenance of the product or system, and the release plan for the product or system. The cost of the work is in the size of the team; team members are paid full time to work on the product or system team.

Work comes in continuously in the form of defect reports and feature requests from users, product managers, and company goals and directives. This work is organized into releases by the product or system team. The releases may be monthly or quarterly, or the team may decide on continuous releases, as we see with many mobile apps. The release schedule will be driven by market demand and the ability of the users to consume the changes.

The measurement of success is did we deliver the right product at the right time for the right cost. This will be measured every time a release is made and the team sees how the users react to any new features or fixes.

A lot of “run the company” work is associated with a product, but may not fit as part of the product team. If you are an insurance company and have a life insurance product, then creating actuarial tables is part of creating the product and so the actuary is part of the product team. On the other hand, handling claims is not part of creating or maintaining the life insurance product. It could be considered a product (or service) in its own right, and since it is repetitive and demand driven, it is a better fit for a workstream model.

Alternatively, legal work is often directly associated with a product. For some companies in highly regulated industries, a lawyer should be part of the product team, as well as possibly a compliance officer. For small, stable products these people may not be full time on the product team, but are rather a resource to be called upon as needed.


A workstream is a way of structuring work that is repetitive and on demand. The repetitive work should be described by standard processes and procedures. Work comes into a queue which may be “first come first served” or may have some other prioritization scheme applied. Work is managed by tracking the current work in progress to be sure it is not too large. There are typically service level agreements (SLA) which describe how quickly requests are processed.

The processes and procedures themselves are likely maintained by a system team who creates and maintains the processes and procedures, and maintains the software and systems to support those processes and procedures.

The cost is in the number of people staffed to handle the work in the workstream. People work full time handling the work in the workstream. For many people, the continuous pace of work can be very wearying over time, so rotating people between the workstream and the system team may be a way to balance the work across all the people involved.

Success is measured by the quality of the results, by staying under the work in progress limit, and by meeting or bettering the SLA.

The Common Mistake

When considering a company as a whole, structuring the work in different ways makes sense. The common mistake is to categorize all work within a department or division the same way. We see this often in IT where everything is a project. All the systems, metrics, and reporting are designed around projects. And yet, the emergency bug fix team should be a workstream. There should be product teams for each product. And there will be projects as well. But management wants everything reported the same way on one dashboard, and so we are back to everything is a project. (Why projects instead of products? Because PMI and Business Schools train people to manage projects not products, so management picks what they know as the default.)

By forcing everything to be measured the same way and accounted for the same way using the same systems, we are forcing inefficiency and greater cost into our work. These are not small inefficiencies. The unnecessary costs could be as low as 10%, but for most companies, these additional costs may be 30-50% of the IT budget. Just so we can have everything on one dashboard.

Think about it.

The Myth of Software Complexity

To claim that software is complex and that therefore we must create large teams to manage that complexity (as SAFe asserts (1)) is missing the point entirely. In this article, I’ll examine the fundamental flaw in that perspective and explain what we really need to do to manage software development in the modern world.


Software is complex. I have heard this a lot in my career. It is typically said by either people who do not actually understand software development or by practitioners who want to maintain the mystique of the discipline. Good software engineers know that the best software is a simple as possible.


The statement “software is complex” implies that complexity is a fundamental characteristic of software. This is quite obviously not true. If complexity is a fundamental characteristic of software, then we would not have all these clever iPhone apps being developed by individuals, even children, in time frames measured in days. The vast majority of software running things such as your clock, thermostat, and parts of your car is extremely simple. Even the software running robots is relatively simple. The math is complex, the software is not.


I’m sure the counter argument is, “OK, all software is not complex. But the software running our businesses and systems, that is complex.” If it is true, then that software is almost certainly unnecessarily complex. Think about most business applications. At its most fundamental, you have a user interface, some business rules, and a database. While the business rules may be complex, the software to implement them should not be. There may be a lot of features, but that does not mean the software behind the features is complex. Many is not the same as complex. Large is not the same as complex.


The discipline of software engineering (not coding, engineering) is filled with techniques and practices to remove complexity from software. This is because complexity in software is bad. Complex software is hard to understand, and therefore prone to error, difficult to change, and often full of defects. Good software is as simple as it can be, easy to understand, easy to maintain. Practices such as service oriented architecture, domain specific languages, object oriented design, test first development, refactoring, and minimum viable product all speak to the push away from complexity.


As my buddy Kyle points out, you have to ask the right questions. The question is not “How do we manage the development of complex software”, the question is “How do we remove complexity from our software”? Hint: you do not remove complexity by creating teams of 70-100 people running under the structure of a program (2). The Fluid Approach is based on removing complexity in software by using the eXtreme Programming (XP) practices along with good Voice of the User teams made up of Analysts and UI Designers who are skilled at Solution Anthropology.


I’m sure someone will bring up this argument “OK, software does not need to be complex, but the process of developing software is complex”. My answer to that is it does not need to be. If your software development process is complex, you have made it unnecessarily so. I have worked for extremely large companies creating big software using a very straight forward, simple development process. You really can create large percentage of the software needed today with teams of no more than 20 people with broad skill sets.


If your company has many different programmer roles, tester roles, analyst roles, etc., then you have created an unnecessarily complex process. If you have many layers of people involved in your software projects, then you have made the projects unnecessarily complex. The question is not “How do we manage a complex software development process”, the question is “How do we lean out our software development process”? The Fluid Approach has the answer: cross training, dedication and co-location of the development team with the Voice of the User team, management of the queue, and development of the tribe. These things have been proven to simplify the process of software development.


The question is not “How do we manage complexity”?


The question is “How do we remove unnecessary complexity”?


The Fluid Approach shows you how.


(1) “Our modern world runs on software. In order to keep pace, we practitioners must build increasingly complex and sophisticated software systems. Doing so requires larger teams…” , Why it Matters, accessed 11 May 2014


(2) “Trains work best with about 50-100 people dedicated to a primary value stream.”, accessed 11 May 2014.

What Metrics Should We Have?

I am sometimes asked “What metrics can we put in place to know that our people are doing a good job?”

They never like my answer. I just want three metrics to start:

1. Are our end users happy?
2. Are our customers (the people paying the bill) happy?
3. Does our team have joy?

They look at me like I am insane.

“That is not nearly enough.” They reply emphatically, “We measure 100s of things. You can’t manage it if your can’t measure it!”

“I agree.” I reply.

“Stop managing and start leading.”

Complexity, Simplified

With additional attention comes additional clarity.

Complexity is the core question, as discussed recently.  But what are the choices?   Turns out there are three basic answers.  One I already discussed, but the other two are better understood in a different way.

How complex is your system?

Is it a simple system?  Handle things with simple answers.  Individual experts, working largely independently, with bucket lists and goal targeting.

Is it a stable system?  Handle things with stability reinforcing answers.  Plan your projects. Manage to the plan.  Work by schedule.  Define processes and tasks.

But what if it’s a changing system?   Then handle things with answers that leverage change. You can’t manage the group, you need to rely on natural social systems (tribes).   You can’t guide with plans, you must use feedback.  You can’t schedule, you have to prioritize.   You can’t define processes and tasks, you have to build ceremonies.

Simple, Stable, or Changing?  That’s your question.  Use the right system for the right problem.

Earned Value Management (EVM) and Agile

Recently I was asked about EVM, specifically CPI and SPI, for Agile projects.  The question stopped me in my tracks because …. it makes no sense.  Why would I collect metrics that estimate my progress when I can prove actual progress by delivering working software every iteration (sprint)? I’ll outline my thoughts in this post to show why EVM makes no sense for Agile.

First, EVM was developed by the US Government in the 1960’s to solve a particular problem. They had many large, multi-year Waterfall projects with outside vendors and no visibility into progress.  Because there was no way to measure how much of the product was complete (Waterfall meant they got everything at the end), if they stayed with Waterfall, the only thing they could measure was the progress of the project.  EVM is based on a fundamental assumption that we can plan everything up front, and therefore if the project progresses as expected, then we will get the product we paid for.

Let me be very clear. EVM treats the project as the deliverable and measures progress of the project.  EVM in no way measures completion of the product, which is what we are actually delivering to the customer.

The fundamental assumption on which EVM is based is (in many cases) not a valid assumption. In many cases we cannot plan all the work up front. Also, we all know of projects that progressed exactly as planned, but the delivered product was a failure. The project succeeded, the product did not.

But let’s be fair. As long as the choice for software development is Waterfall, there really is no other way to measure progress.

Agile gives us a fundamentally different approach. We can still measure plan versus actual, but we measure a different plan against a different actual. We measure the user stories selected for the iteration (sprint) against the actual software we completed. Does the delivered software do what the user stories said it must do? We measure the actual benefit received by real users using the real software against the cost of developing the software. Do the actual benefits match what we expected? Is the cost reasonable compared to the benefit? Should we continue investing in this product?

Agile answers the question the customer really cares about:

Did I receive the right product at the right time for the right cost?

Our customers do not care about how well the project went. They don’t see projects. They see products. They see what the product does, they see what the product costs. They want the product when they need it, not 6 months from now.

I’ll close this by illustrating with a scenario.  I have 2 projects with 10 people each, with an average labor charge of $100 an hour. Each project is expected to cost $1,000,000 and complete in 6 months.

Project 1 is Waterfall. The project plans calls for the requirements phase to be completed after 2 months for a cost of $330,000.

Project 2 is Agile (of some flavor). They are doing 2 week iterations (sprints). Each iteration (sprint) should cost $80,000 if everyone is billing full time to the project. The first two iterations (sprints), the team expects to complete work that has an estimated benefit of $400,000 a year by saving 80 hours a week of labor time on a task performed by 40 people in the company (2 hours per person).

Project 1 completes the requirements phase in 7 weeks for a cost of $280,000. Everyone is happy. We are ahead of schedule and spend, so the project continues.

Project 2 completes the two sprints. The software matches what the user stories described. The team spent $90,000 (they had to call in a specialist to fix a weird problem). The software is given to 10 of the people who will be using it. The users save on average 1 hour per week using the new software. The cost was $90,000, the benefit is only $200,000, but still a good ratio and the users are happy. The new software is released to all 40 users. Based on lessons learned, the team reviews the cost and benefits of the next user stories to see if there is value in continuing.

If I look at EVM for Project 2, we completed what we planned, but we have overspent. The users are already using the software and receiving enough benefit that it was worth the cost. We have this information 1 month into a 6 month project. We can choose whether or not to continue spending money.

EVM for Project 1 looks better. We are on schedule and budget. But we have no idea if we are doing the right thing or if the benefit will be worth the cost. We will not know this for another 4 months. We have no basis for deciding if the cost is worth the benefit or if we should continue spending money.


We’ve run through a couple models of analysis on the nature of Agile/fluid systems.  Specifically, we’ve looked at that Method Grid, and then recently, we were trying to address which question needed asked.  I think we’ve made a breakthrough in our analysis.

Question:  Why is it that Hero and Director are more natural states than Messiah and Wedding Planner?

It seems as if there’s some natural synchronicity between Independent work and Individual responsibility, and also a natural synchronicity between planning and management.

Perhaps calling them out as separate axes is not the right thing to do…maybe there’s a deeper, underlying question, which is being answered in the same way on different axes that leads to this synchronicity.  And once we looked, we did indeed find that to be true.

The new claim:   There is one question at the heart of Agile.  The Agile manifesto gropes blindly for the question, but seems clearly to be looking for it.  The fluid principles are each a manifestation of the Agile question, in a different domain.  What is the question?

Q:  How do you handle complexity?

And at that same deep level, there are three basic paradigmatic responses.

Paradigm 1:  Simplicity.
A:  We don’t.  Our problem isn’t that complex.
Why do startups run in a profoundly different fashion than large companies?  Because their problems aren’t big enough yet.  They’re applying simple solutions (frequently from a brilliant insight) to simple problems.  In applying simple solutions to simple problems, they don’t address complexity at all.  And that’s wonderful.  For the domains that it works in.

Paradigm 2:  Control.  (aka Mechanical, Resisting, Rigid, Structured, Design, Managed)
A:  In the face of complexity, we attempt to control it.
Once problems become difficult enough, the Simplicity paradigm is insufficient to handle the problem.  We design a complexity management system.  More than a couple dozen people in an organization, and the group dynamics need management.  More than a couple dozen modules in your code, and you need to start doing design.  More than a couple dozen weeks in your project, and you need to lay out a plan.  More than a couple priorities, and you need a schedule.  More than a couple risks, and you need a process.   Everyone knows this system, as every large business we’ve seen has followed this mode.

Paradigm 3:  Fluid (aka Biological, Accepting, Organic, Nudge)
A:  In the face of complexity, we travel with it.
At some point after problems become difficult enough that the Simplicity paradigm is insufficient to handle the problem, so too is the Control paradigm unable to handle the complexity of the system.  Nature is complex enough we cannot direct it.  Rather, we need to work with nature, rather than against it.  In the southwest USA, build from brick and adobe to handle the heat.  In California, build flexible, wooden structures to handle the earthquakes.  In Galveston, build on stilts, to handle the Surges.  Nature will not be commanded…but in flowing with nature, we can get some of what we want.

In the face of hundreds of people in an organization, we need to abolish the formal organizational structure that fights nature, and instead allow natural social systems to emerge.  Tribes sit at the 150-person level.  Hunting parties are near 10.  Pairs work together naturally as well.  Natural social systems don’t sit well with authority.

In the face of thousands of components in a system, and fluid requirements, we need to abandon the notion that a design will capture what we need.  Rather, we need test-driven design and an aggressively maintainable system in order to build good enough architectures to survive the natural change cycle.

In the face of hundreds of competing priorities, we need to abolish the formal method of scheduling, and focus instead.  Biological systems like human beings and human organizations have limited bandwidth.  Scheduling 6 things at once doesn’t get 6 things done faster.  Rather, it usually means that at least 5 things get done slower than they would have,  and usually aggressive prioritization/queuing/focus gets 9 things done faster than 6 things in a scheduled fashion.

In the face of innumerable risks, process cannot save us.  We need a better answer.  A natural, flowing with human patterns instead of against them answer.  The answer that gets us there is ceremony.

In the face of more than a couple encounters with changing reality, planning systems crumble under the weight of replanning.  Instead, we need fluid, biological responses to changing conditions.  We need the ur-mechanism for responding to reality.  Feedback systems are the only answer.

There is only one question:

How complex is your problem?

If you have easy problems, a simple paradigm can solve them.
For mildly difficult problems, the control paradigm is standard because it handles them.
But for the actually hard problems, fluid systems are the only answer.

It’s interesting also to consider how many problems fall into the moderately difficult category…and how much overlap there is between the problem-solving capacity of control vs. fluid systems?  How many problems can control solve (well) that fluid can’t?

The answer is no. Wrong question.

As our understanding of Fluid approaches improves, we’ve come to see more and more that it isn’t just the answers to traditional questions that are wrong, but rather it’s almost always the wrong question being asked as well.  And when you ask the wrong question, the right answer is nearly impossible.  It’s as if we’re discussing wealth with a mathophobe and they ask us the question, “If I want to get rich, what should I do with my life savings?  Should I go to Vegas, should I play the lottery, or should I invest in high volatility derivatives?”

The answer is no.  Wrong question.  You get rich by investing other people’s money.  And  you don’t do it in the lottery, vegas, or bankruptcy-immune derivatives.  Now…I’m not exactly rich, so I don’t have enough to say here…but I can tell you with confidence that with the question being so wrong…the answer can’t be right.

And so it goes with decisions in the business world.  Almost every question you’re asked will be the wrong question.  Which of course makes the answers insane.

What questions do we need to fix?

How can we get the right answer to our questions?  Should we rely on experts, or should we rely on careful planning?

No.  Wrong question.  The right question is:

How do we find out where we’re wrong faster?

Feedback systems.


How do we assign responsibility to  individuals to get work done?  Responsibility to the individual, or responsibility to the manager?

No.  Wrong question.  The right question is:

How do we assign responsibilty to groups?   

You build a tribe.


How do we determine what is important?  Should we work in an interrupt driven (scheduled) system, or should we build bucket lists?

No.  Wrong question.  The right question is:

How do we determine what to do first/next?

Work from a queue.


What existing business feature should we trust to bring us good results?  Should we trust the individuals and relationships?  Or should we trust our metrics?

No.  Wrong question.  The right question is:

What system should we build that we can trust?



The old questions are the wrong questions.  The old answers are nuts.

The new questions, with answers:


How do we handle error?  Feedback

What gets responsibility?  Tribe.

What do we work on?  Queues.

What can we trust?  Ceremony.


Finally, some good questions.


Agile Pain Points from Agile 2013

On the final day of Agile 2013, I led a crowd sourced mini-workshop/discussion on Agile pain points. In this post I’ll summarize, with a goal to get into more details over the coming months.

I posted large easel pad sheets on the wall and wrote names of company departments on each sheet. Then I invited the audience to take sticky pads and write their particular pain points and post them under the department causing the pain. After a few minutes, I handed out strips of 8 dots to each participant and invited them to vote on the things that were their biggest pin points. They could use all 8 dots on one, one dot on each of 8, or any variation in between.

A helper reviewed the sheets looking for high numbers of dots. Then we discussed those highest pain points until we ran out of time.

I am still transcribing my recording of that session for notes. But below is the list of departments, pain points, and number of votes for each. 14 people participated in the writing of pain points and voting. Note that things with zero votes are still pain points; they just are not as painful as items with more votes.

What are your pain points? Do you have others?


Executive / Board of Directors

  • 1 – Lack of positive support from executives and on down
  • 0 – Want everything now
  • 9 – Can’t  or won’t prioritize
  • 0 – Silos of demand – no overall view
  • 0 – Developers think the only reason for our Agile transformation is to save money by firing people
  • 3 – Portfolio management
  • 2 – Why don’t you ever stick to the plan?
  • 0 – Not all management is on board with transformation


  • 0 – Project funding (instead of product funding)
  • 6 – Use of estimates – want the budget up front
  • 0 – Must capitalize software projects

Legal / Compliance

  • 0 – It takes too much time to review documents and contracts
  • 3 – Compliance built around waterfall

Human Resources

  • 8 – Job titles versus Agile roles = confusion for teams
  • 2 – No team based compensation model
  • 5 – Performance appraisals / Yearly appraisals
  • 0 – Cannot hire excellent co-op who is a rockstar on the team because of his GPA
  • 1 – Revolving door staff
  • 0 – Compensation model
  • 0 – Lack of dedicated resources


  • 0 – Security patching that breaks automated tests and slows build times (example you can’t use AWS you have to use the corporate cloud solution but we know it sucks)
  • 0 – Project team staffing (staffing a project instead of staffing a team
  • 0 – Mainframe developers, long development cycles
  • 4 -Still think in terms of projects not products
  • 4 – Won’t adopt stable teams
  • 3 – Lack of resource dedication and co-location
  • 1 – Team members changed in and out based on application expertise
  • 7 – Insist on assigning multiple projects to teams at the same time

Product Lines

  • 0 – Lack of priorities
  • 0 – Lack of backlog
  • 0 – Lack of release plans
  • 2 – Product Owners are unfamiliar with how to support Agile


  • 0 – Cube farms
  • 0 – Some teams in special rooms, some not
  • 0 – The right kind of space
  • 7 – Lack of co-location
  • 1 – We need more whiteboards
  • 3 – Can not modify workspaces
  • 0 – Setting up Agile space / colocation
  • 0 – You can’t tear down the cube walls due to fire code
  • 0 – No flexibility to move around

Customer Support

  • 1 – Tier 3 customer support in engineering team takes time away from our work

Center of Excellence

  • 4 – Testing in COE’s instead of the team doing the testing

Product Development

  • 2 – How people are assigned to teams
  • 0 – Defining team structure, competency vs feature
  • 9 – Lack of flexibility for scope on projects
  • 4 – Product specialist not willing to build minimal features
  • 0 – Lack of user stories


  • 0 – Always have most important projects (they think so)
  • 7 – Squeaky wheel want it now


  • 2 – Operations is not structured to support Agile
  • 0 – Prioritizing epics
  • 0 – They don’t work in our Agile teams
  • 0 – Can not provide product owner with enough focus
  • 4 – Operations can’t match speed of Agile team
  • 0 – Can’t take software upgrades more than once per quarter in the factory
  • 0 – Defining roles – product owner, scrum master, coach
  • 0 – Complex development – red tape


  • 0 – Politics – want to say we are doing Agile, no actual support
  • 2 – Funding model
  • 0 – Just velocity metrics

Listening isn’t Learning

The theory of using Ritalin in schools goes like this:

  1. Grades measure learning.
  2. Sitting still and listening is an important part of learning
  3. ADHD prevents kids from sitting still and listening.
  4. Ritalin allows ADHD kids to sit still and listen.


  • Ritalin will help ADHD kids get good grades.

The problem is that the conclusion is false.  Recently, scientists figured out that Ritalin is not actually effective at improving grades.

Why is this? Ritalin supports the standard schooling model very well. If students can’t sit still and listen, what should we do? Ritalin is a very simple answer: Give them a drug that allows them to sit still and listen.

What can explain then, the failure of Ritalin to improve the grades of the students? There are several explanations available, but few of them look especially good for the standard learning model, and none of them look good for the use of Ritalin.

If we have a syllogism with 4 premises and a conclusion, and the conclusion turns out to be false, then so too must one of the premises be false.

For the purposes of this discussion, I think that we don’t need to worry much about premise one’s truth.  It is also pretty well established that ADHD prevents kids from sitting still and listening, and that Ritalin allows ADHD kids to sit still and listen.  That leaves only one premise to address*, which is almost certainly wrong:

  1.  Sitting still and listening is an important part of learning

But, someone might object, this is a foundation of our entire school system, and most of our training in the corporate world.  Indeed it is.  And that’s a pretty big problem.

Let us suggest instead a different model of learning.

There are three domains which we interact with in our learning process:

  • The Territory — The real world
  • The Map — Our mental representation of the real world — usually not in words
  • The Words — What we use to communicate about the world.

Or, because I’m suggesting that the listening/reading thing isn’t good enough, let’s get a picture:

The original tree is the territory.**  What someone sees looking at the world.  That is translated via some process into some sort of mental map of a tree for the original observer.  Then, the original observer communicates something about what he’s understood to a listener “Tree”.  Then, if all the stars are aligned, the listener builds his or her own mental map of what was communicated.


The problem is that this system is designed to communicate mostly old stuff.  It kinda sucks for communicating novelty.  And the learning process is about the communication of information and methods that are new to the listener.  Somewhere between the business of translating from the map into words and the business of translating from words back into a map, there is usually a failure.

While this in itself would be sufficient to explain the failure of Ritalin, we can take it further.

An awful lot of the time, this is not a picture of what’s happened.  It’s more like this:

There’s usually an intermediary between the discoverer and the listener.  Oftentimes the intermediary doesn’t even do the real translation from map to words.  Rather, they encode the words.   And that’s where we get real problems.

Human beings have the capability to encode words.  They also have the ability to build maps.  But basically people can’t build good maps from words.  And you can’t do anything with your words except repeat them until you have a map.  Unfortunately, 20 years in teaching, and nearly that many more in school says that the business of going from words to map is effectively non-existent.

Ticking upwards to close:   What can we do about it?  As educators, we can focus heavily on what a student can do rather than what words they can say.  As Agilists, we can keep our meetings small and participatory.  Anyone not talking is out if it’s more than 10 minutes.  And as learners, we can focus on our ability to really understand by doing, rather than keeping a set of words in our heads.


* It could also be true that Ritalin prevents learning another fashion, independent of sitting still and listening.

** Yes, the whole diagram constitutes something sitting somewhere between words and map.  It’s clearly not words, but it’s an attempt to communicate my map to you.