To Agile or Not To Agile

agile methodology

In the world of project management methodologies, the two words you hear most often is Agile  and Waterfall. Although some purists may question Agile Methodology rather than more of a paradigm the reality is that these are two different ways of approaching project execution.

Traditional (Waterfall) Methodology

Projects that use the Waterfall, or more appropriately called Traditional, model follow a linear approach where a project deemed Feasible moves through progressive steps of Planning and Requirements, Design/Architecture, Building (Coding), Testing, Deployment to production and Maintenance/Support of the final product. This model is illustrated below.

In a true Traditional project, each stage is completed before the next one begins.  In reality, there is often some overlap moving from one stage to the next, but they are performed somewhat in the order above. The management of these types of projects is very hierarchical with a Project Manager working with a Sponsor to control Scope, Budget, and Schedule. A Business Analyst is generally employed to identify the requirements and specifications that the builders and testers will use to create and deliver the final project.

Agile Methodology

Agile projects use an iterative approach for creating products. As the name implies this approach involves a relatively small team (3-9 people) consisting of cross-functional, self-organizing builders/developers, a Scrum Master who facilitates the team, and the Product Owner who understands the final product and prioritizes the work accordingly.

Starting with a concept of what the final product will be, the Product Owner identifies the functional components of the product. These are further broken down into more manageable User Stories and then placed in a prioritized feature list known as the Product Backlog. The Development Team, along with the Product Owner, selects the feature(s) to be worked during a Sprint.  A Sprint is time-boxed and usually lasts between 2-4 weeks. Once established, however, each Sprint is that same duration.

With each Sprint the Development Team selects the most important features from the Product Backlog, identify the requirements and plan the work, design, build and test the feature. This piece of functionality may or may not be launched into Production but regardless the next Sprint cycle will begin immediately after the first.  This methodology is illustrated below.

As each Sprint is completed more functionality is added to the product as well as additional features which are added to the Backlog. This cycle could continue indefinitely. It’s important to remember that Agile is a methodology, not a definition of how a project gets done.  The Product Owner will determine when the product is complete, which generally happens with the remaining features in the Product Backlog are no longer relevant for the product.

Why Use Agile?

The Agile methodology is much more matrixed and less hierarchical than Traditional methodology’s. While its use is seen in several different industries today it stemmed from the world of software development. Traditional Methodology struggled with software development where requirements for the final product were not well-understood up front. Changes and new requirements caused budgets to be exceeded, schedules to be blown and a high failure rate for software development projects.

Agile methodology was created to develop software in a way that would improve success rates.  Its Manifesto outlined four key differences over the Traditional Method:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

This approach to software development greatly increased the rate of success by prioritizing major features, breaking those features into smaller, more manageable chunks that could be developed, tested and delivered in a short time frame, and providing a working piece of functionality after each iteration (Sprint).  Companies can manage their scope, budget and schedule much better since they can evaluate where they are at the end of each Sprint.

Halleluiah – Agile for ALL!!!  Or maybe not.

Agile was born from the principles of Lean manufacturing and organizational learning.  Other industries have found the Agile (or Agile-like) methodology the right approach for certain types of product development. It works particularly well when the road from idea to product is uncertain. Research and Development would be an area where this might work well. Process improvement would also do well with an Agile approach. I’ve even heard of a law firm using this approach in organizing and managing their legal affairs service.

Not all projects benefit by using an Agile methodology.  There are certainly projects where the traditional methodology is preferred and, in some cases, may be mandatory.

If you are doing a project with a well-established set of requirements and outcomes the traditional methodology may be a better way to go.  Construction projects are often this way.  A project funded by a fixed price contract may also do better using the traditional methodology, where the original scope is defined and funded, and deviations can be managed through Change Requests.  Compliance with regulatory or statutory requirements may be managed more easily using the traditional methodology. Government projects may even mandate that the traditional methodology is used.

Some final thoughts

Whether using Agile or Traditional methodologies there are certain traits that seem to be applicable to both.

  • Customer buy-in and involvement will reduce risk in either methodology.
  • With either methodology the more you know about the requirements and features the better able you will be able to plan the work.
  • While all too often a challenge, having teams that work well together will enhance the results from either methodology.