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.
Agile methods for development software were invented 20 years ago and have now become the dominant methods 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 responsible for defining the requirements, the head of software development 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 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 nature of the need being addressed by the software release often changed such that the planned software release would not actually address the need that exists when the software would be completed. For the customer of the software, this means that you might have to wait many years for critical business needs to be addressed. For the development organization, this means that you’re continually bringing to market products that do not actually address the needs of your customer or, worse, result in projects being abandoned in an effort to avoid delivering a product destined to fail.
Agile, which was invented in 2001, solves those problems.
Agile methods break development down into smaller, shorter increments of development in which all of the phases in 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, a small set of features are designed, built, tested and released such that, at the end of EVERY increment – called a “sprint” – those features built in the sprint can be released.
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.
Apply this concept to building a house.
Under the waterfall model, you would spend months with an architect and designer creating the plan for your house including all details from flooring to countertops to paint colors. Then the contractor would start building the house and a year or more later, you’d 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, when you walk in and see the hardwood flooring that the builder used in your living room, you might change your mind about the paint color you want or tile you want in the bathroom adjacent to the living room. You would have an opportunity to adjust the plan. You might also look at the paint color after one room is painted and change your mind. While you might have to pay extra to have that room repainted, at least you didn’t end up with an entire house with colors you don’t like.
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.