Delivering innovation is at the top of every tech company’s agenda. But they often don’t dare as much as they could because they’re held back by the risk of never-ending R&D, leading to failure or lack of tangible results. But is innovation necessarily unplannable and difficult to deliver? At Hadean we’ve iterated on an approach, Tetromino planning, that demonstrates the opposite: we empowered a team of six incredibly talented engineers to deliver, in less than a year, the first iteration of a groundbreaking OS, three proof-of-concepts of distributed-compute libraries that beat the established ones, and a gaming framework that, at the prototype stage, is already unrivaled on the market. This is remarkable innovation delivered in a highly uncertain context, both from a technical and commercial point of view, and it has all gone through a deliberate process.
Agile and other approaches have proven to be excellent at supporting uncertainties in requirements and user needs. But agile shows its limits when comes to substantial innovation. Our approach leverages the tech instinct of the team: through the exercise of an unorthodox planning, the software engineers are guided to transform their intuitions into tangible outcomes that can be delivered, even in a context where the “knowns” are initially very few. Tetromino planning also allows to estimate and create an actual plan, that looks like a Tetris (hence the name!) and that gets continuously updated to integrate the new “knowns” that emerge while progressing.
Let’s see how this novel approach to delivering innovation works.
The principles behind Tetromino Planning
There are three fundamental principles that this approach is based on: maximise developers’ impact, embrace the developers’ flow, and start from the end.
Let’s start with maximise developers’ impact. As a first approximation, the well known empirical model of the Project Constraint tells us that, given a desired quality of a project, there are three constraints we have to deal with: resources, time, and scope; you can only “impose” two out of three and the third is a result of that.
Given these constraints, which is the one that we want lo leave open for developers to decide upon so that they can have the biggest impact? We could choose resources, which, in software development, mainly means people. But there are substantial limitations on this aspect, especially in early stage companies: talent is in short supply, hiring the right people takes forever, and usually there are board-imposed limitations on budget. Also, do developers want to be involved in this aspect? I would be surprised to hear that!
The second option, time, is the one aspect that developers usually have impact on, in the form of estimation. Given certain functionality that needs to be implemented, how long would it take to implement? This is usually where developers are given the opportunity to impact, with estimation. That’s it. Certainly planning poker and similar techniques have been proven to work but, especially when comes to substantial innovation, is this the most impactful aspect? I believe it’s not. I believe having a substantial say in determining the scope of the work is where developers can be most impactful. Later we’ll show how we’ve enabled this.
The second aspect is to embrace the developers’ natural flow. If you have tried to discuss a high-level innovative objective with software engineers, like delivering an alpha version of a brand-new SDK, you might have struggled to have effective conversations. The number of unknowns are too high, the options you have on the table are too many and trying to break down high level objectives in smaller outcomes seems to be extremely complex. But if you’d ask a more straightforward question, like “what would be stupid not to do?” or “what would you surely need to implement?” — suddenly you get a flood of spot-on answers. So instead of fighting with high-level discussions that are frustrating for both to have, we decided to adapt the exercise of planning embracing the natural developers’ flow: details first! We’ll see later how this translates in practice.
The last element we decided to be important is to be sure that we’d have defined very well the desired outcome, and doing it at the very beginning. This way of operating is inspired by the “Working Backwards from the customer” approach that is widely used at Amazon: their product manager starts by writing a press release announcing the finished product. The press release is targeted at the end customer and contains information about the customer’s problem, how current solutions are failing, and why the new product will address this problem. We found extremely powerful the idea that our software engineers would have written a press-release of their own work, because it would have allowed to have clarity and alignment around the actual problem we’re trying to solve. But it would have also stimulated discussions around how our solutions would look like, because in the press-release we should have presented our solutions. It would have also been the opportunity to see and highlight the value we’d ve provided from the customer point of view.
The combination of working backwards, don’t be too worried about a details-first approach and empowering the team to impact on the scope have been instrumental in our success. Let’s see how these translate in practice.
The planning
There are two main phases: the planning and the actual work (we call it “streams”).
A planning phase might seem anachronistic. Didn’t we move away, with agile, from the whole planning thing? Isn’t it a waste to create roadmaps and spend time discussing what could be done in the future and then realise two weeks in that a lot of things have changed? Maybe. But we found that the exercise of planning is where the value is, not necessarily sticking to it. We use planning as an effective tool, which allows us to go from high level objectives to a tangible set of deliverables that we’re quite confident can be delivered. And in fact we’ve consistently delivered for a whole year.
The input of the planning phase are two clear elements: high-level objectives and a timebox. A high-level objective could be “release an alpha version of the SDK” or “create a proof-of concept of a library for real-time analysis of big data-sets,”. They might sound vague, and they are — intentionally. And even if they’re quite vague, they’re well understood by everyone — especially by the non-tech parts of the company. And remember what we said above about impact of engineers? The fact that the outcome is not precisely specified is what leaves room for that impact. Remember this aspect when you’ll have to deal with the frustration coming from the uncertainties!
The second aspect, the timebox, is also critical. It can be imposed by external deadlines (like a conference you’re attending) or self-imposed, like quarterly OKRs. We found out that a full quarter is the timebox that worked best for us.
Once high-level objectives are defined, the planning then develops as a sequence of four separate steps:
- Outcome definition
- Ideation & ballpark estimation
- “Tetris” planning
- Stakeholders playback
Outcome definition
Defining in details the outcome at the beginning of the process is actually what new engineers joining Hadean find more challenging and potentially frustrating, especially because it’s time consuming (and happens mainly in meetings — ouch). But the purpose of this important phase is to minimize wastage in the scope, in a lean fashion. Doing the outcome definition as a group exercise is where we empower everyone to have a say and we align the team around how we interpret the objective.
We start from the high-level objective and everyone has the chance to propose “what it actually means”. The group is guided by a product person in converging to a shared definition of the outcome that meets the high-level objective. It’s fundamental for a product person to moderate the outcome definition because it’s where the business perspective is more heavily involved. Consider the example we made before, “release an alpha version of the SDK”, it would clarify the expected “install” experience for an alpha version. Also the richness of the debugging experience, and the delivery mechanism. And so on.
You shouldn’t be too restrictive at this stage, we’re in the divergent phase of the process. The aim of this step is to clarify what the end of the journey could look like, not to decide (yet) which aspect will or will not be implemented. At this stage, the outcome shouldn’t contain details of the implementation. That’s the purpose of the next step.
Ideation & ballpark estimation
The ideation step is when everyone is invited to suggest what would be the things to be implemented to achieve the outcome defined by the previous step. The functionalities/work-do-be-done should be expressed in simple bullet points, enough to have a conversation about it but not too detailed to represent a spec ready for implementation. People can contribute asynchronously, in their own time, and you should invite them to “go crazy”, in the sense that there shouldn’t be limitations imposed at this stage, every idea is welcome to be considered. This is the step that our engineers most enjoy, and it’s the expression of our intention to embrace their natural flow: details first!
After the list of things that could be implemented is completed, we ask the engineers to do a ballpark estimation of the time that one-person would take to implement. We decide to limit the option to only 4: half-day, one day, two days, one week. If something would take more than a week it should be further broken down. Remember that this estimation is not something we ask them to commit to, but it’s a way to ballpark estimate the associated effort.
At the end of this phase you have a much clearer picture of what are the options we have on the table to achieve your outcome. You can now start deciding what is worth focusing on.
“Tetris” planning
At this point you’ll have an unorganised “laundry” list of things you could do, together with an idea on how long each of them might take. This is the convergent phase of the process, and the purpose is to decide which things that should and should not be implemented, spot critical dependencies, and group things into coherent chunks of work.
To guide us in deciding which things should be implemented or not we use a technique used in prioritisation, the MoSCoW method. It’s a very simplistic but effective way of bucketing requirements into four categories: Must have, Should have, Could have, and Won’t have (this time). Spotting dependencies can be done in whatever mechanism you’re more familiar with, just be careful to not end up with a sophisticated Gantt chart — it’s way too detailed for what you need. Lastly, the grouping in coherent chunks of work, is done simply using the ability of our brain to group things together — very sophisticated, isn’t it?
Now the fun part, play Tetris and create the actual plan!
Your ingredients are:
- A set of chunks of work of variable length (depending on the actual scope)
- People that could work on them
- A week-by-week table where you can lay out your tetrominoes (i.e. a piece of work done by one or more people)
Your game consist of finding the right combinations of people/chunk-of-works/time-you’ll-dedicate to fit your objectives.
With trial & error you’ll iterate on something that looks like this:
Now the last bit is to define the outcome of each chunk of work. How? Reverse engineering the detailed list of things that came from the ideation phase. Basically what you do here is to ask the question: “what is the actual outcome that we’re getting from implementing the things we said?”. It might seem an absurd process, to go from the high-level outcome, then jump straight to the details and then back up in mid-level outcomes. We’ll see later how this mid-level outcome will be instrumental in the actual-work phase, but we can already observe that, thanks to the way the process is designed, this plan has a few interesting properties:
- It’s the translation in practice of a high-level objective;
- It captures the holistic view of what you’re trying to deliver short term, not just the 2-weeks of the tasks that are usually assigned to individuals;
- It’s minimal, in the sense that it only contains the most important things that are necessary for success;
- It contains all the wisdom, seniority and knowledge of your whole team;
- You are quite confident it can be delivered.
Those properties are the differentiator when comes to substantial innovation, and we’ve demonstrated that they have consistently supported us in making incredible progress despite a context of extreme uncertainty, from both a technical and commercial point of view. Ultimately, if what you are trying to achieve is at least doable on paper, it’s way more likely that is achievable in reality!
Stakeholders playback
Once we’ve agreed on the tetromino plan, it’s time to playback to the stakeholders our result. It should be discussed with all the other departments, so that they can have visibility on what’s likely to come. They can also input on major things you might have forgotten or things that are completely off-track. It might be disappointing to realise that certain things are very far from expectations, but you should be very happy because they’ve been spotted very early on and you have plenty of time to adjust (and almost nothing has been implemented yet!).
It should be more clear now how the tetromino planning allows you to go from a high-level objective to a set of outcomes that you’re very confident can be delivered (and that you will in fact deliver). Before jumping into describing how the actual work is done, it’s important to highlight that the whole planning process we’ve described here should be done in no more than a few days. We usually spread it over three days, with ninety minute meeting for each planning phase plus a few hours of asynchronous work. This should also reassure us that what we are doing is not heavy upfront detailed planning, as in waterfall, but a lightweight group exercise.
Let’s see now how the actual work works.
Actual work, aka “Streams”
When a “tetromino” starts working, i.e. when one of the “chunks of work” enters in the delivery, you have a team that owns an outcome and has a dedicated timebox to achieve it.
The mission of this team is to deliver what represents the most impactful progress towards the direction set by the outcome.
This is potentially what separates our approach from a more strict “definition of done”. With a definition of done, you aim at aligning your team around adherence to user stories (or similar) and “quality fit for the purpose of the product and organization”. The definition of done implies that you accept failures and delays, seeing them as the costs you have to adhere to specific user needs.
We see our outcome more like a “definition of success”. It must empower our developers to see their work as their opportunity to make the success real, rather than simplistically adhere to some specifications. What it means is that we don’t prescribe how the success is achieved. We want to leverage the fact that our developers are the experts, and we trust them. It’s the responsibility of the leadership to make as clear as possible what the success is. It’s the opportunity of the developers to find the smartest way to make it happen.
But what does our development process look like in practice, on a daily basis? Actually, it doesn’t look like very different from a Kanban one. And potentially it’s even more lightweight. This is possible because, again, the developers are free to decide what’s best to achieve the outcome — as long as they’re accountable for that.
We have a very lightweight approach, with outcome refinement at the beginning, a daily standup and a weekly demo.
Outcome refinement
Before writing a single line of code, we run a brief meeting where we do a few simple things. Firstly, we re-state the agreed outcome, it’s important to refresh our memory. Secondly, we refine the outcome itself, adding details and clarifying aspects that might still be unclear. Thirdly, we draft the tasks for the work to be done. Finally, the coding can start!
Daily standup
We have the usual daily standup, with a slight variation. We ask everyone to not tell us the activities they did the day before, but to be explicit on the progress they made. “Yesterday I was in a lot of meetings” is something that doesn’t communicate very much. In terms of expressiveness, it is comparable to “yesterday I was typing all day on a keyboard” when it comes to describing software development. What is of interest is what was decided on, or agreed to, during that meeting. If you struggle to participate in the standup in this way, a way to approach it is to answer the question “what do you know today that you didn’t know yesterday?”. And this should make it easier to let the progress made emerge.
Weekly demo
On Monday morning we have an all-people one hour long meeting where everyone is asked to quickly demo the progress made during the previous week. It can be showing a video of the functionality they implemented, or a live deployment or whatever allows you to show the effect of your work, rather than discussing the activities you did. It’s similar in principles to how we run the daily standup, and it has consistently demonstrated being a great opportunity for the dev team to stay in sync and take pride of the progress made. There are weeks when there’s little to show. In that case, we still ask to walk us through the code being created or modified, taking maybe the opportunity to explain certain decision. But this shouldn’t be the default, it should be a backup in case there’s nothing else to show.
As you can see there’s nothing special about it, but this is possible because there’s an incredible attention and effort put in being sure that everyone is crystal clear of what we’re trying to do as a company. And because we made our engineers accountable for success and then we trust them!
Re-planning
You might have the illusion at this point that, once you’ve planned at the beginning and you start the development, the plan remains untouched throughout the whole period of delivery. The usual connotation associated with a plan is that you actual do it.
As mentioned before, we consider a plan a tool that help us rather something we commit to deliver. So we replan often and, if necessary, we replan everything.
Re-planning can trigger for many reasons:
- New “knowns” emerge. This is the most common case, and it is very welcome! This is where clarity is brought to the table.
- New “unknowns” emerge. This happens when, thanks to prototyping or testing, we actually realise that we know less than what we expected.
- Failure to achieve objectives. This also can happen, it’s well known thing that as good you become at estimating, you’ll always have times when you get it wrong! And that’s absolutely fine.
- Change of objectives. The market can change, the tactical direction of the company can change, the team can change. Anything can change. And objectives might change accordingly.
When one or more of these things happen, a re-planning is triggered. We don’t necessarily go through the whole process from scratch, and not necessarily with everyone. It really depends on the affected part of the planned work. The important thing is to re-plan with all the people affected by the changes you’re discussing and to playback to everyone the result of the replanning once it’s finished.
Don’t aim to minimise changes to the plan, that’s not the purpose of the exercise. You’re actually trying to maximise the assimilation of new information into your plan, and if that means that you have to completely change it, it’s absolutely fine.
We keep track of how the plan changes and it’s interesting to look back when the period is finished. What is fascinating to observe is that usually the actual delivered plan looks completely different than what it looked like at the beginning, but the high-level objective is achieved, and this is what matters when comes to delivering innovation!
How does it evolve
It has been fascinating to guide the iterations of this approach, it’s extremely rewarding to see talented engineers doing exceptional work and making substantial progress in deep-tech complex problems.
We knew that this approach had limitations in how much it could scale and how much it could be effective in a world of more strict customer requirements. Our engineering team is now of twelve developers and we believe this is the biggest size of a team that can work in full coordination with such an approach.
We’re also in the privileged position to have done significant progress in the areas we set ourselves and thanks to that we’ve strong interest and traction on our products. As a result of this we now have more clarity on the details of what our customers are expecting. We also know much more about all the areas of the tech we’re dealing with, thanks to our almost three year long journey.
For these reasons we’ll soon evolve our software development process to something more similar to the six-weeks agile squads, which is proven to work in the phase we’re entering as a company and with the kind of products we’re offering.
But we’ll continue using the tetromino planning whenever we’ll work on an area where fundamental innovation is still to be explored. For example we’ll surely continue working in this way with the team that works on some areas of our operating system, the HadeanOS.
Let me know what you think of our approach, and please share how you’re approaching uncertainty in your own planning.
—
This post was originally published on the Hadean blog