UCOSP

Undergraduate Capstone Open Source Projects

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.

One Response to “Overcoming Barriers to Self-Management in Software Teams”

  1. Not to sound like I’m on the Agile bandwagon, but the solutions to all those problems can kinda be summed up by ‘do Agile right’. It sounds like the teams were doing the same stuff wrapped in a new coloured costume (scrum).
    – no shared code ownership
    – no definition of ‘done’
    – meetings for meetings sake
    – weak product ownership (lack of stick-with-the-commitment)
    – lack of self-organization

    The name for this btw is ‘scrumbut’; as in ‘we are scrum, but…’

    -adam

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: