From synchronous planning to Hammock Driven Development

I was first introduced to Hammock Driven Development several years ago, watching Rich Hickey’s talk. The idea stuck with me ever since.

Sprint Planning Two ¶

Before getting into hammock driven development, let me first recap how teams use Scrum nowadays to develop software.

In Scrum, development happens in sprints iterations. Companies usually have iterations that last two weeks, but they could last anywhere from a couple of days to several weeks.

A typical iteration starts with a sprint planning meeting, where the engineering team commits to user stories presented by a product owner. A user story is a description of a feature told from the perspective of the person who desires the new capability - typically a user or a customer of the system.

The format of a user story is something like: <User> wants to <goal>, so that <reason>.

After the sprint planning meeting one, the engineering team continues with planning meeting two. In this meeting, the team tries to come up with a solution concept for each committed user story. The level of detail can vary a lot. The goal of this meeting is to have a clear enough concept and to have some concrete first steps to start with. After this meeting, everyone in the team should have a clear enough idea on how to start working on the implementation

The sprint planning meeting takes several hours.

The Benefits Of Sprint Planning Two ¶

• It leads to a quick result.
• It enables a high degree of knowledge sharing and synchronization among the engineering team.
• It often addresses questions that could come up during the implementation, avoiding interruptions later on.

The Downside Of Sprint Planning Two ¶

• Puts people in a box. Once the team decides on an approach, the team members become reluctant to reconsider, even if it turns out that their initial plan had major flaws. Instead of revisiting a design, people resort to hacks.
• No plan survives contact with the enemy. When the team spends an hour or two per user story, the chance that they missed critical points is high.
• Ignores how our brain works. Trying to come up with a system design within a couple of hours ignores all insights learned from neuroscience. More on this further below.
• Leads to not-invented-here syndrome (NIH). There is no time slot to do research on how other people solved similar problems. This typically means the team will go with the best idea they could come up with within the time slot allocated for sprint planning two.

Hammock Driven Development ¶

The core idea of Hammock Driven Development is to better utilize how our brain works. Rich Hickey in his talk differentiates between the waking mind and the background mind. Stating that the waking mind is good at linear thinking and analysis. The background mind is good at forming connections and holistic thinking.

How do you utilize this?

State and understand the Problem ¶

Before you can solve a problem, you need to understand it. This sounds obvious, but too often people move ahead, thinking they understand the problem well enough.

Say it out loud and write it down. Think about what you know. Write it down. Think about what you don’t know. Write it down.

Get a lot of input ¶

Look for related problems. Look into their solutions. Study them and be critical about them. What is good about the solutions and what is bad? Which trade offs were made? Take notes. Write down questions. Lots of them - you should have them. If you don’t have any questions, you may be missing something.

This is an exploration phase. You want to create work for your background mind. The background mind should form connections and you can’t connect what you don’t know.

Get into a Hammock ¶

After consuming a lot of information you should analyse and recall it. Get into a Hammock, close your eyes and think about what you learned so far. How can it be used to solve your problem? This step is important. You want to shut out new inputs and recall what you’ve learned.

Sleep ¶

The previous steps should have made the problem you are working on important enough to be on the agenda for your background mind. During sleep your brain keeps working and once you wake up you should reevaluate your problem to check if you got any new insights.

If you didn’t have any ideas you can either try to go back to absorbing more information, to actively think about the problem again. Or you can talk to other people. Share the problem statement with them, tell them what you know. Talk through the solutions you had considered.

Repeat the process if necessary. Sometimes you may feel stuck or be in a state of analysis paralysis. In that case there are several options:

• Try to implement your best idea so far. You will likely learn something new along the way.
• Talk to colleagues about it.
• Switch to another problem. But only do this once or twice a week, not several times a day. This may cause you to wake up with a solution to a different problem than the one you want to solve. That’s okay. Capture the solution by writing it down, or, if your schedule allows it, implement it.

Wrap up ¶

Depending on deadlines and the difficulty of the problem it can take weeks or months to come up with truly novel solutions. You may not have the luxury to take this time. But the least you can do is to sleep a single night over a problem before making a decision.

There is a big difference between a design that a team cooked up within one or two hours and a design that a team or an individual iterated on for a longer period. The difference may not always matter, but often it does. Still, you have to know when to stop looking for an even better solution. Development is an iterative process, fixing design issues earlier is cheaper than fixing them late, but no amount of planning will account for everything. Perfect is the enemy of good enough.

Appendix ¶

Does this lead to over engineering?

For me, no. When I take more time on a design it is to reduce the complexity. To find a simple solution. Sure, you can use the time to think of all possible edge-cases and imagine every possible future use-case and then implement a solution that takes care of all that and more. But part of the process should be to understand the problem, and then to solve that one problem, not dozen others. The goal is to come up with a design where the common cases and the edge cases are the same thing. A simple design.