What can we learn about iterative project planning from space travel? [Part 1]

The big question of space travel is how to make it cheap and safe. NASA responded to that call by building their iconic shuttles, but SpaceX took a completely different approach years later. Elon Musk’s company started creating new rockets, equipping them with scalable technologies. The first of those two organizations operated in the traditional model, while the second focused on iterative product development. One of the fundamental differences between the two organizations is their approach to planning. 

Space exploration is considered by many to be one of the greatest achievements of humankind. No wonder since the decision of President Eisenhower in 1958 to establish the National Aeronautics and Space Agency (NASA), each subsequent mission was considered an event of great magnitude. Let us not forget that each successful mission was an important weapon in the propaganda war between the United States and the Soviet Union. 

On the other hand, any failure or setback meant a potential image blow not only for the US but also for NASA. The Agency’s raison d’être has been widely contested, especially after the disasters of Space Shuttle Challenger in 1986 and Space Shuttle Columbia in 2003. In consequence of these terrible losses, NASA started being more and more cautious in setting future goals and both planning and execution phases had been stretched out.  

The history of NASA may represent a story about a traditional organization, perhaps managed using the waterfall method, where planning takes many years, after which the (often staggeringly expensive) rocket or shuttle is built. And, after several years, the spacecraft is ready for flight. Eventually, a clock starts the final countdown. Every instrument and every slightest change in the weather is monitored by a team of experts. 

All necessary tests were performed, and mathematical equations were calculated. The long-awaited moment of takeoff is moving closer. All the previously adopted assumptions and theories will be tested more severely than ever before. There will be no room for mistakes. The whole world is watching. Everything must go perfectly because there is only one chance. 

If, dear reader, you feel the creeps of agitation, know that this is the proper reaction. Perhaps some of the participants of the Apollo 11, or Apollo 13 missions, had similar feelings. This is how the flights into space, managed under waterfall principles, would be conducted. But SpaceX broke this rule.

Elon Musk’s company was the first in the space industry to make rockets iteratively. Currently, the company can build a rocket and launch it within a week. The beginnings, however, were problematic. The first three Falcon 1 missile flights in 2006-2008 were unsuccessful. Still, every subsequent version of the rocket reached further important milestones to achieve the overarching vision: the conquest of Mars. 

What were these particular goals? They were relatively inconspicuous. The rocket was to take off, reach outer space and return to Earth – to a previously marked safe zone and in a coordinated manner so that the rocket itself would be reusable. The next planned stage is a human-crewed flight in a module that can land using its engines. The ultimate goal is to build a rocket that will land on Mars. 

And this approach works. There is no doubt about it. Studies show that the iterative approach proves to be highly successful. Statistically, agile projects have a two times higher chance of success and 1/3 lower probability of failure than projects managed in the waterfall model. If you want to learn more, please click here or here. While agile projects have a greater chance of success, an iterative approach to product development requires a different planning approach than the one used by traditional organizations like NASA. 

The iterative approach works not only in the space industry but also in building more down-to-earth products. That’s where experts at Hobly come in. We prepared advice and suggestions on how to plan effectively with the iterative, agile approach. 

1. Don’t be afraid to make mistakes

Failure is, in a sense, inherent in every action. Unless you’re sending NASA shuttles into space. Then a failed flight costs not only tens of millions of dollars but can also cost lives. In this case, you would probably prefer to cross the word “failure” out of your dictionary. Well, we have bad news for you. As mentioned above, projects managed with the waterfall method fail more often than they succeed. But all is not lost.

Failures will happen, but we can approach them the way SpaceX approaches space flights – let’s make them cheap and safe. That’s what iterative product development and focusing on planning relatively small increments is for. Each mistake can be treated as an opportunity to draw valuable lessons for the future. Thanks to this, each subsequent element of the product, whether it’s a piece of code or a space rocket module, is better. 

