How to Think About Agile for Executives: The Evolution of Agile Part One

Because it felt natural for us to build things in a linear, sequential fashion- similar to the way you might think about building a house- we were initially drawn to a development framework known as “Waterfall”.

Waterfall is a methodology with roots in non-software industries such as manufacturing and construction - fields in which projects must happen sequentially.

If you imagine the way you might build a house you are loosely envisioning waterfall - the house is designed and then built, starting with the foundation, floor, the walls and then the roof - it has a definite beginning and end. It’s simply not possible to work out of sequence.

Similarly, development work in Waterfall ​involves sequential phases of design, development, validation, and iteration ​where no phase begins until the prior phase is complete and no phase can be returned to without starting over.

However, we quickly learned that successfully building software isn’t actually much like building a house. A house is, for the most part, a static product. Once the blueprints are finished and construction is underway it’s not likely that many changes to the original plan are going to be made, and if they are, it’s probable that they will be made at a very high monetary and time cost.

Software, on the other hand, requires the ability to adapt to changing demands. As an executive stakeholder begins to see their product come to life, it’s extremely common for them to request changes.

These changes are extremely costly and time consuming when using the Waterfall framework as it’s very likely that the team has already moved on to an entirely new phase of the project, and to change one aspect of the product might mean having to start from scratch again on other, already completed components.

It’s much more beneficial to approach building software in the same way you would building a resort (just with drastically different time periods). If you imagine yourself as a resort developer with an island you would like to develop, it’s easy to understand why you might not want to build everything concurrently.

Instead, it might be beneficial to begin by building some beachfront bungalows, to determine whether the location is attractive to vacationers while at the same time creating capital to build a restaurant.

Once the success of the bungalows and restaurant prove that there is a demand to stay on the island, you might decide to build a hotel to accommodate more guests, and then a small airport to bring them there.

If you had gone the other route and built the entire resort concurrently, upon completion you might find that the much more interesting resort a few miles away keeps vacationers from staying at yours, or that the location has a nasty bug problem (pun intended).

It’s also possible that some overlooked issue might result in your running out of money midway through the project, leaving the result a giant colossus, half built and unusable. All of these possibilities mean millions of dollars and man hours lost.

Building software is very similar in nature. On a very large scale, you might imagine building a product similar to facebook, with all of its pieces and components, in one fell swoop.

What often happens in this case is finding yourself partway through the development phase only to find that a complication with the design expands the scope of your project significantly. Or you might run out of money midway through the project with everything half built and no way to generate the capital you need to finish it.

With all of this in mind, it became clear that waterfall wasn’t the right framework for us to use when building our products. Everyone talks about Agile, a more modern methodology ​created for software development, and on paper it made sense to us.

Where Waterfall is extremely linear and sequential, Agile is iterative and incremental, placing its emphasis on rapidly delivering functional components of a product in two week cycles called sprints. This addressed some of the major issues we’d run into during projects where projects could easily become endless monstrosities.

In Agile, work goals and deliverables are defined by the team before the start of the sprint, and the sprint consists of developing and testing the designated deliverables, which are then reviewed and evaluated by the project team and executive stakeholder.

A tested and approved working component of the product is delivered at the end of the sprint, and then the sprint process starts again with a new deliverable. This continues until the product is complete.

As we began working with Agile, it’s huge range of benefits became apparent.

• Agile Projects are Failproof:​ Agile eliminates the chance for projects to fail completely. By delivering usable pieces of the product at the end of every sprint and receiving feedback on those pieces, you don’t run the risk of spending hundreds of hours (and even more dollars) building a flawed product.
  
  And because you are delivering usable features at the end of each sprint, you won’t find yourself with a pile of unusable code, regardless of what may happen in the future of the project.
• Stakeholder Involvement and Satisfied Clients: ​While Waterfall only allows for client/stakeholder involvement at it’s very first stage, Agile relies on a high level of executive involvement throughout the project, which is mutually beneficial in many ways.
• Because Agile allows for quick cycles and consistent feedback, the development team is able to make changes and adjustments sooner rather than later, helping to ensure they are always on the right track - even if the requirements shift.
  
  Additionally, rather than requiring the client to wait until the entire product is complete, Agile allows the client to assess the work being delivered at the end of each sprint, meaning that changes aren’t nearly as costly or time consuming as they would be when utilizing waterfall.
• Better Products:​ In Agile development, testing is conducted during every sprint, allowing defects and other potential usability problems to be identified and fixed immediately,maintaining the quality of the product throughout its development.
  
  When utilizing Waterfall, the entire product is completed and then tested and consequently, when there is a problem you will likely need to backtrack multiple steps in order to fix it- a time consuming and costly procedure. In Agile, adjustments can be made each sprint so as everyone’s understanding of the product evolves so will the product itself.

From the get-go we loved working within the agile framework. Shorter, function-based projects provided a nice balance of speed and flexibility, and our team felt less burnt out than they had when using waterfall.

However, we discovered that our clients, the executive stakeholders, weren’t as thrilled with the process, primarily because they felt like accountability was lost in the process.

Continue to Part Two of this article: "When Agile isn't enough".