Overcoming Barriers to Self-Management in Software Teams
Posted by Greg Wilson on 2009/09/26
As I’ve written earlier, an increasing amount of research in software engineering is focused on empirical studies of what actually works (or doesn’t) in the real world. A new paper from Moe, Dingsøyr, and Dybå reports a multi-year study of teams in several companies implementing Scrum. Key problems they identified include:
- Over-specialization: if each module “belongs” to one developer, it’s hard for the group as a whole to design and plan, because no one knows enough to get a big picture view.
- Unclear completion criteria: if team members don’t know how to tell when something’s done, it’s difficult for them to plan and prioritize.
- Meetings that are not engaging: self-explanatory.
- Lack of team autonomy: in particular, if managers constantly come along and say, “Never mind the plan, fixing this bug is now your top priority,” people stop caring about making plans in the first place.
- Impression management: if managers give their managers the impression that a team is better than it actually is, then the team will be given goals that are impossible to meet.
- Resource contention: developers who are working on two or more projects in parallel always have to decide who to disappoint. (Note: students are usually working on five courses at once…)
The paper suggests solutions for all of these problems, but they basically come down to “use common sense”. It’ll be interesting at the end of term to see which of the traps on this list we’ve fallen into, and whether we can improve next time ’round.