A Teamwork Model for Understanding an Agile Team
Reviewed by Jorge Aranda / 2011-08-02
Keywords: Agile Development, Organizational Behavior
Moe2010 Nils Brede Moe, Torgeir Dingsøyr, and Tore Dybå: "A teamwork model for understanding an agile team: A case study of a Scrum project". Information and Software Technology, 52(5), 2010, 10.1016/j.infsof.2009.11.004.
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 et al 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.)