Self-organizing teams have been recognized and studied in various forms-as autonomous groups in socio-technical systems, enablers of organizational theories, agents of knowledge management, and as examples of complex-adaptive systems. Over the last decade, self-organizing teams have taken center stage in software engineering when they were incorporated as a hallmark of Agile methods. Despite the long and rich history of self-organizing teams and their recent popularity with Agile methods, there has been little research on the topic within software wngineering. Particularly, there is a dearth of research on how Agile teams organize themselves in practice. Through a Grounded Theory research involving 58 Agile practitioners from 23 software organizations in New Zealand and India over a period of four years, we identified informal, implicit, transient, and spontaneous roles that make Agile teams self-organizing. These roles-Mentor, Coordinator, Translator, Champion, Promoter, and Terminator-are focused toward providing initial guidance and encouraging continued adherence to Agile methods, effectively managing customer expectations and coordinating customer collaboration, securing and sustaining senior management support, and identifying and removing team members threatening the self-organizing ability of the team. Understanding these roles will help software development teams and their managers better comprehend and execute their roles and responsibilities as a self-organizing team.

Self-Organizing Roles on Agile Software Development Teams

ContextCustomer collaboration is a vital feature of Agile software development. ObjectiveThis article addresses the importance of adequate customer involvement on Agile projects, and the impact of different levels of customer involvement on real-life Agile projects. MethodWe conducted a Grounded Theory study involving 30 Agile practitioners from 16 software development organizations in New Zealand and India, over a period of 3 years. ResultsWe discovered that Lack of Customer Involvement was one of the biggest challenges faced by Agile teams. Customers were not as involved on these Agile projects as Agile methods demand. We describe the causes of inadequate customer collaboration, its adverse consequences on self-organizing Agile teams, and Agile Undercover - a set of strategies used by the teams to practice Agile despite insufficient or ineffective customer involvement. ConclusionCustomer involvement is important on Agile projects. Inadequate customer involvement causes adverse problems for Agile teams. The Agile Undercover strategies we've identified can assist Agile teams facing similar lack of customer involvement.

The impact of inadequate customer collaboration on self-organizing Agile teams

Agile processes focus on facilitating early and fast production of working code, and are based on software development process models that support iterative, incremental development of software. Although agile methods have existed for a number of years now, answers to questions concerning the suitability of agile processes to particular software development environments are still often based on anecdotal accounts of experiences. An appreciation of the (often unstated) assumptions underlying agile processes can lead to a better understanding of the applicability of agile processes to particular situations. Agile processes are less likely to be applicable in situations in which core assumptions do not hold. This paper examines the principles and advocated practices of agile processes to identify underlying assumptions. The paper also identifies limitations that may arise from these assumptions and outlines how the limitations can be addresses by incorporating other software development techniques and practices into agile development environments.

Assumptions Underlying Agile Software Development Processes

Awareness of design smells - indicators of common design problems - helps developers or software engineers understand mistakes made while designing, what design principles were overlooked or misapplied, and what principles need to be applied properly to address those smells through refactoring. Developers and software engineers may "know" principles and patterns, but are not aware of the "smells" that exist in their design because of wrong or mis-application of principles or patterns. These smells tend to contribute heavily to technical debt - further time owed to fix projects thought to be complete - and need to be addressed via proper refactoring. Refactoring for Software Design Smells presents 25 structural design smells, their role in identifying design issues, and potential refactoring solutions. Organized across common areas of software design, each smell is presented with diagrams and examples illustrating the poor design practices and the problems that result, creating a catalog of nuggets of readily usable information that developers or engineers can apply in their projects. The authors distill their research and experience as consultants and trainers, providing insights that have been used to improve refactoring and reduce the time and costs of managing software projects. Along the way they recount anecdotes from actual projects on which the relevant smell helped address a design issue. Contains a comprehensive catalog of 25 structural design smells (organized around four fundamental design principles) that contribute to technical debt in software projects Presents a unique naming scheme for smells that helps understand the cause of a smell as well as points toward its potential refactoring Includes illustrative examples that showcase the poor design practices underlying a smell and the problems that result Covers pragmatic techniques for refactoring design smells to manage technical debt and to create and maintain high-quality software in practice Presents insightful anecdotes and case studies drawn from the trenches of real-world projects

Refactoring for Software Design Smells: Managing Technical Debt

Software developers and project managers are struggling to assess the appropriateness of agile processes to their development environments. This paper identifies limitations that apply to many of the published agile processes in terms of the types of projects in which their application may be problematic.

Limitations of Agile Software Processes

One of the core XP (Xtreme Programming) practices is that of the "on-site customer". In the words of Kent Beck (2000) in his book "eXtreme Programming Explained" the intent is that a "real customer must sit with the team, available to answer questions, resolve disputes, and set small-scale priorities" … "someone who will really use the system when it is in production". This panel brings together practitioners and researchers to discuss and offer wisdom on the challenges and opportunities inherent in the practice.

The role of the customer in software development: the XP customer - fad or fashion?

Extreme programming is the latest rage, everyone is talking extreme, but who is doing it? XP is in the words of one proponent, is a “lightweight, efficient, low-risk, predictable, scientific, and fun way to develop software”. XP bundles much conventional software engineering wisdom into a practice with a high degree of appeal as a cool technology. Questions for inquiring minds include: Will XP deliver? Will XP scale? How will products based on software developed by XP practices age? What are the elements of XP that can be effectively adopted by organizations outside the XP envelop, e.g. large teams, real-time systems, etc. Is XP the next “silver bullet”?

Hacker or hero? - extreme programming today (panel session)

Agile software development practices including XP and Scrum have risen to prominence within the software engineering community over the past ten years. Are agile software development practices converging? Are some practices becoming more integrated and/or more widely adopted than others? In the early 90s there was a convergence of object-oriented design methodologies - is a similar pattern being repeated within the agile software development community? Several years ago conferences featured debates on the number of practices inherent to XP - or for that matter what constituted XP. Is the Agile community on the verge of converging to standardization or do individual practices retain their individually and evangelists/disciples? A somewhat related question is: Can an agile practice be applied out of the box or is some assembly required? What does it take to get agility going in an organization? Does it work as advertised? What practices work and play well with others? Hear the experiences of panelists in their attempts to actually make agile work in the real world. From Crystal, DSDM, FDD, LEAN, Scrum, to XP (and others) - participants will to share their perspectives and experiences. Be warned - this fishbowl will be stocked with piranhas.

A Fishbowl with Piranhas: Coalescence, Convergence, or Divergence? The Future of Agile Software Development Practices: Some Assembly Required!

One of the core XP (eXtreme Programming) practices is that of the “on-site customer” In the words of Kent Beck (2000) in his book “eXtreme Programming Explained” the intent is that a “real customer must sit with the team, available to answer questions, resolve disputes, and set small-scale priorities”  “someone who will really use the system when it is in production” This panel brings together practitioners and researchers to discuss and offer wisdom on the challenges and opportunities inherent in the practice

Linda Rising

Papers

The role of the customer in software development: the XP customer - fad or fashion?

Hacker or hero? - extreme programming today (panel session)

A Fishbowl with Piranhas: Coalescence, Convergence, or Divergence? The Future of Agile Software Development Practices: Some Assembly Required!

The XP Customer Role

Non-software examples of PoSA patterns