We’re all looking to move faster, but when the direction we’re moving in is unclear, it’s important we come up for air frequently. Here are some practices to adopt and to avoid when operating in a complex environment.
Mastery at a startup is understanding how to make good decisions with incomplete information. I wrote in a previous post about complex (uncertain) environments and how we need to “Do -> Reflect -> Plan” more than “Analyze -> Plan -> Do”. This post will make the case that you are probably planning too much, executing too many things simultaneously and trying to optimize for speed, when you really should be optimizing for direction.
Imagine the game Marco Polo many of us played as kids.
If you’re “it”, or “the den”, then you have to keep your eyes closed and call out “Marco” and everyone else yells “Polo” in response. You then swim off in their direction. Naturally they scatter away from you, so you pop your head up again and say “Marco” and re-calibrate.
This is how agile teams should be operating. Probing – Sensing – Responding
But when things are moving slowly, it’s actually quite common for teams to go the opposite direction. They seek to have greater control by spending more time in planning. They will develop a six month roadmap, break it down into epics and stories (if we’re lucky) and then into tasks and have engineers estimate and analyze each task and only then will the boss sign off on it and we start development.
This is like saying “Marco” once, and then spending five minutes planning your assault, putting on flippers, stretching your shoulders and spinning off in whatever direction you planned for another three minutes. It’s great if you’re swimming in a race (complicated environment), it’s terrible if you’re playing Marco Polo (complex environment).
Why does this happen? Why do we cling to detailed requirements when things are out of control? It’s often because we think it’s more efficient to break up work. But work which is broken up needs to come back together, and in the real world, this is messy. So how do we keep the big picture in mind while executing on a small testable piece?
Encourage questions, don’t hand out requirements
One of the greatest dangers a team can face is trying to divvy up work and losing the context and purpose of the work in doing so.
We saw in the previous post that operating in a complex environment with many unknowns requires us to be wrong frequently. As frequently as possible. To do that requires that we release something of value on a regular basis, while keeping the big picture in mind. That is what is known as a “vertical slice”.
As you can see, the items on the left are all things which change a user’s experience. They will allow us to learn something if we release them. The ones on the right are just building blocks which eventually will create something on the left. So while it might be more efficient to create a perfect architecture and perfect designs, etc and then assemble them at the end, this is like the swimmer speeding off into the edge of the pool – it might be the wrong direction and we’ve just wasted a lot of time.
Henrik Kniberg made this popular illustration to demonstrate the case for vertical slices. His article is far more articulate and well illustrated than mine, but in case you don’t read it, here’s the gist:
- The first team is faster (only four iterations instead of five), the second team had a happier customer
- The customer wants transport, not necessarily a car.
- They got transport the entire time with the 2nd team
- They also love the feeling of wind in their hair, but the team in the first row didn’t realize that
This example is also ridiculously simple, because in reality, the first row often goes much much worse than this. Oftentimes the people building the wheels have no idea it is even going into a car.
Achieving the 2nd team’s methodology comes from a combination of factors:
- Read about user stories and write meaningful ones, but don’t just write them, tell them.
- Don’t be afraid to release something you know won’t scale.
- Investing in automated testing or you can’t keep turning skateboards into bikes or whipping out MVPs.
- Give your team the story and access to the customer, not the “requirements”
If you do this, you can be wrong quickly, learn from your customer and iterate. Software (when automatically tested) is bendable and re-writable. More so than people.
You can’t iterate yourself to greatness (but you can avoid disaster)
One common objection I hear is that iterative development just means crappy MVPs we throw out. And it is fair given all the agile snake-oil selling that is creating mindless feature factories.
What is important to remember here is that iteration ≠ software development. There are many ways to discover what users want which are cheaper than software and its corresponding AWS, Facebook and Google Ads bills.
For instance, at Grofers we had a project to try and encourage people in housing societies to buy together and save money.
The final released product can be seen above, but the initial release? The skateboard?
The Scrum team (including a developer) went and set up a pani puri stall at an apartment complex and had people show their phones to prove they had ordered. MARCO!
We discovered that people were much more interested in competing with their neighbors for “top orderer this month” than collaborating with them for group discounts. POLO!
But even when it is software – it’s crucially important that we don’t just push out half baked ideas that the CEO had on their last trip to the bar. Even the iteration has to be leading up to something we had planned.
A useful technique to address this is having a “Planning Horizon”
Planning horizons
A planning horizon is a fancy term for having a sketchy long term plan, a likely medium term plan and a certain short term plan. Think of it as staring off into the horizon. The tree in front of you is very clear and you can count every leaf, the forest off in the distance looks like pine and maple and the mountain on the horizon seems to have sparse vegetation.
To make this a little more concrete, Roman Pichler uses the following terms (with some Dr. Evil examples added by me):
Freaking Lasers is a tactic – short term. It’s a vertical slice, it has an impact (we hope), and it ties into a backlog item (Sharks) that ties into a Roadmap item (Defend against Austin Powers) that supports our strategy.
The time periods in brackets signifies how long each item should be valid for but it does not signify how long it is locked in for. Nothing is locked in when we’re in a complex situation and trying to learn fast. If we have new information, we update each of these. How frequently? Pichler suggests the following:
A fantastic tool for doing this are user story maps. User story maps are, at their simplest, a way to get everyone on the same page and to get real about your backlog from the perspective of your users and their experience. They are a way of expressing your backlog not just in things to do, but also in how your work will impact users or your P&L. Using them correctly will reduce waste and align the team more closely to the customers they are serving.
Here’s a story map I recently created for a basic expense reporting tool.
Jeff Patton, a renowned expert on product management and user experience who spent his early career as product leader for Salesforce Commerce Cloud, writes extensively about user story maps. You can read an early post on this on his blog.
Summary
We’re all looking to move faster, but when the direction we’re moving in is unclear, it’s important we come up for air frequently.
Here are some practices to adopt and to avoid when operating in a complex environment:
Avoid:
- Building components and trying to assemble later
- Engaging in wasteful long-term planning
- “Giving” requirements to the team
Better Practices:
- Plan and release in vertical slices
- Having a planning horizon. Keep adjusting
- User story maps are great for this
