For software development professionals, working with “agile” development methodologies (agile methods) such as Scrum or Kanban is an easy-to-understand and obvious choice. For business professionals who may not be experts in development practices, this may be less obvious, so we thought we’d take a few minutes to explain.
Twenty years ago, software developers invented agile methods, which have since become the dominant method used by technology firms. A number of methodologies preceded agile methods, most notably a process called “waterfall”. To explain the value of agile, you need to understand the limitations of what it replaced.
The waterfall method followed a set path to defining, building, testing and releasing software that include distinct phases for:
- Defining product requirements – the features and functions as well as non-functional requirements such as scalability – that the software should support;
- Creating designs for the product that meet the requirements;
- Writing the code to support the requirements and designs;
- Testing the product and fixing any problems – referred to as defects or “bugs” – in the software;
- Releasing the software.
Seems reasonable at first impression, but there are a few challenges…
The waterfall process centered around a contract-like agreement among stakeholders about the requirements defined in phase one. All parties – the head of product is responsible for defining the requirements, the head of software development is responsible for writing the code, the head of quality responsible for testing the software, the head of marketing responsible for generating demand, the head of sales responsible for achieving a revenue target – would all (quite literally in many cases) sign off an agreement that the requirements were “right,” and everyone was committing to achieve their intertwined goals based on those requirements.
This forced the organization to stick to the agreed-upon requirements set out at the beginning of the project and NEVER make changes or additions to the plan along the way else those changes/additions be the cause for a release delay. Because waterfall prioritized bringing an entire product to market, it could require a year or more to complete a release.
During that time, the software release frequently underwent changes in response to shifts in the nature of the need being addressed. It causes the software release to not align with the actual need when the software is completed. For the software customer, this implies potentially waiting for many years to address critical business needs. For the development organization, this means continually introducing products to the market that do not genuinely meet customer needs or, in some cases, abandoning projects to avoid delivering a destined-to-fail product.
The invention of Agile in 2001 solves these problems.
Agile methods break development down into smaller, shorter increments of development. All of the phases in the waterfall are completed, but on a MUCH smaller and more frequent basis. Under the most common version of agile development, called “Scrum”, product increments are anywhere from a week to four weeks and, in my experience, two weeks seems most common. During that short interval, the team designs, builds, tests, and releases a small set of features so that, at the end of EVERY increment – referred to as a “sprint” – they can release the features developed during the sprint.
This created a shorter delay between the identification of a need and delivery of functionality intended to address the need. The result:
- Faster delivery of value to customers;
- Ability to improve features more quickly by listening to customers after they use a feature and incorporating improvements into subsequent sprints in an effort to optimize the customer experience;
- Fewer products failing in the market;
- Ability to release individual features without necessarily having to wait for a complete software release.
Read: What Are the 12 Principles of Agile Project Management?
Apply this concept to building a house.
Under the waterfall model, an architect and designer spend months creating a detailed plan for the house. This plan includes everything from flooring to countertops to paint colors. Then, the contractor begins building the house. It takes a year or more before you finally get to see it for the first time. But what if six months into the build, you discover you’re pregnant and should have added another bedroom? Should you have to wait until the house is finished and then build an addition? Or what if you decide that the shade of paint doesn’t quite look right? Shouldn’t you say something after the painters finish the first room instead of after they paint all the rooms?
Using an agile approach, you’d get to see the house every week during development. So, looking at the hardwood flooring in your living room may prompt you to reconsider the paint color or bathroom tile choice. You would have an opportunity to adjust the plan. Also, look at the paint color after one room is painted and change your mind. You may need to pay extra for repainting that room, but at least you avoided having an entire house with colors you dislike.
In summary, agile methodologies deliver to the business who use them:
- A greater likelihood that your product actually addresses the needs of your customer and you find a market fit;
- Software that your customers enjoy using because you were able to listen to their feedback and improve incrementally.
Michael Manzo