How does it work in practice? Imagine a product development timeline. This hypothetical product will reach the next stages of its life cycle and develop new essential items from the Product Backlog. During this time, the team working on every next increment will become more mature thanks to inspection and adaptation. 

The team members will know how to manage their work more efficiently and effectively. They will become savvier with the technology they use and more aware of the possibilities and constraints that their tools bring. They will gain more and more knowledge about the product and the exact direction in which its development should proceed.

In the early stages of a product’s lifecycle, the risk of failure is the greatest, but (at least in agile methodologies) the cost of failure is minimal. Subsequent sprints supplement the missing knowledge and cause the team to develop, so the risk is being reduced in time, although we must consider that the cost of failure becomes greater. This relationship is well illustrated by the situation in which SpaceX in March 2020, launched a rocket with two astronauts on board. The cost of failure was very high. However, the mission was successful also thanks to tests, numerous trials, and a series of previous increments that the company had made in the past.

2. Use checklists whenever you can

Before you start planning a sprint, it’s a good idea to make a checklist of things needed to create a plan for developing the increment. Specific points on such a checklist will vary depending on the specifics of the team and product, but many points are considered necessary regardless of these variables. The most important questions every team needs to put a check-mark next to are:

• Is there a Product Owner designated and available?
• Do we have a team?
• Is the Product Backlog prepared before the planning session?

The lack of a prepared Product Backlog is a considerable obstacle more often than you might think. We know situations where the team thinks they are ready to plan while the tasks are unprepared. It’s worth taking the time to specify and define at least the tasks that are at the top of the backlog.

Checklists can also help us at lower levels of complexity. In fact, the last point of our sample checklist can (and should) be broken down into a separate set of sub-points. That’s when the Definition of Ready may come in handy. DoR is nothing more than a list of conditions that must be met for a particular task to be taken into account when planning. These conditions will vary for each product, and each team should agree to its list. However, many such conditions repeat themselves from one product to another. The most common elements of the Definition of Ready include:

• The task should be properly described.
• The task should be estimated.
• The client should be defined.
• A high-level description of how this task will be demonstrated at the sprint demo should be provided.

Checklists can help to standardize every aspect of work. For it to happen, they must be visible. How to achieve that? Some teams write a checklist for each task separately in Jira. This is a good practice because every developer understands and has easy access to exactly what the Definition of Done requires. 

Sometimes the list includes standards for how software is developed, such as the number of unit tests or peer code reviews. Sometimes necessary conditions may be hardcoded into the software in such a way that it’s impossible to proceed with the work without making sure that the previous steps have been taken care of.

If you have decided to create a checklist, it may be a good idea to do it with the help of your team. This way, each point is well understood, and the team members identify with it, knowing why any particular point was put on the list in the first place. A good rule of thumb when creating a checklist is that no point should be redundant.

3. The first sprint is still a sprint

Before starting work, your team should determine the duration of the sprint, the dates of the events, and the rules for working with the Product Backlog. Not all rules can be defined before the sprint starts. Only during its duration may we establish some essential details on how to organize work effectively. The first sprint is quite specific in that the potential complexity and ambiguity are often the greatest. 

What should the team do? The usual: stay calm and produce the first increment. The first sprint is not, and should not be, treated as a kind of anomaly that does not fit into the framework. It is not an opportunity to start a team that will produce something of business value only in the next sprint. When used, the “sprint zero” is rarely aimed at exercising empiricism or testing any important assumptions for the product. In other words: it’s just wasteful.   

We now hear about the “sprint zero” only in the context of things that should be avoided in Scrum. And rightly so. It’s a good idea to iterate right from the start to check hypotheses and assumptions regularly, which leads to smoother work on future iterations. 

By resigning from the “sprint zero,” we use a clear and consistent framework while inspecting and adapting. The assumption for the “sprint zero” would be: “we have to prepare to be ready.” Iteration and empiricism are pretty different. It’s about improving our work as we go, rather than improving our assumptions for work that hasn’t even happened yet.

Looking for more lessons? 

Be sure to check out the second part of our article.