.png)
In partnership with
Substantial innovation is the secret sauce of successful tech companies.
But leading the delivery of innovation is often a disheartening experience: deadline slippages, disappointing the board, changes in direction, frustrated engineers, and a lack of tangible progress that leaves prospective customers in the void. Does it have to be this way?
Tetromino planning, a novel approach to plan-and-deliver innovation, has shown that a different approach is possible. At Hadean, for example, in less than 18 months we built a technology stack from scratch that has beaten the world record of the number of concurrent users interacting in real-time.
Through the exercise of unorthodox planning, the software engineers can be guided to transform their intuitions into tangible outcomes that will be delivered – even in a context where the ‘knowns’ are initially very little. Let’s see how I uncovered this approach.
Put your engineers’ voices front and center
When looking at how we could maximize developers’ impact, we went back to the basics. The well-known empirical model of the project constraint tells us that, out of the constraints of resources, time, and scope, you can only ‘impose’ two out of three, and the third is a result of that. We then asked ourselves, which ones are the most relevant to engineers?
Resources seem not to be the best candidate: they’re often externally imposed and engineers rarely care about this aspect. It’s not their core expertise – they love technology after all! The second constraint, time, is what engineers have the unquestionable say on in Agile: estimations. Surely having engineers forecasting the time is important for predictability, but it often involves engineers too late in the process – when the requirements have been established by someone else. Is playing Planning Poker the most impactful thing engineers can contribute to when it comes to innovation? We felt that engineers having a fundamental say in scope is what could have made the difference.
We also often found ourselves ineffective when trying to break down high-level objectives into smaller outcomes as a team. For example, what are the mid-level outcomes of the generic ‘alpha version of a brand-new SDK’? The number of unknowns is too high and the options you have on the table are just too many. So we questioned ourselves, is there a way to remove friction and frustrations, and embrace the engineers’ natural flow? We observed that more specific questions like ‘What would be stupid not to do?’ and ‘What would you surely need to implement?’ were getting a flood of spot-on answers with highly valuable insights into potential solutions. So instead of fighting with high-level discussions that are frustrating for both to have, we decided to adapt the exercise of planning and embrace the developers’ natural flow: details first!
Planning, not plans
Due to the success of Agile, we have increasingly associated negative connotations with plans. Potentially optimizing the work to stick to a plan seems like an anachronistic waterfall approach (and it is). But what about the exercise of the planning? Can planning be made into a lightweight tool to help the team express their best ideas, and come up with a set of deliverables that you’re confident can be delivered in a specific timeframe?
We approached planning with the two aspects guiding us: maximize developers’ impact and embrace the engineers’ natural flow.
We started planning with a very high-level outcome and a timebox. For example, a high-level outcome could be ‘create a proof-of-concept of a library for real-time analysis of big data-sets’; ‘release an alpha version of the SDK’; or it could be a quarterly OKR set for your team. We also had a timebox in mind, and we found out that a full quarter was a timebox that worked best for us.
We then aligned on a shared definition of the outcome that met the high-level objective. This outcome definition was done as a group exercise, in order to empower everyone to have a say. It was guided by a product person who helped the group (through the lens of a business perspective) to align on what the high-level objective meant in practice. Considering the example we made before, ‘release an alpha version of the SDK’, this step would help to clarify the expected ‘install’ experience for an alpha version. Also the richness of the debugging experience, the delivery mechanism, and so on.
The next step was where we embraced the engineers’ natural flow and we gave the opportunity for them to have impact. Instead of doing some more traditional planning, we let engineers jump straight into discussing what they love, and the minute details of the ideas that could be implemented to achieve the defined outcome. We call this the ideation step. This generates the list of potential solutions very quickly. We then asked the engineers to do a ballpark estimation.
What you end up with is an unorganized ‘laundry’ list of things you could do with an idea of how long each of them might take.
Reverse engineer the team’s wisdom
We wrap up the planning exercise with what I consider to be the game-changing aspect of this approach: from this unorganized set of items, you prioritize and reverse-engineer the thinking of your team. This produces a plan, with parallel streams of work and deliverables. Every deliverable has a precise outcome, a duration based on estimations (in weeks) and people that will work on it. A plan that has the shape of a Tetris (hence the Tetromino name!)
|
|
|
||
|
|
|
|
|
|
|
|||
|
|
|||
|
|
|||
|
|
|||
To get to this final plan, we first prioritized the items with the Product team, using a MoSCoW method. We kept the constraint of the total time and people available in order to be sure we excluded things that wouldn’t move the needle.
We then regrouped things so they became coherent batches of work. Each piece of work had a precise outcome that was defined by working backwards from the implementation details. Lastly, we captured the dependencies and sequenced the pieces of work according to them.
All of this might seem like an absurd process: going from the high-level outcome, then jumping straight to the details, and back up to mid-level outcomes. What we observed, though, is that thanks to the way the process was designed, this plan had 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 two weeks of 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.
Play it back and keep it short
One thing we noticed is that the plan, in this simple form, could be easily played back to the rest of the business. This was good for helping us spot things very early in the process that were either completely off-track, or had major elements missing. In those cases, we had to re-do part of the planning exercise. But the beauty of this is that we were preventing failures down the line because nothing was implemented yet!
And another very important thing was that we were trying very hard to keep the whole planning exercise very short. For a quarter’s worth of work, we usually spread the planning exercise over three days, with a 1.5hr meeting for each planning phase, plus a few hours of asynchronous work. This also reassured us that what we were doing was not heavy, upfront, and detailed like in a waterfall, but a lightweight group exercise!
Plans are useless, but planning is indispensable
You might have the illusion at this point that, once you’ve planned at the beginning and started the development, the plan remains untouched throughout the whole period of delivery. The usual connotation associated with a plan is that you actually do it.
This is not what we wanted from the planning exercise!
We worked hard to consider that the plan could be a tool to help us rather than something we committed to delivering. So we replanned often and, if necessary, we replanned everything.
Re-planning could be triggered for many reasons, including the following:
- New ‘knowns’ emerge. This was the most common, and was extremely welcome! This is where clarity was brought to the table.
- New ‘unknowns’ emerge. This happened when, thanks to prototyping or testing, we realized that we knew less than what we expected.
- Failure on achieving objectives. This also could happen; it’s a well-known thing that as much as you can become good at estimating, you’ll always have times when you get it wrong! And that’s absolutely fine.
- Change in the context. The market can change, the tactical direction of the company can change, the team can change. Anything can change.
When one or more of these things happened, a re-planning was triggered. We didn’t necessarily go through the whole process from scratch, and not necessarily with everyone. But we tried our best to not minimize the changes in the plan as it’s not the purpose of the exercise. We were actually trying to maximize the number of new information we brought into our plan. So if that meant we had to completely change it, that was absolutely fine!
We kept track of how the plan changed over time, and it was interesting to look back when the period was finished. What was fascinating to observe was that usually the delivered plan looked completely different from what it looked like in the beginning.
But what is important is that the high-level objective was usually achieved, despite the actual journey being different from what we originally planned.
And this is what matters when it comes to delivering substantial innovation.
.png)
.png)
.png)
.png)
.png)
.png)
.png)
 (1).png)
.jpg)
