How a Roundabout is like Product Development

334_roundabout1I quite liked driving through New Zealand and Australia. Like most countries outside the U.S., they use roundabouts to deal with intersection traffic.

The rules of a roundabout are quite simple: you must yield to oncoming cars to your right – otherwise – go. Most of the time there are no cars coming and you can avoid the “come to a complete stop” law all together.

I find the iterative development cycle works in much the same way. In older more classic models, a product manager and their stakeholders work diligently to make sure specs are completed thoroughly before marking them as “ready for development.” In reality, the a majority of what *can* be done dramatically changes as new information is made available (digging into the problem, user feedback, stakeholder feedback, complexity etc.) The “stop” heavy culture of elaborately planned tasks are often thrown away the seconds after development, and issues, start. The real knowledge comes from implementation and iteration once each atomic feature is released. It also requires trust in those that implement to have a good enough understanding of the high level purpose of what your product is trying to achieve.

What if something goes wrong? Well, just like with a round about, development yields when there is” oncoming traffic” (AKA an issue getting flagged.) In scrum, the flag can be raised at standup meetings or planning meetings. If there is no flag then the developer does the best they can to implement the best way they can. In essence, they are entering the intersection and driving on through. This lack of congestion on spec creation can be better spent on feedback, iterations, and issues that come up. (In reality it is where the most critical time has always been.)

So, next time you’re concerned about how a task *should* be completed, and feel the need to surround yourself with stop signs, imagine the steady flow of a roundabout. Give your team the freedom to produce, stay available for issues that *may* come up, and when a change needs to be made revisit the task at hand.

Comments

comments

Leave a Reply

Your email address will not be published. Required fields are marked *