Distracted? Unproductive? Thank “Resource Management.”

October 22, 2009 Michael James

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.
–mj

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:
http://blogs.danube.com/suggested-topics-for-definition-of-done-discussion

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.

–mj

Download the pdf version: Distracted_Unproductive_Thank_Resource_Management_blog

Previous Article
SCRUMとは何か

...

Next Article
Mixing Up a Community Cocktail…

Chris Brogan once described a community manager as ‘part party host, part fine restaurant host.’ Part of wh...