yeti logo icon
Close Icon
contact us
Yeti postage stamp
We'll reply within 24 hours.
Thank you! Your message has been received!
A yeti hand giving a thumb's up
Oops! Something went wrong while submitting the form.

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

Tony Scherba
August 7, 2019

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.

waterfall diagram

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.

agile diagram

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.

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".

Tony Scherba is a CEO + Founding Partner at Yeti. Tony has been developing software since high school and has worked on digital products for global brands such as Google, MIT, Qualcomm, Hershey’s, Britney Spears and Harmon/Kardon. Tony’s writing about innovation and technology has been featured in Forbes, Huffington Post and Inc. At Yeti, Tony works on strategy, product design and day to day operations, hopping in and working with the development teams when needed. Follow Tony on Twitter.

You Might also like...

business management strategyFinding Your Company’s Groove: How We Manage Our Remote Software Team

From company planning to team building and scaling operations, there’s a lot to unravel when managing a remote company. Discover how we forged a bespoke team management strategy by integrating the EOS model with our unique needs and processes - and how you can do the same.

Retreat in SedonaRetreat Planning 101: Crafting an Unforgettable Team Bonding Experience

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!

Yeti's 2022 Year in Review

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!

Browse all Blog Articles

Ready for your new product adventure?

Let's Get Started