Ken Power

Obstacles to decision making in Agile software development teams

Highlights? We conducted focus group with 43 Agile developers and managers. ? We conducted 6 case studies with 33 interviews across 5 organizations. ? Results indicate 6 decision obstacles Agile software development teams face. ? Decision obstacles were mapped to show effect on decision process. ? Obstacles affect strategic decision focus, backlog and team engagement. The obstacles facing decision making in Agile development are critical yet poorly understood. This research examines decisions made across four stages of the iteration cycle: Iteration Planning, Iteration Execution, Iteration Review and Iteration Retrospective. A mixed method approach was employed, whereby a focus group was initially conducted with 43 Agile developers and managers to determine decisions made at different points of the iteration cycle. Subsequently, six illustrative mini cases were purposefully conducted as examples of the six obstacles identified in these focus groups. This included interviews with 18 individuals in Agile projects from five different organizations: a global consulting organization, a multinational communications company, two multinational software development companies, and a large museum organization. This research contributes to Agile software development literature by analyzing decisions made during the iteration cycle and identifying six key obstacles to these decisions. Results indicate the six decision obstacles are unwillingness to commit to decisions; conflicting priorities; unstable resource availability; and lack of: implementation; ownership; empowerment. These six decision obstacles are mapped to descriptive decision making principles to demonstrate where the obstacles affect the decision process. The effects of these obstacles include a lack of longer-term, strategic focus for decisions, an ever-growing backlog of delayed work from previous iterations, and a lack of team engagement.

Decision Making in Agile Development: A Focus Group Study of Decisions and Obstacles

The process and effectiveness of decision making in agile development is critical yet poorly understood. This research examines decisions made across the four stages of the sprint cycle: Sprint Planning, Sprint Execution, Sprint Review and Sprint Retrospective. A focus group was conducted with 43 agile developers and managers to determine what decisions were made at different points of the sprint cycle. The results indicate that Sprint Planning includes decisions about planning the work for the subsequent sprint, Sprint Execution includes tactical implementation and development decisions, Sprint Review includes decisions about whether the product satisfies the customer and whether future sprints should continue, and Sprint Retrospective includes decisions for improving the sprint process in future sprints. Additionally, six key obstacles to decision making were identified. This research contributes to the literature on agile software development by advancing our understanding of how these teams function by analyzing the decisions made during different points of the sprint cycle and the obstacles to these decisions.

Stakeholder Identification in Agile Software Product Development Organizations: A Model for Understanding Who and What Really Counts

Stakeholder Theory is an area of strategic management that defines a stakeholder as someone who affects or is affected by the actions of the organization. The principles and concepts of stakeholder theory can be applied to software development organizations to give managers a better understanding of the diverse community of stakeholders that influence product development efforts. A deeper understanding of the broad community of stakeholders can help an organization that is transitioning to agile methods by highlighting the stakeholders that are affected. This paper describes the application of stakeholder theory to product development organizations in the context of a global product development company undergoing a multi-year transition to agile development. A model is presented for mapping stakeholders into stakeholder groups, and for quantifying the influence of stakeholders. This paper further uses a stakeholder approach to demonstrate how traditional organization roles map to roles in an agile product development organization.

Understanding the impact of technical debt on the capacity and velocity of teams and organizations: viewing team and organization capacity as a portfolio of real options

Understanding the impact of technical debt is critical to understanding a teams velocity. For organizations with multiple teams and products, the impact of technical debt combines non-linearly to impact the organizations velocity. We can think of the capacity of a team as a portfolio. Not all of that capacity can be invested in new features or defect fixing, without incurring negative consequences. A portion of the teams capacity needs to be invested in the ongoing management and reduction of technical debt. This paper describes a simple technique for visualizing, quantifying and tracking a teams technical debt as a portion of their overall capacity investment. The knowledge and insights gained through this technique help with better capacity planning, improved forecasting, and helps to justify the business case for investing in managing and reducing technical debt.

Impediments to flow: rethinking the lean concept of 'waste' in modern software development

