When Yeti was in it's infancy we knew that one of the keys to creating successful products would be our ability to adhere to a well defined development methodology that would allow us to structure, plan and control our projects.
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.
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.
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".
Are you faced with the daunting task of planning your company's upcoming retreat? Does the mere thought of it make you break out in a sweat? Take a deep breath and rest assured - we've got your back!
2022 has been a record breaking year at Yeti! Let's take a look back at all of the fun we had in our Year in Review!
While volunteering is beneficial for the community, it can also deliver benefits to your employees and organization.