Flavors of Agile

Posted in management by Christopher R. Wirz on Fri Feb 14 2014

There are several project management approaches based on agile methodologies. The term "agile" became common vernacular during the dotcom boom (~2001) but has roots from throughout the 1900s. The family of product development methodologies known as agile focuses on iterative and incremental tactics to produce a product using constant planning, understanding, improvement, team dynamics and delivery. In many contexts, agile methodology is associated with the software development lifecycle as it can be used in all phases: requirements analysis, planning, analysis and Software Requirement Specification (SRS), design and product architecture, building and implementation, integration and test, and deployment and maintenance.

Agile methodologies make sure that development, testing and planning are both parallelized and synchronized – giving agile an advantage over waterfall in certain circumstances. For example, agile favors individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. While the pitfalls of each of these preferences might be obvious to some, they have the benefits of early customer satisfaction and successful execution where success is measured by progress.

To achieve this, agile boasts flexibility and high collaboration with stakeholders (e.g., customers). While agile can work well if a stakeholder can articulate the final product and the problems it solves, agile also uses its high visibility and iteration to define and refine requirements – but only in certain flavors. Given the different types of product development methodologies and life cycles that agile hopes to address, there are several different flavors of agile. These generally fit the different priorities that a project may have a driven by team and stakeholder dynamics.

Note: There are many flavors of agile, but this post hopes to cover the four commonly seen in software practice in the US with noteworthy historical significance.

The Scrum methodology is the most popular agile methodology in software development. This framework came from the research of DuPont in the 1980s when evaluating practices that effectively mitigated failure. Scrum breaks down the development process into smaller cycles called sprints. Each sprint has its own set of goals and deliverable – which is provided for stakeholder review for refinement, iteration and retrospective. A focus of scrum is the ability to provide a delivery at any time and let designers adjust priorities in order to successfully complete subsequent sprints. Each sprint gives the team visibility as to how to complete the next sprint, and implementation is planned at the team level with buy-in from the product owner.

The Kanban methodology was developed by Toyota in the 1940s are part of the agile family of project management approaches that encourage frequent testing and collaboration. The Kanban methodology provides all participants and stakeholders constant awareness of where each piece of work stands at any given time. It helps quickly identify risks and bottlenecks – and aligns to a critical path or form of living project management plan. During Kanban, work is pulled from a predefined backlog – meaning that the backlog, and requirements, has to be well understood by the team. The expectation that the team is not reinventing requirements throughout the product development lifecycle. This allows the team to deliver a product on time and to completion.

The Extreme programming methodology emphasizes near-real-time feedback, communication and teamwork. It was first piloted by NASA in the 1960s for the first human spaceflight. During that period of time, computer hardware was limited so efficient, accurate, and understandable code was imperative. The intention of extreme programming is to improve software quality and responsiveness to customer requirements. This method also uses sprints to deliver short, incremental releases. Code reviews, test driven development and unit tests are a major component of extreme programming. Typically, this uses paired programming to ensure development of only the most needed features and sustainable code.

The Lean methodology became popular in 1913 with the adoption by Henry Ford in a desire to create a wide variety of potential product offerings from a single process starting point – and bring the product to completion. Lean was thoroughly described in the 1990 book The Machine That Changed the World (by James P. Womack, Daniel Roos, and Daniel T. Jones), which focused on Toyota's adoption of Ford's concepts in the 1930s. Lean starts by identifying the value desired by the customer, map the steps to deliver value and eliminate wasted steps, make the product flow as continuous as possible, couple all steps in production as much as possible, and continuously improve the product and process to perfection. The purpose of Lean is to eliminate waste while maximizing value. This frees up bandwidth to additionally improve product quality. Lean does not focus on predictions. Instead, if focuses on delivering a minimum viable product in the minimum number of sprints, and then improving product quality in the remaining sprints. If the product has a clear vision, lean focuses on delivering that – before anything else. One advantage of Lean is that it allows the stakeholder to quickly reject a product that is not desirable. Lean also uses Test Driven Development (test cases for acceptance) and Behavior Driven Development (use cases as acceptance).

These are probably the four most distinct methodologies of Agile with the longest and most robust history. Other flavors of agile mix and match concepts from each to further address team dynamics and project priorities.

Dynamic Systems Development Method (DSDM) takes concepts from the previous methodologies to focus on Rapid Application Development (RAD). DSDM is a governance and framework for RAD. RAD became popular in the early 1990s to develop graphical prototypes. The problem with RAD is that it doesn't always lead to complete or defect-free products. Like Lean, DSDM focuses on business need and on-time delivery. It uses prototyping from RAD, collaboration from Extreme programming, iterative development from Scrum and continuous communication from Kanban. DSDM uses timeboxing to achieve milestones, and priorities the deliveries within each by must, should, could, and won't have. Each timebox uses configuration management (CM) to track deliverables. Part of the CM package is the test results of each iteration and notes from the workshop with stakeholders which articulate requirements and understanding of intended functionality.

Feature Driven Development (FDD) uses each sprint (taken from scrum) to focus on the creation of a specific feature (taken from Lean). Like Kanban, it relies on teams with advanced design and planning capabilities and can be used to break major projects down (like DSDM). Using an overall model of the desired product, the team builds a feature list which is broken down such that each sprint plans, designs and builds a feature.