Chapter 6 — From iterations to tangible results: Mission lifecycle
Previous chapter: Societies & Circles: not just another Product and Engineering matrix structure
If you’ve been following our SpaceUP journey, you are now familiar with why we have changed our product and engineering organizational principles. Before the reorganization, like millions of others we were using scrum and its ceremonies to keep ourselves organized. Currently, the concept of Missions are the mechanism how we add the value into the product. Even though we might use different terminology than you are used to, you will see in the following lines that the essence of ideas mentioned in the agile manifesto is in the core of our Missions.
Aligned autonomy
It is always tough to find a balance between autonomy and alignment. Some people even think that too much alignment removes the autonomy, and vice versa. We don’t agree with this, and as stated on a well-known image from Spotify, alignment enables autonomy. Especially, when we talk about companies that want to scale as we do, the holy grail is to find a way to achieve aligned autonomy. To get into this desired state we have defined a couple of stages which every Mission has to go through.
Not everything is a Mission
It may or may not be evident on first sight, but not every development effort has to be a Mission. We use common sense to distinguish between the Ground Crew and the Mission, but basically we follow these simple rules. Something is a Mission if any one of these apply:
- It’s a more significant investment in terms of man-days. We leave it up to one’s judgment but for me it means when something is more extensive than two people for two weeks (= 20 man-days).
- It is a strategic decision about how we do something which deserves a broader discussion and alignment.
- You need focus time to deliver it on schedule, e.g. because it was promised for some release.
- It’s a cross-Spaceport effort which needs to be coordinated.
Mission lifecycle
1. Discovery
The goal of the discovery is to find a product increment which is aligned with our product strategy captured in a Spaceports’ OKRs, and to ensure that risks are tackled upfront rather than at the end. The further you are in the development process, the higher the costs. By risks, we mean value risks (whether customers will buy it), usability risks (whether users can figure out how to use it), and feasibility risks (whether our engineers can build what we need with the time, skills, and technology we have).
How all the things above are tackled is the responsibility of the discovery team which nominates itself from the Ground Crew. The discovery is usually started by the product manager alone but very soon she joins forces with a product designer and a technical lead. This trio forms the core team who ideally flies the Mission once it gets approval. Does the initial team always consist of these three roles? Of course not. It should consist of roles which are needed to tackle and minimize risks mentioned above.
The tools and techniques which the team uses in this phase are quantitative and qualitative user and market research, running a series of very quick experiments with various types of prototypes.
It’s important to say, we don’t plan the discovery work on the Mission Control HQ level (more about the HQ later in this article). By its very nature, it is an activity with uncertain length and outcome and therefore very hard to plan. It is totally okay if the discovery ends up with the resolution that we don’t want to pursue the particular opportunity, which can happen for various reasons. It’s always better (cheaper) to kill something at the beginning before significant investment was put into it.
2. Mission pitch
The Mission pitch is the ultimate outcome of the discovery phase which has a form of a written document reacted collaboratively by the discovery team.
We believe that great communication is key ingredient for building stellar products. If you can’t formulate and capture your ideas in the form which is at the same time simple enough that everyone can digest it and still incudes all the critical parts, there’s a very small chance your ideas will stick and resonate. This is what makes a difference between great and good product leaders.
This sounds scary, but it doesn’t have to be. In Ataccama, we believe that everyone can formulate an idea and should be able to pitch a Mission. We encourage everybody to do so and the Mission pitch is here to help.
The Mission pitch is a structured document (a template) which provides a guide to tackle the most important product questions upfront. It consists of the following three main parts.
Problem When you write the pitch, you have to think about why the particular thing is actually a problem for your users and what is the benefit of solving it. It helps to imagine how the world will change when the mission successfully lands. In other words, what is the desired outcome to pursue.
Solution A conceptual fat-marker sketch to ensure there is a feasible answer for the given problem. What also helps to shape the scope is to think about the paths which we don’t want to take and mark the problems which we don’t want to tackle. We call it Mission boundaries.
Mission needs It represents the expected Mission duration with needed capabilities possessed by the Mission Crew. Rather than giving estimates, we frame the Mission in the form of the investment which which we are willing to spend for solving the problem — we set the appetite. Because every mission is kind of a bet, we defined the maximum length to eight weeks to minimize the risk of a wrongly-shaped Mission.
3. Mission Control HQ
Every Mission pitch is publicly presented to the Mission Control HQ, which consists of all Spaceport Leaders, Society Leaders and the CPTO. Who presents the pitch isn’t formerly defined but usually it is a product manager or future Mission Commander. There’s no need to use a special slide deck, and presenters are rather encouraged to present the authentically written Mission pitch in a concentrated form to ideally make it in the timeframe of five minutes. After all, it should be a pitch, not a meetup talk. The goal is to convince the audience that the problem is significantly large, the thinking is aligned with our product strategy, and there is a feasible solution.
After the pitch is presented, there are three types of possible feedback to receive. First, the Mission is approved and the team may proceed to the next phase. Second, there are still fundamental aspects and key questions to answer to better define the Mission outcome or to minimize the risks. In such cases, the team will work further on the Mission and pitch it again. Third, the pitch is rejected. Most of the time this happens when the targeted problem or the solution isn’t aligned with our strategy. Nevertheless, these discussions are very important for us because they open fruitful conversation which help us to better formulate our overall vision.
Are you asking yourself why do we need such a mechanism when we have autonomous Spaceports with defined objectives? Why can’t we leave it up to them and keep them accountable for fulfilling their goals? Most of the time we can and we do. However, there are moments when Mission Control HQ plays an irreplaceable role. One of them are cross-Spaceport Missions which wouldn’t be possible to coordinate, and the other are requirements to support crucial projects for our customers. In other cases, the HQ just oversees all ongoing Missions and from time to time adjusts the product strategy.
The key purpose of this phase is to ensure the alignment with product objectives, and to provide a transparency through the communication channel to other parts of the company so they know what to expect from the product organization.
4. Assembling Mission Crew
Every Mission is different, needs different skills, capabilities, and even different seniority level. Therefore we establish the Mission Crew for every new Mission. In the past, when we had stable teams it happened that we shaped the work around the team and its skills and capacities. If you think about it, that doesn’t make any sense and it should work vice versa. If there is work for three people for three weeks, why artificially adjust it so it fits in two-week scrum sprints of the team of seven people?
Usually in this phase, we enrich the core team which is typically ready from the discovery phase. This was the team who put together the whole Mission scope and presented it in front of Mission Control HQ during the Mission pitching. We try not to break this trio because during the work on the Mission pitch they have already created the tacit knowledge which is impossible to share and will help them during the flight. One person (astronaut) can’t fly two Missions at the same time. The Mission Crew has to be staffed so they are able to deliver the whole Mission on their own without any other dependencies and waiting times.
The Mission Commander plays a crucial role among the Crew Members as the smooth running of the Mission is their responsibility. They are the one who reports a Mission’s progress to a Spaceport Leader and removes all impediments. The Mission Commander can be anyone from the crew and it depends on the character of the Mission. Most of the time, it is a product manager, but if the mission is rather technical it can be one of the developers, or if it is oriented on improving the user experience, it can even be a designer.
When we put the Mission Crew together we think about the knowledge transfer and the personal growth of individual team members. Developers, designers and the product manager shouldn’t be part of the Mission Crew because some Deus ex machina assigned them there, but because they believe in the Mission’s success and want to contribute to it. Self-motivation and commitment are the cornerstones of Mission success.
5. Pre-flight
A final confirmation before the flight. At this moment, the Mission Crew is finalized and the Mission Commander is known. All of them should now have their full focus on the Mission without any other distractions. You can think of this phase like the Sprint Zero which is still happening on the ground. As we don’t want anyone to die in outer space, this is the last check before lift off. Each member of the Crew has to fully understand the given problem and desired outcome together with the high-level solution, including the architecture. This is a last resort for the team to challenge the Mission scope and the provided resources before they fully commit to a successful delivery.
6. Mission spacetime
Finally, the dedicated time in which the product increment is materialized by the Mission Crew. During this phase, a production code is created. We call it spacetime not only because we like the analogy of a spaceship on the journey. But we also want to create a feeling that astronauts aren’t reachable because they left Earth and we can only contact them from time to time by a walkie-talkie. The only priority of the team in this phase is successful landing. Having an undisturbed time without distractions is one of the ways to help the team achieve it.
In reality, the team is separate from the Spaceport and most of its ceremonies for the duration of the Mission. The Spaceship crew is self-organized and has its own meetings. There isn’t any prescribed methodology and it is up to the Mission Commander whether the team will use Scrum, Kanban, or something completely different.
The only required contact with the Spaceport is during regular check-ins where the Mission Commander informs a Spaceport Leader about the progress. How often the contact happens is up to the Spaceport Leader and Mission Commander to decide. During their periodic conversations they may discover that the Mission isn’t on track for various reasons and that it doesn’t make sense for it to continue. Some Missions can and will crash, and there isn’t any shame in that. It takes courage but it’s always better to stop something sooner than later when there isn’t a chance for the Mission to land successfully.
7. Mission landing sequence
One of the key pillars of the SpaceUP is that each Spaceport is responsible for the end-to-end ownership of components they develop. Each Spaceport owns its part of the product. And the product doesn’t consist just of the code behind the running software but also from the documentation, marketing materials, training materials, demo content, and much more.
Therefore the landing sequence serves two purposes. First, to verify the quality of the delivered outcome — to check whether the technical/design debt is reasonably high so it can be tackled by the Ground Crew. Let’s face it, there is always some debt. Something to consider is whether the debt is low enough for the Ground Crew can manage it, or whether the Mission should be prolonged because defined outcomes or code quality standards haven’t been met. It can’t happen that the feature is merged before the product manager, designer, and technical lead see it. The product manager judges the business perspective, product designer checks or even tests the quality of delivered screens and interactions, and last but not least the technical leader verifies the standard of delivered code.
The second purpose is to ensure that all communication materials were properly created and nothing prevents our consultants or customers from benefiting from a newly developed feature. In the past, we often forgot to provide all needed materials, therefore we created a Mission landing checklist to forestall such situations. Before the spaceship lands on Earth and the Mission Crew declares the mission completed, they have to go through this checklist.
8. Mission decommission
We have a constant desire to improve as people, as professionals, and as a company. And it’s with this same mindset we approach Missions. Before the Mission Crew dissolves to the Ground Crew, there is one last thing they have to do, and that’s to reflect on what we learned during the Mission so each future Mission can be better than the previous one.
The Mission Commander organizes a retrospective, or if you want a post-mortem, to gather honest feedback from the whole crew. Learnings from the retrospective are then shared with the entire Spaceport but also across Spaceports through Circles. These learnings consist of information regarding organizational aspects such as communication, meetings, or various artifacts (e.g. how to improve the Mission pitching template), but also includes lessons learned from the technical solution. Decommission is for both the Missions which landed successfully but also, and maybe more importantly, for the ones that crashed.
The Mission Crew should now stay on Earth as part of the Ground Crew to enjoy some rest as especially the final stage of the Mission can be quite stressful. Moreover, this is another and natural way to spread knowledge about what was happening on the Mission and also how to pay the technical debt which could be created during the flight.
To sum it up
In our case, well-executed Missions help us with:
- Transparency → Things which people are preparing are visible not just within a small team, but for the whole company; it opens good discussions.
- Quality assurance → In the past, sometimes things which went into development weren’t well prepared. The result was features that weren’t useful, usable, nor feasible and very often the development took much more time than expected. In general, the quality of the prepared work has improved.
- Discovery VS. Delivery → Now, there is admitted time for the discovery phase. It’s easier to distinguish which phase of the lifecycle we are in.
- Getting feedback → Everybody is getting better through getting good feedback. This is now naturally happening and it helps us raise the quality bar in general.
- Improved communication → As people need to communicate more and present their work (usually multiple times) we are getting better and better at how we talk about our work, problems, business opportunities, and features.
We tried to be as specific as possible but because we wanted to write just a reasonably long article and not the whole book, we had to omit a lot of details. In some of the following articles we want to also cover what tools we use to capture and track the Missions’ progress, or how we map our objectives to the Missions. Nevertheless, if you missed something or have a question, please contact us and we will be more than happy to provide further information. We are still learning every day and adjusting the whole process to best suit our needs.
