Don’t go chasing waterfalls

This metaphor basically sums up the struggle of a lot of organizations who want to be agile, but fail in being it. Agile isn’t just a way of working, it’s a way of life. It goes further than reading a book about it or following a crash course to become certified. Agile needs to be implemented deep within the roots of an organization. But more on that later.

Embrace uncertainty

So what is agile? Answering that question wouldn’t be agile. Because every description of agile is, in fact, not agile. Sounds very contradictive and complicated, now does it? So, for arguments sake I’ll give a brief description on what agile can be. Agile is all about embracing uncertainty and with that, the willingness to change without knowing the exact outcome.

Agile uses iterative cycles called sprints done by a scrum team to develop, test and release product increments until the minimum viable product (MVP) as defined by the business representative is done. Optionally refining the MVP with additional features, agile is all about creating value. So unnecessary features that do not create (business) value, should not be developed.

Benefits of agile are a higher delivery rate thus shortening time to market and creating more business value. Originating from the software development world, agile is being used widely as way of developing, improving and releasing non-IT products too. And to take things even further, agile is also being implemented in teams, in order to stimulate innovation or to align intercompany departments.

Waterfall approach

Agile came as an answer to the waterfall approach. Seen as the counterpart of agile, the waterfall approach is all about the big design upfront. Meticulously describing every process, functionality and aspect of the product before developing even starts. One of the problems of this approach is that it takes up a lot of time. And when the product is released, risks are that demands in the market or customer wishes have changed significantly.

It’s in my own business experience that most organizations who want to work agile, used to work with the waterfall approach. One of the biggest challenges for those organizations is the willingness to embrace uncertainty and with it change without a certain or known outcome.  Now that’s more nicely said than done. Because let’s be realistic. Things usually get complicated when there’s money involved.

By asking the big design upfront question, organizations not only seek certainty on how their product will look like and what it will do. They also want to know how much the product is going to cost. With estimates being as close to actuals as possible. It’s that question you’re dying to ask, when you’re in that upmarket store that doesn’t have any prices listed. So, how much is it going to cost?

Because being in control is just as important to the board as actually having an all new cool product or neat feature. And when things get tense and budgets are tight, the usual go to reaction is to exert even more control. Chasing waterfalls. Setting even tighter tolerances, creating more boundaries, executing more useless processes and fleeing into the perceptive safety of writing endless exception reports to safe ones neck.

People over processes

But exception reports do not solve problems, people do. If you want to be agile, that means that you have to learn to let go. Let go the will to control the things you basically cannot control in an agile developing process. And that basically extends to everything you want to change in (business) life.

In an ideal agile organization bottom up empowerment is key. Responsibility is not a management thing, but a shared effort for all. But all responsibilities need to add value for the customer. Setting tight tolerances, creating boundaries, executing processes because it’s the process and writing exception reports are activities that do probably not add any value for the customer. I’ve seen organizations that had processes or standard operation procedures (SOP), with no one being able to explain why they where there or what value they added to the (core) business. I find that to be rather shocking.

With agile, the life cycle of an idea is a business theme that needs to be translated into a feature set, user stories (as a … I want … So that … ) and eventually a product (increment). Business sponsorship, trust and the willingness to learn from mistakes in order to prevent them to be made again are key. They will determine whether you will succeed or not.

What about the money?

If you’re still wondering when I will come back on the topic of budget issues and forecasting, then you’re not that agile. If you were simply curious on how this blog will conclude, congratulations! You are starting to get pretty agile and passed the test. With agile it’s extremely hard to give exact estimates on total costs and durations of development, simply because you’re working with short sprints and releasing product increments as you go. Benefits are that you actually have more control over a project than with waterfall development.

Meaning: yes, there is product backlog with user stories and a defined MVP. But demands of the customer can change, because the world is changing. You need to be prepared for change with an uncertain outcome, so embrace it! The velocity of the scrum team developing the product can change too. Usually velocity goes up the more sprints the scrum team does. But sometimes the team will encounter (unforeseen) issues that cannot be resolved in a sprint or will lead to a decision that can impact the MVP. Hence: the uncertain or unknown exact outcome. Thus impacting the development process. And the budget.

So how can I be agile?

Agile is all about the willingness to embrace uncertainty and change with an unknown outcome. About translating cool ideas in cool products that add value. About releasing product increments, which allow organizations to refine, add or even change features in the process of developing instead of releasing upgrades or patches after the product is released. It’s about testing and discovering potential flaws or errors, with the ability to react and resolve instead of concluding that ‘apparently something went wrong here and now we seem to have a faulty product.’

Don’t go chasing waterfalls. Agile is all about team play, shared effort, success and partnerships. And this holds the key for solving that nasty budget thing mentioned earlier. Because whether you have your own (IT) department developing a product or an external supplier, you’re in this together. The flexibility agile offers, will empower you and enable you to make the best choices in regard to adding value for the customer and determining whether you’re willing to make that investment or not. And with that, you’re in control too.