Rashina Hoda is an Agile researcher, pursuing a PhD at Victoria University of Wellington, New Zealand and holds a bachelors degree from Louisiana State University, USA.
Rashina has been studying Agile teams in New Zealand and India for over 3 years as a part of her industry-based doctoral research. Her research has resulted in publications and presentations around the world, she presented at Agile2008, Agile2009, and XP2009 conferences.
Recently, she had a paper accepted to the International Conference on Software Engineering (ICSE2010) to be held in Cape Town, South Africa in May 2010. Rashina’s paper on Self-organizing Agile teams is one of the 52 accepted from 380 submissions worldwide.
The thrust of her ICSE paper is what actually happens on self-organizing teams – what perspectives, roles and attitudes need to be in place for a team to become effectively self organizing.
Recently Rashina answered some questions about her research:
Please can you tell us the background to your research – what prompted you to go down this path?
I started exploring Agile project management back in 2006 as a part of my PhD research here at Victoria. The idea was to investigate the use of Agile methods in the industry and gain a deeper understanding of some of the critical problems Agile practitioners face.
In your research you talk about the importance of “self-organizing” teams – what makes a team self-organizing, why are they better than directed teams and what needs to be in place to enable self-organization to emerge?
Yes, that's right. Agile teams are meant to be "self-organizing" but unfortunately there isn't enough information on how Agile teams go about self-organizing themselves in practice.
Self-organizing teams are given the freedom to chose their own team goals every iteration [4]. They also have the freedom to self-assign tasks which leads to higher sense of responsibility and ownership of tasks and the overall project as compared to manager-led or directed teams that have tasks assigned to them by their managers. Self-organizing teams are cross-functional and there is more flexibility across functional areas of expertise which ensures maximum utilization of resources and better learning through collaboration. Directed teams, on the other hand, focus on specialization which can be detrimental to collaboration and knowledge-sharing. Finally, self-organizing teams also value self-reflection and continuous learning while effectively achieving iteration goals which allows them to not only out-perform themselves but also find better and innovative ways of working. Directed teams, on the other hand, are focused on meeting deadlines set by their managers and have little incentive to improve their own ways of working.
Self-organizing teams do not function in isolation and are effected by environmental factors [1,4]. The two most important environmental factors that the research revealed include senior management support and customer involvement. Senior management at the teams' organization must be able to provide freedom to the teams so that they can self-organize themselves. Customers must support the teams by being actively involved in the development process through providing regular requirements, clarifications, and feedback as required. These two are the most important environmental factors that need to be in place to enable self-organization to emerge.
The documented Agile practices already define a variety of roles that are needed in Agile projects – does your research negate the existing roles (scrum master, agile coach, developer, tester, customer, SME, business analyst, UI designer etc)?
No. The roles we've discovered are self-organizational roles - informal, spontaneous, and at times temporary - that emerge in response to issues faced by the team. They are different from the established organizational roles - formal, predefined, and mostly permanent - that are based around established functions of software development such as coding, testing, designing etc and are found on non-Agile teams too. The self-organizational roles, as discovered through our research, emerge specifically to facilitate self-organization and can be played by different organizational roles. For example, I found that an Agile coach usually played the Mentor role on relatively new Agile teams whereas the Mentor role was also played by senior developers in more mature teams. So, there is no conflict between the two, rather there is a mapping between the established organizational roles and the informal self-organizational roles.
In your paper you define six roles that teams need – please can you describe them and explain the way in which these roles differ from those already defined?
Our research has identified 6 informal roles that team members adopt in order to help their team self-organize [1]. These are:
1. Mentor that provides initial guidance, understanding, confidence of Agile methods, and encourages continued adherence to Agile practice. This role is closest to the classic Agile coach role, but as I mentioned, was also played by senior developers in more mature Agile teams.
2. Co-ordinator that co-ordinates communication and change requests from customers. The co-ordinator role was present in situations where the customer was physically distanced from the development team and co-ordinating change requests and communication with the customers was difficult. The Co-ordinator was played by a developer or business analyst.
3. Translator that translates the customers’ business language into technical terminology used by the team and vice-versa, in order to improve communication. This role emerged to address the language gap that exists between business customers and the technical development team. The Translator could be played by anyone of the team with good communication skills who can effectively understand and translate between business and technical languages.
4. Champion that gains the support of senior management to establish pilot teams and to propagate more self-organizing teams across the organization. The Champion was played by a Agile coach or (senior) developer.
5. Promoter that secures customer collaboration and involvement to support efficient functioning of Agile teams and was played by an Agile coach.
6. Terminator that removes team members that hamper team productivity due to their inability to fit into the Agile way of working. We found the Terminator to be played by the Agile coach.
Should organizations be recruiting for and establishing these roles when building Agile teams?
These self-organizational roles emerge spontaneously in response to the specific problems faced by the team instead of being formally established by the organization upfront. It will be useful to be aware of these self-organizational roles and ensure that the team is comprised of individuals that are capable of taking on one or more roles as and when required.
What areas of future investigation does your research open up?
Besides presenting a deeper understanding of self-organizing teams, our research has uncovered several challenges of practising Agile methods. These include problems around negotiating contracts [2], lack of customer involvement [3], and issues with senior management support. Our research has opened up areas of future research into self-organizing Agile teams in different countries and cultures than those we studied.
Thank you for taking the time to talk to InfoQ.
Do you agree with these definitions, and have you seen these roles in your Agile teams?
References:
[1] Organizing Self-Organizing Teams. Rashina Hoda, James Noble, and Stuart Marshall. To appear in the proceedings of the International Conference on Software Engineering (ICSE), South Africa, 2010.
[2] Negotiating Contracts for Agile Projects: A Practical Perspective. Rashina Hoda, James Noble, and Stuart Marshall. XP2009, Italy, 2009
[3] Agile Undercover: When Customers Don't Collaborate. Rashina Hoda, James Noble, and Stuart Marshall. To appear in the proceedings of XP2010, Norway, 2010.
[4] Balancing Acts: Walking the Agile Tightrope. Rashina Hoda, James Noble, and Stuart Marshall. To appear in the proceedings of CHASE workshop at ICSE2010, South Africa, 2010.