Thoughts on Adopting Agile

Posted Sunday, May 17, 2015 in Software Engineering

Introduction

Imagine managing a small team of developers tasked with developing an email server and client system for a customer. In this scenario, a loose definition of what the customer expects is presented to the team. A listing of activities is then devised that would result in the delivery of the software such as interface design and network protocol development activities. At this point in the development process, the manager may consider how these activities will be performed such that a rough timeline and order of execution is determined. Now the manager considers contingencies for several uncertainties. How will changes be managed? Certainly, the loose requirements will change over the course of the development process. Also, what processes and tools will be used by the team? How does the customer present changes and feedback to the project? How will the team respond to customer changes? These questions and more underpin the uncertainty that comes with software development.

How uncertainty is managed has much to do with the software development plan established by the project manager. Luckily there are established best business practices that have many years of research backing them such as the Agile software development methodology. However, implementation of a particular process model or methodology comes with some caveats. The following discusses how Agile may be implemented and some of the trade-offs compared to established organizational methods.

Agile

Agile concerns lightweight development methods that seek to improve the software development process. Defined by a loosely constrained manifesto, Agile is closer to an attitude than a specific set of practices or methodology (Fernandez D. & Fernandez J., 2009). Agile software development, akin to the term agility, focuses on responsiveness to change and interactions between developers and stakeholders over a strict set of processes and management plans. An appropriate mixture of structure and disorder is expected while using Agile methodologies (Fernandez D. & Fernandez J., 2009). In more concrete terms, Agile defines many different approaches to common software development efforts such as testing, change management, debugging, design, and more. One example of an Agile approach is pair-programming, based on the Agile manifesto of interactions over processes, involves two developers working closely together on the same code simultaneously.

Another core concept of Agile is the use of Scrum which defines activity execution, planning, and defining iteration units as sprints. The iterative nature of Agile, similar to the spiral process model, comes from scrum sprints that define units of work with time designated for review, shipping, and planning for another possible iteration of a sprint. Again, imagine the developer's task of developing an email server and client system. After determining a backlog of activities to complete a group of activities from the backlog is identified for a sprint in which a shippable version of the software may be produced, even if in concept form. Tasks that are chosen are selected by team members to work on in phases such as working, testing, debugging, and completed. Daily review, co-location, and code reviews are also typical in a sprint to afford ample coordination between developers and tasks.

Implementation

An organization may come to the point where Agile methodologies look like a promising fit and decide to adopt Agile as the primary development process. The organization's decision to adopt Agile may come in one of two ways: From the bottom up and from the top down. The bottom-up refers to development and management teams or individuals adopting Agile methodologies with or without top-level management support. Without management support, Agile adoption can cause an increase in the IT landscape complexity due to varying understandings and practices in software development (Van Waardenburg & Van Vliet, 2013). Agile adoption may also occur in which horizontal functional areas adopt Agile while others retain existing business processes. For example, a development team may adopt Agile methodology but contract and procurement teams may retain existing practices. Negotiation of a contract is a customer facing operation that may restrict the development's team ability to perform Agile actions such as rapid customer feedback and involvement due to contract stipulations. Therefore, top level management, as well as organization wide involvement, is critical in ensuring negative effects are not created as Agile methods are adopted.

An important concept in adopting Agile is that adoption must be based on the organization's existing practices, culture, and development context (Cao, Mohan, Xu, & Ramesh, 2009). One term for describing the pit-fall of Agile adoption is cargo cult mentality. This term comes from a world war II interaction between military air cargo support and an indigenous population. Observing the methods of the air support crews the indigenous people made the connection that performing certain actions such as building landing strips and making arm gestures would result in an aircraft landing with cargo. An organization may make the same mistake by forcing Agile methods to be conducted and assume that positive results will be produced. As Cao et al. (2009) wrote, project managers must provide due consideration of the impact of adopting Agile and its fit within their organization. For example, imagine a single developer conducting daily scrum meetings with themselves and spending hours writing plans and conducting reviews with themselves. Such a practice would seem quite silly, but can certainly happen when certain practices are blindly adopted and enforced. As Fernandez D. and Fernandez J. (2009) wrote, Agile is mostly an attitude rather than a fixed set of practices. Enforcing a fixed set of practices without consideration of the organization is a dangerous practice.

Strengths, Weaknesses, Opportunities, and Threats

One of the core strengths of adopting Agile is having contingencies for when software development projects run into issues of change, uncertainty, and complexity. For some organizations, there may be no established plan for how to manage change and risk. The flexibility of Agile practices and attitude over method style lets an organization at least consider an approach to software development uncertainty that would otherwise be handled through improvising processes.

However, for organizations with established software development practices, adoption of Agile may be less successful due to increases in IT landscape complexity and additional considerations required to integration or replacement of existing practices. For a large organization, replacement of established procedures that may have millions of dollars worth of established practices and systems. Adopting Agile would require a considerable return on investment. Critics such as Janes & Succi (2012) were skeptical of the performance of Agile based management due to the possibility of underlying assumptions that were the real cause of success. Due to flexible nature of Agile, which can be seen as an informal construct unsuitable for performance research, there may be practices not defined in Agile areas of knowledge that are the actual cause of success.

Whether or not an organization should adopt Agile methodologies should be from a close consideration of the organizations existing practices. The organization may wish to develop a strengths, weaknesses, opportunities, and threats (SWOT) analysis to determine if Agile adoption is a good fit for the organization. What should be avoided is taking an inflexible approach to adopting Agile. For example, an organization may be presented with a presentation from an Agile consultant describing the benefits of Agile that are possible. Purchase of a contract with an Agile consultant may cause an organization's leadership to succumb to confirmation bias that may come with sunk costs (i.e. we've come this far there's no going back) and lead to inflexibility in adoption. Therein lies the threat of the cargo cult mentality.

Conclusion

There is a positive benefit opportunity to the adoption of Agile methodologies, but not without due consideration of the threats. Contingencies for the uncertainty that comes with software development is critical to reducing the risk of project failure. An organization without these contingencies may find great benefit in adopting Agile methodologies as at least a starting point for more established practices. Top level management must recognize the importance in their role for the adoption of Agile (Cao et al., 2009).