Eliminating waste is a core principle of lean thinking. Despite the emergence of literature that applies lean in the software domain, an underlying analysis of this literature reveals the fundamental interpretation of waste has remained largely unchanged since its origins in manufacturing. Lean defines waste as any activity that does not directly add value as perceived by the customer. Software development is a creative design activity, not a production activity, and agile teams and organizations are more akin to complex adaptive self-organizing systems than repetitive production lines. Waste has different meaning in such systems. This paper reframes the lean concept of waste as impediments to flow in complex human systems. Drawing from ongoing research, this paper presents an updated categorization to describe the impediments faced by teams and organizations. The categories are extra features, delays, handovers, failure demand, work in progress, context switching, unnecessary motion, extra processes, and unmet human potential. These categories provide a foundation for helping teams and organizations to see, measure and reduce impediments to flow in their systems.

Definition of ready: an experience report from teams at Cisco

Definition of Ready is a set of simple rules adopted by an agile team to help them remember all the things they need to do before a development team starts work on a backlog item. Not having a definition of ready can seriously impede the flow of work through your system. This paper describes where definition of ready fits in a teams process, and how it can be used as a synchronization point for teams and product owners. This paper presents an example of definition of ready used by agile teams in Cisco. These teams have developed three levels of ready that apply for user stories, sprints and releases. The paper describes how definition of ready provides a focus for backlog grooming, and some consequences of not meeting definition of ready. The paper finishes with perspectives from different roles in the organization and how they are affected by definition of ready.

A metric-based approach to managing architecture-related impediments in product development flow: an industry case study from Cisco

Contemporary lean thinking, especially in knowledge work areas like software engineering, begins with understanding flow. Architecture plays a vital role in enabling the flow of value in software engineering teams and organizations. To date there has been little research in understanding impediments to flow in software engineering organizations. A focus on enabling flow through removing impediments is a useful perspective in creating a more agile, lean thinking software engineering organization. Particularly so when supported by appropriate metrics. This paper presents a case study of how architecture-related impediments impact the flow of work in software engineering teams and organizations. The key contributions of this paper are centered on the concept of flow and impediments in modern software engineering, and its relationship with architecture. We develop an understanding of how a focus on flow and removing impediments, supported by appropriate metrics, is helpful in identifying architecture-related challenges. Drawing on research of one companys practices the paper presents an example of a scenario where flow analysis using specific metrics reveals architecture-related impediments and shows how addressing these impediments improves effectiveness and productivity in ways that would not otherwise have been revealed.

Using Silent Grouping to Size User Stories

User stories are used to describe the functionality delivered in a product or system. Planning Poker is a common technique for sizing user stories, however it has challenges. It can be time consuming and teams can get bogged down in unnecessary discussion. This paper describes a technique called Silent Grouping that can be used to compliment Planning Poker, explaining how to apply it so that large sets of user stories can be sized in minutes. Experiences of seven Scrum teams from Cisco’s Unified Communications Business Unit are used as examples. The paper shows how to apply the technique with co-located teams, and includes an example of how it was used with distributed teams. Silent Grouping has several advantages. It is fast, which in turn leads to significant time and cost savings. It also has more subtle benefits. This paper discusses the techniques, challenges, cost savings and benefits of Silent Grouping.

A Model for Understanding When Scaling Agile Is Appropriate in Large Organizations

The term “agile at scale” is used frequently in relation to agile approaches in large organizations, but the meaning of “scale” is not always clear. Without a proper understanding of meaning and context, inappropriate methods are applied. It is important to understand when “scaling agile” is the solution to the problem at hand, and when its not. There is a difference between agile approaches used by a team in a large organization, agile approaches used on a large development effort, and organization agility. The distinction is important. This paper explores that distinction using Human Systems Dynamics as a lens through which to understand and articulate which of the three contexts an organization is dealing with. By analyzing a system through the HSD lens it becomes possible to predict and influence the impact on the flow of work through the system, and in particular, it is possible to understand what types of impediments might impact the flow of work. This helps organizations to understand appropriate approaches to agility that better suit their context.

The Agile Office: Experience Report from Cisco's Unified Communications Business Unit

Similar to the way a Project Management Office (PMO) defines standards for project management within the organization, an Agile Office governs the organizations ongoing agile adoption and continuous improvement through agile practices and is responsible for the successful ongoing adoption of agile practices throughout the organization. Agile transition takes time, it is not a discrete event. When transitioning to agility it is important to put in place structures that will ensure that agile survives long after the initial transition period. This paper describes the experiences of Ciscos Unified Communications Business Unit in establishing an Agile Office. It describes the history behind establishing the Agile Office, the governance model, where it fits in the organization structure, engagement model, primary activities, challenges faced, and the stakeholders with whom it operates.