_edited.png){kind=logo}
As software developers, we constantly have to do more with less. We’re expected to create something brand new that outperforms what already exists, all while making smart decisions based on assumptions. Let’s not forget the whirlwind of the ever-changing, contradictory, and ambiguous demands of customers and stakeholders.
But the thing about assumptions is that they’re just that—assumptions. Even with the best resources, we can never be sure about any of them until they’re executed and tested (and money is spent).
So how is Agile supposed to actually help us with the problem of having to make so many weighty assumptions?
First off, the known and understood problems aren’t the issues; it’s the faulty assumptions that cause the pain. Ideally, we wouldn’t have to make any assumptions. But that’s impossible because we create brand new, never-before-existing products and processes (it’s why we’re paid the big bucks). So, by definition, there will be unknowns and we have to make some assumptions.
So we try to make better assumptions, but we become trapped in analysis paralysis. We spend so much energy on:
Desperately trying to find and analyze data
Dealing with competing interpretations of the data
Wrangling to get buy-in on the ‘correct’ assumption
It is an exhausting and expensive process that generates arguably better, but still fragile assumptions. We’ve all experienced the sharp bolt of panic and after taste of shame when a critical assumption falls through—never mind the cost of money/materials/labor spent on rework to deal with reality.
So we have an exhausting and fragile process in analysis paralysis. How do we get ahead? To do more with less?
Agile is the mentality of trying to see reality for what it is. It’s a mindset to use in our attempt to drive the number of assumptions to zero. We’ll never be rid of all the assumptions. But in rooting them out, we are likely to remove the most dangerous ones.
We must still make assumptions, but instead of being mired in analysis paralysis and waiting months to see the results, we run experiments and engage in continuous delivery to gain immediate feedback. Instead of assumptions living for months, we quickly test them and quash the faulty ones in weeks.
Agile does this by shortening the feedback loop. The shorter the feedback loop, the quicker assumptions can be tested. It does this by:
Using working software as the measure of progress, letting us test assumptions
By delivering working software quickly and often, so we can quash long-living assumptions and root out the most dangerous risks
By building cross-functional teams, so that we avoid knowledge silos that constrain reality
Because in the absence of reality, we make assumptions.
Interested in learning more about how Agile can help? We’re here to help you turn abstract concepts into concrete Agile practices tailor-fit for your team. Reach out!