It Will Never Work in Theory

A teamwork model for understanding an agile team

Posted Aug 2, 2011 by Jorge Aranda

| Organizational Studies | Qualitative Studies |

Nils Brede Moe, Torgeir Dingsøyr, and Tore Dybâ. "A teamwork model for understanding an agile team: A case study of a Scrum project." IST 52, 2010.

Context: Software development depends significantly on team performance, as does any process that involves human interaction.
Objective: Most current development methods argue that teams should self-manage. Our objective is thus to provide a better understanding of the nature of self-managing agile teams, and the teamwork challenges that arise when introducing such teams.
Method: We conducted extensive fieldwork for 9 months in a software development company that introduced Scrum. We focused on the human sensemaking, on how mechanisms of teamwork were understood by the people involved.
Results: We describe a project through Dickinson and McIntyre's teamwork model, focusing on the inter-relations between essential teamwork components. Problems with team orientation, team leadership and coordination in addition to highly specialized skills and corresponding division of work were important barriers for achieving team effectiveness.
Conclusion: Transitioning from individual work to self-managing teams requires a reorientation not only by developers but also by management. This transition takes time and resources, but should not be neglected. In addition to Dickinson and McIntyre's teamwork components, we found trust and shared mental models to be of fundamental importance.

There are at least two things in this paper that are relevant for practice. The first is the fairly detailed account of what went right and wrong when this team tried to implement Scrum. The second is the emphasis on self-management and its challenges: for a lot of people today, Agile means short iterations, daily stand-up meetings and unit testing. The self-management aspect (the idea that teams should be autonomous, self-regulating, to actually have power) is often ignored---which is too bad, because it really is at the core of the Agile manifesto and its implementations. Moe & Co show why this is a problem, and how switching to Scrum is more about organizational reorientation than about programming practices.

(Note: The link to this paper does not have the PDF available yet, but the authors tell me it will be made available there soon. If you don't have access to it and you are interested in reading it sooner rather than later, kindly requesting a copy from the authors directly through email often works.)

Comments powered by Disqus