Organizing Self-organizing Teams

Posted by Shane Hastie on Apr 17, 2010

Sections

Process & Practices

Topics

Teamwork ,

Agile ,

Adopting Agile ,

Coaching ,

Team Collaboration

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.

 

 

Shane Hastie is an agile coach, trainer and consultant working for Software Education in Australia & New Zealand

1. Back to top

   Self Organizing Teams/Agile ... Democracy & Dictatorship

   by aditya yadav

   Self Organizing Teams commonly found as Agile Teams are like Democracies and Most conventional organizations are like monarchies/dictatorships. We find government models at the levels of countries from which we can draw analogies.
   
   Agile Enablement of an organization is like running a hybrid model government which is not proven till date anywhere in the world atleast at the level of countries. e.g. Dictatorship at the top while the Bottom of The Pyramid is Self-organizing/agile or democratic. This is why Agilification of conventional companies is a very difficult task. As it involves succeeding in a hybrid government model for sustained periods. Which is one aspect of the problem.
   
   When I look at democracies I believe the essential intrinsic criteria for a democracy to succeed is that citizens are capable of making unbiased decisions, respectful and participative. While Dictatorship is essential and succeeds only in other cases. If we draw an analogy which seems pretty reasonable one according to me brings me to the second aspect of the problem. Which is somewhat related to your work.
   
   When you ask a developer "how are things?" and he replies with "Fine" or "The Build is broken" compared to an Agile Team where the answer normally is "The build is broken because of breaking changes to XYZ module. But its ok as it happens at times. The concerned developer needs to fix the services in module 'x' and he has started working on it. Lets say about 2 hours of work before the build goes green" Can we see the difference? The first two answers are from Manager driven companies and the last one from one of my agile teams.
   
   Essential criterias necessary for self evolving teams/Agile teams/Democracies are missing from what you have written. As per my opinion. I'm sure there is a lot more to your research than what is summarised above. And I would be interested in getting my hands on it, if I may.
   
   Any thoughts?
   
   Aditya Yadav
   Aditya Yadav & Associates
   Amazon Cloud Computing With C#/.Net
   Amazon Cloud Computing With Java
   Understanding Programming Languages
   Deploying HTML5
   Essays on SOA AND EAI - A Pocket Guide

   Reply

2. Back to top

   Optimal Case for Self organization teams

   by alireza haghighatkhah

   I think we should consider organization culture, scale and some other important factors when we are talking about self organization teams, perhaps in the small size team it’s very good to involve team members in all aspect of project from A to Z. not by described roles as above.
   
   This may cause more commitment, motivation and knowledge sharing between your team members, but this model will not work in large scale team.
   
   In large scale system maybe we need to definition of some roles as described above, this may leads to more discipline but it will eliminate team member creativity also.
   
   Actually it’s tradeoff between some qualities, you should balance different factor for your needs.
   
   In the optimal cases we should have “Problem specific self organization teams”, this means that team members can identifying existing problems, discuss with each other and brainstorming to finding proper solution, create different small group comprised from different skills to collaborate in order to solving problem and they may disband team.
   
   This behavior may be happen in daily experience of good agile team.

   Reply

3. Back to top

   Re: Self Organizing Teams/Agile ... Democracy & Dictatorship

   by Rashina Hoda

   Hi Anand,
   
   Thanks for your insight.
   
   Defining the type of team model is perhaps inseparable from defining the management style in an organization. As we discovered in our research, if the team model is self-organizing the management style must be supportive of self-organization. As you rightly said, the introduction of Agile teams into 'traditional' organizations is an uphill task. Since an Agile team is not manager-led, we found that somebody from within the team usually takes on the task of convincing the senior management to understand and support the self-organizing team. We call this role: the Champion. The Champion ensures that the team has senior management support in terms of freedom provided to make decisions about various aspects of their work. Similarly, the other roles emerge in response to other problems that may threaten the self-organizing nature of Agile teams.
   
   As you guessed, the six self-organizational roles summarized here are one aspect of our research on self-organizing Agile teams. These roles show us 'how' Agile teams go about self-organizing themselves in absence of traditional managers that were previously in-charge of most of these problems (such as gaining senior management support or training.)
   
   Other aspects of our research include the 'Balancing Acts' [reference 4 in the article] performed by these teams between (a) freedom and responsibility (b) cross-functionality and specialization and (c) continuous learning and iteration pressure, to uphold the three conditions of self-organization: autonomy, cross-fertilization, and self-transcendence (as defined by Nonanka and Takeuchi, 1986)
   
   You can find more information on our research on my Research webpage and in our conference papers (referred to in the article)

   Reply

4. Back to top

   Re: Optimal Case for Self organization teams

   by Rashina Hoda

   Hi Alireza,
   
   Thanks for your comment. I fully agree with you that self-organizing teams should decide the solutions to the specific problems they face in their own contexts. The six self-organizational roles that we discovered in our research (by 'discovered' I mean we didn't invent them in theory, rather we found them in practising Agile teams) emerged spontaneously in response to specific problems these teams were facing. The most common problems were: lack of Agile knowledge and training in new teams, challenges of co-ordinating and effectively communicating with customers (sometimes distant) on a regular basis, gaining senior management and customer support, and dealing with team members that were harming the team's self-organizing abilities. The roles of Mentor, Co-ordinator, Translator, Champion, Promoter, and Terminator emerged in response to these problems respectively. So, these roles are very much "problem specific" as you suggested. And as such all roles may not be present on every Agile team as a given Agile team may not be facing all of these problems simultaneously.
   
   You also mention concerns about scalability of these roles. The Agile teams we studied were composed of between 4 to 15 people. In case of large projects, usually the project was split between groups of smaller teams. As such we didn't encounter single 'large' teams (say 50+ members), which may be partly due to the concerns around scalability of Agile methods in general. One can imagine that even if the roles take on the shape of groups (instead of individuals) for larger teams, the fundamental idea of spontaneous roles (groups or individuals) emerging in response specific problems remains the same. The spontaneous emergence of roles in response to "specific problems" is what makes these roles self-organizational.
   
   As you said, "it’s tradeoff between some qualities, you should balance different factor for your needs". Please see my reply to the previous post on the "balancing acts" of self-organizing Agile teams.

   Reply

5. Back to top

   Re: Self Organizing Teams/Agile ... Democracy & Dictatorship

   by Javier Gonel

   When you ask a developer "how are things?". In a Manager driven team they cannot answer. They just don't know or they just say what are they doing.
   
   In an Agile team the answer should be: check the status of the tasks we spoke and leave us work/ask scrum the scrum master (if we talk about scrum). Yep, that person that everyday checks on the status of each task and "facilitates" the assignments.
   
   In a team of 10 developers, you cannot pretend that the 10 knows exactly what's happening to the other nine. They should know the basics due to the fact that every morning they decide on the assignments. But it's the scrum master (again if we talk about scrum) the one that knows about the problems, forths and backs of the team.
   
   Note: talking about "criterias" for self evolving, is like talking about "the 10 rules of genetic evolution". It doesn't make much sense.

   Reply

• Older >