Agile is like building a car… but not in the way that you think.
When we build a car via the Agile methodology, we will not build the car one wheel at a time, and then the body, and then the roof. It will NOT look like this:
*Concept and image by Agile and Lean coach Henrik Kniberg
Still, many organizations claiming to be Agile build software in phases. Each phase is a component that will all be assembled at the end of the last phase — in time for a big application launch. The approach masquerades as Agile by presenting the progress of each phase to the users and inaccurately calling it a sprint.
The enthusiasm to call something Agile is understandable. Successful applications such as AirBnB, Spotify, and Facebook were born as prototypes quickly and passionately coded by their founders. Actual users helped snowball these prototypes into the massive apps that are now part of our everyday lives. But transitioning to Agile is not as glamorous — nor as easy — as it sounds. It does not happen overnight. It entails a major shift in mindset and culture that has ingrained the Waterfall methodology for many years.
In a Waterfall approach, developers already know that the end goal is a car that will take users from point A to point B. They build a car. Users test drive the car after it is completed. In the end, the car will have wheels, a body, an engine, and a roof. It is safe and reliable. The client uses the car to drive to and from work, and is satisfied.
Did we succeed in building a car? Yes! Did we do it via Agile Methodology? No. So why not stick with traditional development? In this example, it is fortunate that the user is satisfied with a sedan that can get them from point A to B. In other cases, the user may find the car boring and not suited to their lifestyle. They want to feel the wind in their face. But changing the car to satisfy this user will entail tearing down the body of the car and rebuilding it into a convertible. If only the team got that feedback earlier, they wouldn’t have wasted time and money building a sedan. In this instance, Agile is the more appropriate approach.
So what is the Agile way to build a car?
Analogous to our own software development experience, the first thing we will ask our users is why they want a car. The answer will be to get from Point A to Point B fast, comfortably, and without tiring their legs so much. Also, they would like something they can use in two weeks’ time.
*Concept by Agile and Lean coach Henrik Kniberg. Image modified for the purpose of this article.
In this case, we propose a Minimum Viable Product (MVP): a skateboard. An MVP is a prototype with just enough features to work for early adopters and to provide the development team early feedback about viability. A skateboard is not a car, but it will get the client from point A to point B (the main goal for the user), it is faster than walking, plus it can be built in 2 weeks. After trying the skateboard, they may say they tripped and fell a lot. But it is viable. It is usable. It is testable. This MVP is a good place to start.
The next iteration may be a scooter. It’s not a long way from a skateboard, but it has a handle so the user can change directions and does not fall as much. They can get to places more safely, but their legs still get tired. That’s good feedback. It validates that safety and comfort are important to the user.
A bicycle as the next iteration is still not a car, but it can definitely get us somewhere. It’s faster, safer, and less tiring than a scooter or a skateboard. Then, a motorcycle — now that’s a game-changer! A motorcycle has an engine so there will be no pedaling involved. You can ride a motorcycle on an open road. After test driving a big bike one windy afternoon, users may realize that looking cool was important to them and that they love feeling the wind in their faces.
*Concept and image by Agile and Lean coach Henrik Kniberg
Thus, in the fifth iteration, instead of delivering a sedan as was previously planned, the Agile team delivers a convertible car. The convertible does all the things that the users wanted a vehicle to do: get from Point A to Point B fast, comfortably, and without tiring their legs as much as walking does. By incorporating feedback in previous iterations, the development team built a car that is safe, that looks cool, and that has an open body so that users can enjoy the wind on their faces while driving.
The users are more than satisfied. They are elated. Because users were involved in the creation of the product through the feedback process, they got features they didn’t even know they needed at the beginning of the project. In the end, the pivot from a sedan to a convertible paid off.
Now that’s Agile!
Having built dozens of applications over the course of 2 decades, we have witnessed how the transition from traditional Waterfall development to Agile development can be challenging. As we get feedback from users in every sprint, there is uncertainty in what the final product will be. This uncertainty can be uncomfortable. On the plus side, taking the software to a different direction based on what the users really need and will love is a much better strategy to ensure adoption and loyalty. And that is the Agile way to build software (and a car!).
Not sure where to start? Reach out to us! We will help you create amazing apps for your brand from design thinking to Agile implementation, and beyond. Fill out the form below to book a discussion.
