An Analysis of Agile Methodologies via Comparison to Traditional Methods
Arguably the most divisive debate in the software development field is the idea of workflow management. Ideas, principles, and guidelines amalgamate into singular, all-encompassing methodologies that may be adopted by organizations or teams therein. Though the number of individual methodologies is incredibly extensive, the majority fall into one of two major categories: the traditional so-called waterfall model or the more contemporary Agile methodologies.
The idea of the waterfall model evolved out of the science and engineering disciplines, characterized by extensive planning of both the project itself and the timeline that would be followed to that end. Deliverables are viewed in terms of so-called milestone deadlines and are typically not provided prior to these points in the development.
Comparison of Methodologies in Key Areas
The waterfall model applies most effectively to large, enterprise-scale projects that have a large number of contributors. A simple successive and predictable workflow between each of the major development phrases allows for team members to all be well-versed in the current state of the project. However, the teams associated with any given project will likely be segmented by department ' an IT team, a marketing team, etc. Lack of cross-functional teams often results in decreased interdepartmental communication. If the marketing team, for example, believes a change in requirements for the information system is near, such information may not be well transmitted to the analysts and developers that are constructing said information system.
'[A] system designer will still fall short of knowing what kind of change to expect without intense oversight by a business user' (Dermody, Ragsdale, & Aragon, 2012, p. 45). This oversight is frequently overbearing and will ultimately reduce productivity and time to market.
Agile methodologies instead recommend smaller teams, with each member representing a given business unit. Such a team structure is conducive to cross-functional collaboration on projects. However, a smaller team is less likely to be able to deliver a large-scale solution in a comparable amount of time.
Perhaps the most significant difference between the methodologies with respect to team structure is the idea of daily self-reflection. 'The team meets daily'to assess progress toward the goals' (Dermody, et al., 2012, p. 47). The team analyzes not only the advancement of the project, but also the specific intra-team processes that have resulted in effective communication and/or workflow. Identifying these specific processes engages the group in self-adaptation; only members themselves are given the power and responsibility to establish the practices that will best aid in the progression toward the end product.
Roles and Skills
The waterfall model allows for very specialized and defined roles for each team member. Although this may be less difficult from a management perspective, it stifles cross-functional learning and development. This results in 'a hierarchy involving a command-and-control style of management with clear separation of roles' (Nerur & Balijepally, 2007, p.82). In the system development environment of the past, this proved to be an effective solution; in the modern information system era, it is often viewed as suffocating and management-centric. This is not to say that the waterfall model is completely defunct. Rather, it has been well established that Agile can prove more effective, particularly when a project is new and is of relatively small size.
The obvious alternative to the waterfall view of roles and skills is an approach that emphasizes cross-training, ultimately resulting in a productive team with a wide range of skills. 'The diversity and redundancy of skills (such as interchangeable roles) built into integrated self-organizing agile teams amplify the variety within the system' (Nerur & Balijepally, 2007, p.83). That is, the Agile views of role assignment and skill expectations result in improved diversity both within the team and the products it creates.
Project Structure and Plan
One of the most noteworthy downfalls cited by critics of the waterfall model is the fact that 'The user's first glimpse of a soft-ware product frequently happens after 80% or more of the development activity is complete' (Dermody, et al., 2012, p. 46). Such a situation presents the potential conflicts that would occur if the user has since changed their requirements. Because 80% of the development has already taken place by the time the user is shown the software, there are very few, if any, changes that can be made. In this respect, the only way that the waterfall model can work effectively is in a project that has static and well-defined requirements ' this, of course, tends to be a rare occurrence in the modern business paradigm.
Alternatively, Agile methodologies emphasize the idea of frequent and functional deliverables; the customer/user will be shown working prototypes of desired features as frequently as possible. Keeping in mind the iterative nature of Agile, a given deliverable should be produced, in a potentially shippable form, to the customer at the end of each cycle. This process allows for the customer to monitor progress and request changes as they deem necessary. When Agile techniques are implemented in this fashion, developers begin to 'profoundly appreciate how'business users can drive'activities for mutual success' (Dermody, et al., 2012, p. 50).
Though the term artifacts was popularized with the advent of Agile methodologies, it can be taken in the context of the waterfall model as meaning information, often in physical form, provided from various sources to guide the development process. A frequent critique of the waterfall model is that the documentation often produced during the process of acquiring these artifacts is far more detailed and time-consuming than what is truly required. This documentation is then often put through a mandatory review process in order to proceed with funding and production. It is for this reason that the more modern Agile approaches are practiced in such a way that more tangible and functional software is more highly valued than excessive documentation about what a product should do.
Using the Scrum framework as an example, the most significant artifacts include backlogs for each sprint and the product as a whole. These backlogs serve as lists of features that provide sources of work for the development team. That is, each time the team allots a given amount of time ' generally two week sprints ' to perform work on the project, it is determined on what features this work will be done. It is important that these backlogs are not overly ambitious, as it is crucial that the scrum team produce each of those features on-time and in a fully-functional form.
Significant Benefits and Respective Drawbacks
Difficulty of Implementation
With the many demonstrated benefits of adopting the Agile methodologies in one or more areas of a business, it is easy to overlook some of the key factors that can impede the conversion from a waterfall approach. 'Organizations must rethink their goals and reconfigure their human, managerial, and technology components in order to successfully adopt agile methodologies' (Nerur, Mahapatra, & Mangalaraj, 2005, p.75). Companies and employees that are more resistant to change will likely struggle in the transition to Agile; they may not understand why the current model is no longer deemed efficient or effective. In some industries, this alteration of various business processes may also prove difficult due to industry or governmental regulations.
Conversely, the more traditional waterfall model is much simpler to understand ' largely because it is what has been practiced in many corporations for decades. Although this worked sufficiently for previous generations of technology, the integration and development of innovative and emerging technology does not lend itself well to this sort of development. It has become considerably more effective to use the smaller, self-organizing teams that Agile methodologies provide.
Stakeholder and Customer Involvement
By encouraging the customer to be meaningfully involved on a regular basis, Agile 'improves customer engagement and satisfaction' (Rigby, Sutherland, & Takeuchi, 2016, para. 13).
''that 'projects with a higher degree of participation from customers tend to perform better' (as cited in Ramasubbu, Bharadwaj, & Tay, 2015, p. 793)
Organizations That Have Adopted Agile
Here's why companies have become Agile
One of the numerous stories of success following the implementation of Agile is that of John Deere. George Tome, an IT project manager with the company, began in 2004 to develop a more specific brand of Agile ' one that any employee of John Deere could understand and apply within their respective department (Rigby, et al., 2016, para. 21). Because the language that defines the key principles of Agile is highly technical and software-centric, it was initially difficult for non-IT managers and employees to grasp an understanding of the processes. To combat this, Tome enlisted an experienced Agile coach who was able to help spread Agile practices throughout IT and the company as a whole. The training and establishment of Agile teams within the organization's research and development (R&D) unit 'significantly compressed innovation project cycle times'in some cases by more than 75%' (Rigby, et al., 2016, para. 22). This statistic provides concrete evidence as to the efficacy of Agile on both IT and R&D projects, justifying the belief that Agile proves better for fostering information than the waterfall model does.
Ambit, a residential energy provider start-up, also implemented Agile techniques. CIO John Burke's primary reasoning for adopting the Agile is his prior negative experience with waterfall, stating that '[i]t creates this animosity where IT blames business because they didn't know all the specs upfront, and the business blames IT because the meeting wasn't organized well' (Vijayan, 2010, p. 14). Burke also describes the morale-based results within the company, observing that business units feel that they have contributed valuable feedback and that IT departments feel more connected with the business.
...(download the rest of the essay above)