Working notes on Velocity
7 min readApr 20, 2024
Moving fast is one of the most important things I’ve learnt over the last few years. Here’s everything I’ve learnt about the ambiguous nature of software, delivering challenging projects on tight timelines, and improving internal processes. These are first principles I’ve come to rely on.
Intro
Enough is written about why velocity is important for every team. Velocity increases throughput of the company.
- Project Management is the skill that unlockes velocity. It is often percieved as a bureaucratic role tasked with cracking the whip on people. This is furthest from the truth and importance of the skill.
- My experience is that it’s an everyday, every moment ability to prioritise, sequence and focus towards an objective. It is a intensely creative exercise to reach objectives faster than thought possible, at a quality higher than thought possible in overconstrained situations.
- It’s most effective when combined well with skills of quality and leadership. When not combined, it leads to sub-optimal trade-offs and cutting corners. Notice that people at the cutting edge of craft, tend to also be really good at velocity — either conciously or sub-conciously.
If in doubt about the importance of velocity, read:
Work is always is abstract and incomplete
It took me a while to realise these simple but powerful characteristics of software. Knowing them makes a lot of the suggestions that follow very self-explanatory.
- Software is fundamentally abstract. None of the representations like a PRD or a Figma file meaningfully capture the overall system complexity. That’s why software is impossible to scope accurately at the time of kick-off.
- Software can be easily changed even after customers have bought it. The best companies change it hundreds of times a day without us knowing. This capability is severly underappreciated and ignored by most teams.
- The implication is that teams creating software are always working with incomplete information, evolving ideas, and inefficient systems.
- So creating software is unlike playing chess or tennis where rules of play and start and finish are clear. It’s more like writing a book or making a movie where you’re making up the rules as you go and you decide when you hit publish. And move on to the next iteration.
Listen to Sidu and Jack talk about the abstractness of creative challenges below and read range to understand how people have gotten really good at other ambiguous disciplines:
Only 1/3rd time for deep work
The makers in us want to be spending most of our time building. It makes sense in contexts where the requirements are clear and complete. Software isn’t that.
- Scope clarity comes mostly from testing software — both with users and during QA. Requirements change significantly from the first draft to the shipped product. It stems from the abstract nature of software.
- Instead of trying to scope better at kickoff, it’s infinitely more helpful to accelerate time to tests. With the increased clarity in scope reprioritise tasks, execute, test, and repeat the next day.
- Accelerating time to tests means decrease in the deep-work time. In Mythical Man Month, Brooks contests that only 1/4th of a day should go into building. 1/4th should go into planning the newly discovered scope. And 1/2 into the various tests, reviews and communications.
- A new rule of thumb I use is — to spend a third of each day on planning, building and testing. Planning includes weekly iteration meetings, capturing and clarifying user stories. Testing includes design reviews, and user tests.
Discovery — Delivery cycle
All creative work goes through two distinct phases. Finding clarity on what to build (Discovery) and then building it (Delivery). Software is the same.
- The phases involve very different kinds of work. The nature of time and communication involved is very different — with direct implications on staffing, sequencing, and nature of decision making in each phase.
- Discovery involves determining key objecives, features and their relationships. It’s high ambiguity — and high communication task. Few expert minds working on it ensures system integrity and simplicity.
- More than 3–4 people during discovery rapidly increases communication needed to ensure alignment. People spend more time communicating than building. The project will never complete this way.
- When done well, Discovery will identify the key components and their relationships early and often. This becomes the starting point for delivery teams to figure out how to bring it to life.
- Delivery phase ends not with creating the builds but when testing is complete internally and with users. The testing is the hardest habit to build, but also the one that is most clear and revealing.
Accelerate cycle time
Cycle time is the heartbeat of a system. It creates momentum. Most teams settle at weekly or monthly cycle time. Anything slower would be too slow to survive. The best teams put in the effort to accelerate cycle time.
- The ineffective way to increase cycle time is to increase pressure and intensity. The effective way is to build the ability to shift gears quickly at the right time.
- Shifting between Discovery and delivery phases aren’t applicable only at a project level. Discover and prioritise everyday. Deliver, test and review everyday. Rinse and repeat.
- Shifiting between Discovery and delivery needn’t be sequential. Delivery teams can be working on PoCs and research spikes as soon as broad strokes start to come in from Discovery teams.
- Shifting to the right level of detail or fidelity quickly is incredebly powerful. Fidelity is the amount of detail in the solutioning. Ex. When writing a PRD, a low fidelity of flow chart or wireframe suffices. When building the narrative, a higher fidelity of well written copy and a prototype is helpful. But building screens at the time of writing PRDs is too high of a fidelity for a PRD.
- Laser-like focus helps shift quickly and at the right time. It’s the ability to put aside something, that with every bone in your body you think is a phenomenal idea. You put it aside because you’re prioritising something else.
- In time you will see that no matter how ambiguous the situation and how fast you’re moving, it’s possible to move 10x faster. Just lean towards ambigiuty, Identify what information is missing, creatively and rapidly find that information in 1/10th the time. And switch to delivery mode.
Identify stories, iterations, and releases
It’s always helpful to have a simple and effective process to enable velocity. Agile Methodology is built for it. The gist is:
- Stories are the atomic units. A story typically corresponds to a flow in the product that cannot be broken down further into meaningful pieces. A project or a feature should be broken into stories at the time of kick-off.
- Iterations are a collection of stories to be completed in a week.
- Releases define the feature-set that needs to be pushed to production for the feature to make sense. Make Release 1 the thinnest slice of a feature that can be shipped. Release 2 adds fixes and additional functionality, etc.
- As stories go through the cylces of discovery and delivery, clarity on each story will improve, and more stories will surface. Update the stories, story points in the iteration everytime new information comes up.
- As you settle into this system, you will start to see your estimations get better, piroritisation and scoping get better, and overall velocity and time to market go up!
Start today
- Identify the stories in your current feature. Tag them based on size and complexity into 1, 3 or 5 points. Aim for the stories to add up to 20 points of work per week per person. Update stories through the week and see how many you’re able to complete.
- Plan and review project iterations on Mondays every week. For tasks, plan and review daily. You’re going to make mistakes and be confused and be frustrated for a couple of weeks. That’s alright. Keep at it.
- A note on deadlines — be careful with throwing around this word. A deadline means if we don’t hit it, we pack up and go home. Very few situations are so. Most are good to have timelines based on severly incomplete information.
