Let me start out by saying that implementing Agile ourselves was no easy task, but now our business is stronger and more efficient than it's ever been.
Why Agile and why should I care?
I’ll begin by speaking about the methodology that many teams start out with, Waterfall. When it comes to building a house, it makes sense to measure twice and cut once, doing an enormous amount of planning up front in order to mitigate as much risk and as many variables as possible. Most people who are new to software don't necessarily realize that this approach is not a very good one when it comes to building things that require frequent change and iteration based on user feedback, such as software.
As a result, Waterfall projects run the risk of delivering limited business value until the entire product has been built. There are fewer opportunities to test features with users and find out what does and doesn't work in real time.
What risks can you face at the end of a Waterfall build-out? A piece of software that likely requires many of the features to be modified in order for the product to be what the intended users actually want. We knew there must be a more efficient way for our team to anticipate these iterations, accommodate our customers requests and build better products.
Enter Agile. Agile is a methodology that was created as an answer to this problem. It allows our team to focus on the highest priority features in 1-2 week phases called "Sprints." At the end of each Sprint, we have fully usable features that we can deliver to beta testers and gather feedback on. We repeat these 1-2 week Sprints until the first version of our client’s product is ready to ship. This way, the entire team is learning and iterating throughout the entire build-out and we are delivering features that users actually care about. This is how you succeed at building software.
So how did we implement it at Teeps?
If it’s in your budget, I recommend hiring an Agile Coach with a good track record. I'm going to talk about what we learned implementing the Agile process ourselves with me as an interim Agile Coach.
Get Company Wide Buy In
This was quite possibly the most difficult thing we encountered in our transition to Agile. We learned that you can't just run into a room, guns blazing, and say, "Everyone! I have the solution to all of our development problems! There's this methodology called Agile and it will fix everything. Drop what you’re doing, we’re starting right now!" It simply won't work and people will be in shock, unable to move along the adoption curve.
Instead, we learned to think in terms of effective change management. Often when you first bring a new concept to people, you may be completely bought in, while they are just becoming aware of the problem. We had to exercise patience here and allow everyone to process the change that we were proposing. We met each team member where they currently were, and gently guided them into the change.
Educating Our Clients
Once our team was following the process, we quickly realized that our clients also needed coaching so they could be better prepared for their build-out with us. We designed educational materials and scheduled sit down meetings with many of our clients to explain the process and all of the ways it would benefit them. A little advice - avoid overwhelming discussions about features and buzzwords. We found that our customers simply want to know how this change is going to impact their experience.
Fixed Estimates are a Thing of the Past
Our customers often request a ballpark estimate before hiring us for their development project. We gladly provide a general estimate, but only with a disclaimer that formal Sprint Planning meetings are required to truly understand the effort and cost of the project as it unfolds. Companies that provide an upfront proposal and a fixed cost without conducting a proper Sprint Planning will set unrealistic expectations between the client and the development team. Both parties will be working against each other right from the start based on a budget and a set of requirements that will inevitably change.
Agile solves this problem by breaking a large project down into digestible two week chunks. By conducting Sprint Planning meetings, we take the time to understand each product feature, provide our technical recommendations and commit to an amount of work that we believe can be completed during the Sprint. Our clients appreciate having functional pieces of their product every two weeks and have the freedom to iterate quickly. After a couple of Sprints, we can effectively gauge the velocity of the team, and estimate out the remaining requirements with the knowledge gained along the way. This provides an idea as to how we and our clients perform together, and it is the only fair way to build software.
The process of adopting Agile at Teeps has been incredibly rewarding for our team, but not without its challenges. We will be posting future articles on the specific components and roles within the process. If you have ever implemented Agile, we’d love to hear about your story.
Want to start a project with your team? Let's chat.