Distracted? Unproductive? Thank “Resource Management.”

The recipients of the email below have been sorta kinda doing Scrum without making structural or cultural transformation it implies.  After writing this I realized it could just as easily apply to most of the large companies we’ve been dealing with.  The disturbing part is that every day more project managers are taught exactly the kind of thinking that causes the problems below.

Begin forwarded message:

After meeting dozens of people at [omitted] in [omitted], I have an impression everyone is too distracted to do their best work. Unnecessary task switching is wasting millions of dollars of human attention. Teams lack the focus and months of continuous membership stability to reach the self-managing state needed for high performance and high quality.

This fibrillation isn’t caused by having “too much to do” or “not enough resources” or “changing business climate.” It’s caused by bad habits and misconceptions.

I’ve listed some typical issues below:

1) Please reconsider the early-20th Century microefficiency approach to “resource management.” As people up and down the org chart are individually yanked from thing to thing, they don’t mentor others, digging the specialization ruts deeper. The good news is that knowledge and skills spread quickly on long-lived collaborative teams (especially in team rooms). Use every opportunity to offer work to a *team* through the Sprint Planning Meeting.

By the way, doing Sprint Planning by task hour capacity is typically a clue our team hasn’t worked together enough yet.

2) Please reconsider the habit of linking teams to architectural components. If creating a product feature requires more than one team, you may have fallen into the trap of *single-component teams* or (worse) *single-discipline teams*. This reduces the business’s ability to re-prioritize product capabilities, increases the coordination bottlenecks through managers and Product Owners, and introduces integration risks. Try replacing *efficiency thinking* with a concept of team autonomy and ownership.

Creating feature teams also comes at a cost: developers (testers, analysts, POs, etc.) must learn new skills. The good news is most developers got into this because they enjoy learning new skills. Experience reports with transition strategies such as technical “component guardian” are described in _Scaling Lean & Agile Development_ (Larman/Vodde 2008).

Once you’ve mastered feature teams, a next step could be *general purpose feature teams* with reduced affinity to feature areas.

3) Technical debt is causing production problems and high cost of change. I heard y’all blame this on the old C++ parts, but I predict the new Java parts will look the same in a couple years unless habits are changed. It’s easy to write unmaintainable code. Are any of you writing legacy code *today*? Creating high quality code, with robust built-in tests to also allow future refactoring, probably requires the focused attention of a cross-functional team. Do you have a product-wide definition of “done” that includes proper testing and refactoring? Are you accumulating technical debt by demonstrating work that falls short?

See also:

4) HR practices of most companies are rooted in the industrial era model of human motivation. Job titles tied to prestige typically reinforce specialization. W.L. Gore & Associates does fine without them. Performance appraisals (including 360s) tied to raises and incentives may do more harm than good, especially to collaboration. While B.F. Skinner was able to use rewards and punishments to elicit simple conditioned responses from animals, behaviorist approaches seem to be harmful when applied to complex work.

If you want to be one of the people who can say “I told you so” when more companies realize this a few years from now, read _Punished By Rewards_ or _Abolishing Performance Appraisals: Why They BackFire and What To Do Instead_.

Some people aren’t a good fit for Scrum, or for particular teams. Consider giving teams more say in who joins them. For examples of successful autonomous workplaces, look into the GE Plant in Durham NC that makes jet engines without a management-imposed org structure. Or read about Semco in _Maverick: The Success Story Behind the World’s Most Unusual Workplace_.

5) We ask ScrumMasters in large organizations to maintain a big visible list of *organizational impediments* and act together to gradually reduce them. Where’s yours?

I hope that helps. Several people have kept in touch with me — I really appreciate that.


Download the pdf version: Distracted_Unproductive_Thank_Resource_Management_blog

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Tagged with: , , ,
Posted in Agile
5 comments on “Distracted? Unproductive? Thank “Resource Management.”
  1. Great email Michael. I’m happy I won’t be on the receiving end of one of these.

    Project managers continue to be taught the “old ways” and view people as resources rather than people. Building teams is the name of the game, and that means working at the people level. Rather than learning how to make everything line up on charts, project managers need to be taught more people skills and how to help people make better decisions.

  2. Craig says:


    How do you think this email will be received? Is the client in crisis and willing to take on any advice? Or will your message be rejected as an outsider’s criticism?

  3. Michael James says:

    I’m working with three large companies that all have basically the same problem. Sometimes size itself is a pathology. I’m guessing that two of them will make incremental changes, then stop when it gets too uncomfortable, and one of them will continue to transform.


Leave a Reply

Your email address will not be published. Required fields are marked *