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.

Short Cycle Scrum: A leaner, meaner, scrum.

Here is a summary of how we implemented a leaner, more efficient Scrum at Socialize coined Short-Cycle-Scrum. We have added some rules of thumb, and processes around ou Scrum to deliver stories with a surprisingly good amount of efficiency. This is a style we have specially tuned for short sprints (usually one week.)

Short Sprints Cycles
Sprint plaanning meetings can go long. They should definitely go as long as the need to, but no longer. One of the main reasons to have a sprint planning meeting at the beginning of yur sprint with the whole projects team members is that having a system that relies on having meetings throughout the week are like death by a million paper cuts for each developers time. Many times, those metings throughout the week are unfocused, not involving all the members of the team needed, and breaks up a developers day. most likley one devlopers need for a quick meeting means another developers inability to focus on delivering their story. So, with a single, team wide, sprint planning meeting you take care of all the discussions scheduled for your sprint as a team, all at once, when every one is in “meeting mode”. The goal is to get as many questions out of the way as possible. By the end of the meeting all your developers should be confident enough to solve their own questions or problems, as much as they can, throughout the sprint. If your sprints are short enough, and your stories are as atomic as possible, your devs will never truly implement something so wrong, due to a quick judgement call, that can truly ruin your the product. They must make judgement calls on their own to get the story delivered, this will get features out, allow for interative improvements, and avoid analysis paralysis.

A good rule of thumb is: If you can’t do it in a week (or your sprint’s time span), it is a sign that the story should be smaller. This takes a little convivcing when going over new features or stories with your team, but for us, even if at first it does not seems so, it ends up being the case time after time.

This and Next Sprint Need Only Apply

Another way we have made our planning meetings even more efficient is by asking the team to only address issues in terms of “this sprint” or the “next sprint”, every other situation can wait. People have a tendancy to use planning meetings, their PM tool, and stories to “remember” things that are”needed”. We have found that things that are truly needed are rarely forgotten and adding them to the plan do nothing more then create noise. If the concept or feature will take more than 1 sprint or is something that needs to be done, or done at a later sprint, then create a thread or discussion abut it, but do not take up sprint planning time, or your queue with it.

Asynchronicity and Simplicity

Using sharable threads (for us we use basecamp) for asynchronous conversations helps us hash out discussions, and preserve the sprints for only things that are ready, or close to being ready, for implementation. This helps your team sperate planninng and ideas, from implementation and delivery. A good tip for a synchronouse discussions is to make sure new threads are created for new topics and that the title of the thread is the topic to close and focus on. Again, only after there is a clear concept formulated and ready/need to be implemented in tis or the next sprint, should it be added the icebox or queue.

Planning Meeting Agenda

So how do we set up the agenda for the next sprint so we know what to talk about? We create a sharable doc that devs can add the link to a story they want to delve into, or they want moved from the ice box into the backlog or sprint. Again, only things that need to go into the next sprint are added here. At the sprint planning meeting we go over the sprint we are starting, and maybe a few stories into the backlog, just incase we have a high velocity week, and then links added to the sprint planning doc. This keeps the sprint plannig meeting tight and focused and works very well for short sprints.


We use pivotal tracker and google docs to manage all this, and base camp for discussions and group notifications. I will go more into the use of these tools in subsequent posts.


The main take sways: if it is not for now then it does not exists in the panning world. And discussions together things onto the planning world should be as asynchronous as possible. Finally, completely sperate high goals with systems that are used for accomplishing the next step.