7. Autonomous work group in Agile IT projects…

“Autonomous work groups are teams of employees who typically perform highly related or interdependent jobs, who are identified and identifiable as a social unit in an organization, and who are given significant authority and responsibility for many aspects of their work, such as planning, scheduling, assigning tasks to members, and making decisions with economic consequences (usually up to a specific limited value)”, (Guzzo & Dickson, 1996). There are large number of literatures regarding autonomous work groups, referring it using different names like empowered teams, autonomous work groups, semi-autonomous work groups, self-managing teams, self-determining teams, self-designing teams, crews, cross functional teams, quality circles, project teams, task forces, emergency response teams, and committees, (Guzzo & Dickson, 1996).

A traditional software development team consists of software developers, testers, business system analysts, etc., (Hoda, 2011). Each of these members have well defined, roles within team, and they work within their boundaries, (Hoda, 2011). On the other hand, agile software development team comprise of “individuals [that] manage their own workload, shift work among themselves based on need and best fit, and participate in team decision making" (Highsmith, 2004). Autonomous work groups are the heart of Agile software development, (Chow & Cao, 2008) (Cockburn & Highsmith, 2001) (Highsmith & Fowler, 2001). 

(Anon., n.d.)

Software development is a cohesive process between domain experts, technical experts and experts in process knowledge, (Chau & Maurer, 2004). Hence this process requires a lot of knowledge sharing between different roles and in different stages of the process. In traditional software development, this knowledge sharing between each stage mainly based on documents, such as functional specifications, test specifications, source code, etc. (Chau & Maurer, 2004). Furthermore, long communication lines in this approach sometimes lead to over document information. Contrarily, daily stand-up meeting in agile software development helps to share knowledge easily, reduce redundancy and build trust and team orientation (Karhatsu, et al., 2010).

Among the downside of self-managed software teams, conflicting goals/priorities, completive behaviour, not taking the ownership of the decisions, unwilling to commit to decisions, etc are identified (Moe, et al., 2009) (Drury, et al., 2012).

References

Anon., n.d. Agile Development Model. [Online]
Available at: https://www.intelegain.com/agile/
[Accessed 30 04 2019].

Chau, T. & Maurer, F., 2004. Knowledge Sharing in Agile Software Teams.. In Logic versus Approximation, pp. 173-183.

Chow, T. & Cao, D., 2008. A survey study of critical success factors in Agile software projects.. Journal of Systems and Software, 81(6), pp. 961-971.

Cockburn, A. & Highsmith, J., 2001. Agile software development: The people factor.. Computer, 34(11), pp. 131-133.

Drury, M., Conboy, K. & Power, K., 2012. Obstacles to decision making in agile software development teams.. ournal of Systems and Software, 85(6), p. 1239–1254.

Guzzo, R. & Dickson, M., 1996. Teams in organizations: Recent research on performance and effectiveness. Annual review of psychology, 47(1), pp. 307-338.

Highsmith, J., 2004. Agile Project Management: Creating Innovative Products.. s.l.:Addison-Wesley Professional.

Highsmith, J. & Fowler, M., 2001. The Agile Manifesto.. Software Development Magazine, 9(8), pp. 29-30.

Hoda, R., 2011. Self-Organizing Agile Teams: A Grounded Theory. Wellington: Victoria University of Wellington.

Karhatsu, H. et al., 2010. Building blocks for self-organizing software development teams: A framework model and empirical pilot study.. San Juan, 2010 2nd International Conference on Software Technology and Engineering, Proceedings..

Moe, N. B., Dingsøyr, T. & Dyb°, T., 2009. Overcoming barriers to self-management in software teams.. IEEE software, 26(6), pp. 20-26.