Businesses want ultimate flexibility and speed to market. Developers want complete requirements so they can do their jobs right the first time without a lot of back and forth. Historically, companies have implemented a waterfall approach in which all the requirements are complete before any development is done. It can take a while to gather all the requirements for large initiatives and then just as long, or longer, to develop against those requirements. After that is done, a single long round of QA testing is undertaken and only then do products release to the wild.

Who’s happy in that scenario? You would think that developers win and businesses lose. The developers got exactly what they asked for, right? However, I think that both businesses and developers lose. It is such a struggle to fight against all of the “scope creep” that happens in a large waterfall project. That takes quite a lot of effort that most development teams and managers would like to put towards something more productive. And, when you sit back and really look at it objectively, who wouldn’t think of improvements to their requirements during a multi-month, or even multi-year, project. Do you often do everything perfectly the first time? Common sense tells us that we can’t expect that from a business either.

I think Gareth Evans put it perfectly in his blogpost (of which this is an excerpt):

Allow for late decisions in software development
Many valuable design changes occur through knowledge created during the development of a product. By designing everything up front we stifle innovation and do not arrive at the optimal solution. This is like empowering drivers to change route based on road conditions versus mandating a route for drivers before they start their journey and making them stick to it no matter what.

If the system isn’t working for you, don’t give up… change the system. There’s a reason for the Agile and Lean movements and this is a big part of it. Waterfall fights change. It tries to keep it from existing. Lean & Agile methodologies give teams the tools to manage change. Let that sink in… Change is not the enemy. Over time it lets you apply increasing levels of wisdom and experience, not only to your code, but to the requirements for what you’re coding.

For teams moving away from waterfall it can be difficult to get out of the mindset that you don’t have to know everything up front. Here are a few tiny steps to help you get started.

Step 1: Stop believing you ever know 100% about anything.

You have to start allowing yourself to move forward with partial information. How much information is enough? Well, probably not 5%. You want to allow for change but you need to be smart too. In a Kanban masterclass I attended, we were advised to learn to operate with as little as 80% certainty.

Step 2: Bigger is not always better. Break your project into manageable, viable pieces.

So, do you need to know 80% about the whole project before you start? Not necessarily. When you eat a pizza, do you stuff the whole thing into your mouth at once, even 80% of it? Unless you’re very unique, it wouldn’t be possible. No, we break it down into smaller units to eat it. Now you have a couple of options: a layered approach or a piece by whole piece tactic.

A layered approach would relate to building the core of a product with not very many bells and whistles, then adding on functionality layer by layer over time. A piece by whole piece approach is the idea of putting out individual features with all the bells and whistles, one feature at a time. Both ways accomplish the initial goal of subdividing a large project into smaller units. In each unit, apply step 1… stop requiring 100% certainty. The value of this is to shorten the time to market for initial pieces of the project as well as giving the product owners a longer requirements definition cycle on future layers or features.

Note: As I type this, I’m struck by the parallel to Kanban and how I explain why WIP limits are important. I like to explain to people by saying, assume you have 5 tasks to do and each takes 1 day. You spend 20% of your time each day on each task. You are able to deliver your first thing to the client in 5 days.  If you decide to do one thing at a time (the equivalent to breaking it down into pieces), then you spend 100% of your time each day on a single task and deliver the first thing to the client at the end of the 1st day. You exponentially improve time to market.

Step 3: Realize the value of shorter feedback loops

By completing steps 1 and 2 you have shortened time to market and therefore shortened your feedback loop. Faster feedback means you implement improvements earlier in product development, which is less costly than waiting until the whole shebang is finished. You can even learn to apply the OODA Loop. This describes how you should react to feedback. A first decision is based on best information. Once that has been executed, you then follow the following steps in this order:

  • observe (collect the feedback)
  • orient (interpret the feedback)
  • decide (define necessary actions based on the observations and orientations)
  • act (well, this one’s obvious ;))

Success : So your legs may not feel quite like a landlubber’s yet, you are well on your way to a more adaptive process that produces better results. Your journey is not over. You have to OODA. Always. You have to continue learning about ways to streamline process and delivery. You have to keep an open mind and understand all the players in the system. Its a full time job, and its not always pretty, but someone has to do it. Don’t think you can do it?

Yes you Kanban 😉