The Agile Method: Getting Comfortable with Uncertainty

Agile is one of the most effective ways to deliver value at the speed of business. To be successful, you have to get the appropriate stakeholders on board with the reality that we might not always know what we're going to be working on next. There will be times when a stakeholder will ask “I have this idea. When can it come to fruition?”, and the development team won’t be able to provide them with the answer they’re looking for. Instead, we will do everything we can to ensure that our teams are always working on what’s most valuable to them at the moment. By doing this, we will make progress and deliver capability along the lines of what you're looking for. We will take what we learn along the way to make this capability better with each iteration — and as long as it's still the most important thing to you, we'll keep making it better.

Agile Isn’t Comfy, It’s Effective

An Agile approach is a very effective way to get feedback early on and for validating business decisions or business requests, but it requires a belief in something that is almost antithetical to what most people who are brought in from the business side of the world understand. What’s comfortable to a lot of businesses are things like timelines, strong, rigid budgets, and being able to see burndown charts with lofty plans coming to fruition. They want certainty, and the problem with Agile is — it’s not designed for certainty. The only guarantee we can give is what I mentioned earlier: that we will always be working on what’s most valuable to you at the current moment. We can give you capabilities that are getting better over time, but it goes against the concept of Agile to provide any level of absolute certainty when something is going to be “done.” The reality is, our definition of done today simply won’t match what our customers are going to expect tomorrow.

Beware Snake Oil and a One-Size-Fits-All Approach

What we see in the industry is a lot of people saying that they are “being Agile”, but really they are just going through the motions. They're running things in two weeks sprints, they're having planning sessions, and doing all the things that you might think of when you hear the word “Agile.” However, they're incorporating, or they have been sold a framework for enterprise, or business that tries to apply pieces and parts of Agile alongside that comfy blanket of certainty — and those things don't mix well.

Here’s an example: we worked with a customer who came to us who had introduced the Scaled Agile Framework (SAFe) as their Agile practice. In order to implement SAFe, they went out and found someone who had a background in the framework and brought this person in to introduce SAFe to the organization. The problem is that SAFe was designed to address problems that large organizations experience when implementing Agile at scale, things like inter-dependencies among teams and aligning major software releases when you’re working with tens or hundreds of engineers.  This customer only had two development teams. At that time, they didn’t have the problems that SAFe was designed to try to combat. They simply didn’t have the scale to be applying this kind of framework, nor the personnel in place to do their part on the business side to make it a success.

These are the kind of missteps that more and more businesses are being sold; bringing in consultants because they're trying to make this shift from a more Waterfall mentality to an Agile mentality. They hear the benefits of what an Agile process can do, but they don't know how to do it themselves — so they bring in experts. But when those experts don’t take the time to understand the needs of their business, don’t take the time to instill an Agile mindset throughout the organization, and instead instill a framework that they’re familiar with, the chances of those benefits they are seeking coming to fruition are slim to none.

Believing is Seeing

So, what is the path to finding a solution that works best? Unfortunately, it's one of those things that you almost have to see to believe — and that's what makes it so difficult. You can bring in companies like Aviture, who try to promote these Agile mindsets a bit more, but how do you know that we're any different from any other consultant who might be telling you to use a certain framework? If you’re a business looking to implement Agile, it’s going to require a bit of research on your side to understand what its real purpose is and what you believe it can enable your team to accomplish. You must get bought into that concept of iterative delivery of the most valuable thing in the moment, and you've got to get buy-in from other decision-makers in the organization to give something like that a try. If the expectation is to satisfy the executives in your business who might be looking for that certainty on things like scheduled budget, time, et cetera., and you pitch Agile in the wrong way, you’re setting yourself up for a failed experiment. You're not going to see the magic that really happens when you can get a team that's self-motivated and self-organizing, with deep context into the problem they're solving, taking their creative energy, and focusing it on the thing that is the most valuable to the business.

Becoming the Hero

Research and understanding Agile is incredibly important to making the right decision for your business, along with knowing how to sell it as a concept to the rest of the company. You might have to put yourself out there a little bit and take a bit of a leap of faith to get to that “show me” moment. But if you can use some of that capital you've built up over the years in your business to get people to take that leap of faith with you, and you do it right, you can be the champion or the hero in the story, not just the person who took them down an agile rabbit hole. Successful Agile is a fight worth fighting for, that I’m certain of.