Over my 7 years of experience in Product, I have managed to be predictable only for the last 8 months. This article shed some light on how.
What is predictability?
As in every company, my team and I are asked to be predictable.
At a certain point in time, we have to say what we plan to do over a certain period of time.
Once the time period is over, we have to review if we did what we said.
👆 This is the definition of predictability.
🙋 Why do we need to be predictable in the first place?
For many different reasons!
It's very difficult for a company to believe in an idea if you cannot put a price tag next to it.
An unpredictable team will get stuck on dependencies with others.
The execution will be sub-optimal, for the team, but also for everyone that will be affected by the dependencies.
An unpredictable team may be working on the wrong thing.
A "Quick win" that a team prioritized now could very easily become a "Very long fail" if the team failed to see some UX or technical challenges.
An unpredictable team may "sprint" at the end of a period to finish things over.
It may neglect quality to "check" some arbitrary boxes.
I used the word "sprint" on purpose.
People should never sprint. Stories, tasks, things (call it however you want) should sprint.
At a certain point in time, we have to say what we plan to do over a certain period of time.
Once the time period is over, we have to review if we did what we said.
👆 This is the definition of predictability.
🙋 Why do we need to be predictable in the first place?
For many different reasons!
It's very difficult for a company to believe in an idea if you cannot put a price tag next to it.
An unpredictable team will get stuck on dependencies with others.
The execution will be sub-optimal, for the team, but also for everyone that will be affected by the dependencies.
An unpredictable team may be working on the wrong thing.
A "Quick win" that a team prioritized now could very easily become a "Very long fail" if the team failed to see some UX or technical challenges.
An unpredictable team may "sprint" at the end of a period to finish things over.
It may neglect quality to "check" some arbitrary boxes.
I used the word "sprint" on purpose.
People should never sprint. Stories, tasks, things (call it however you want) should sprint.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- 💬 Agile Principle #8
🙋 Can we become 100% predictable?
I don't think so. Estimation is an art.
The only way to estimate some work with 100% accuracy & 100% confidence is to do it.
This means that any estimation methods lies between these two (useless) extremes:
- Estimation cost 0 & accuracy 0% (For example: "give me your task I'll size it randomly")
- Estimation cost = implementation cost & accuracy 100% ("give me your task, I'll do it and tell you afterward how much it took me")
Any other method will introduce risks and bias.
It's a balance between the effort it will take to estimate and the accuracy of the estimation.
Predictability at Ricardo
💡 Note: At Ricardo, we like to revise iteratively our processes in order to continuously improve the way we work, so this article is not the definitive guide of how to be predictable. It is where we are, as a company, on our predictability journey.
⭐️ We believe that a common lightweight framework is required to align at the company level.
Similarly to many other companies, we do not believe in ready-to-use frameworks built by others that have to be adapted to our way of working (SAFe among others).
We believe that following the agile principles and creating something of our own is far more efficient.
At the company level, we plan work in chunks of 6 weeks that we call a cycle.
The 6-week planning chunk is becoming the norm for more and more companies, I will quote Basecamp:
⭐️ We believe that a common lightweight framework is required to align at the company level.
Similarly to many other companies, we do not believe in ready-to-use frameworks built by others that have to be adapted to our way of working (SAFe among others).
We believe that following the agile principles and creating something of our own is far more efficient.
At the company level, we plan work in chunks of 6 weeks that we call a cycle.
The 6-week planning chunk is becoming the norm for more and more companies, I will quote Basecamp:
We wanted a cycle that would be long enough to finish a whole project, start to end. At the same time, cycles need to be short enough to see the end from the beginning. People need to feel the deadline looming in order to make trade-offs. If the deadline is too distant and abstract at the start, teams will naturally wander and use time inefficiently until the deadline starts to get closer and feel real.
After years of experimentation we arrived at six weeks. Six weeks is long enough to finish something meaningful and still short enough to see the end from the beginning.
- 💬 Shape-Up
This article is going to be mainly focused on how we plan a cycle as a company... but first, let's quickly review how we operate inside a cycle :
⭐️ We believe that teams should have the freedom to adapt their process:
Each team is free to organize the work the way they want within a cycle.
This is self-management at its finest.
This is self-management at its finest.
Scrum Teams are [...] self-managing, meaning they internally decide who does what, when, and how.
- 💬 Scrum Guide
Some teams are doing 6 sprints of 1 week, others are doing 3 sprints of 2 weeks, others are using Kanban.
Each member of the company is invited to a single demo event, every week.
Each team chooses if they want to show something they shipped or learned, or if they pass their turn.
That's it.
It is as lightweight as it gets.
Each member of the company is invited to a single demo event, every week.
Each team chooses if they want to show something they shipped or learned, or if they pass their turn.
That's it.
It is as lightweight as it gets.
The Festival
In between two cycles, we have a 2-day event that we call a Festival ("We rock" was one of our internal slogans when we started the festivals and the name stayed 😊)
Our Festival main goal is to commit on the best possible plan to execute, as a company, for the next 6 weeks. It's an alignment exercise where, as a team, we build and share our plan to move our business forward.
- 💬 Dimitri Kandassamy - Head of Delivery
The main goal of the Festival is surfacing all the possible dependencies and connections between all the departments and align employees to pursue all together the main goal of the company, precisely, directly and delivering it with high quality standards.
- 💬 Mirko Brambilla - Engineering Manager and Agile Lead
A Festival is always composed of the same parts, in the same order
- ✨ Demo
- 🎤 Pitch
- 🍷 Speed Dating
- 🗺 Planning
- 🎯 Final Presentation
🎶 ACT 1: The show must go on
The ✨ Demo is built like a show.
Each team goes on stage and has 10 minutes to show the impact created over the last 6 weeks.
We show that the needle moved, or we show what we learned to make it move the next time.
We are emphasizing on the outcome we reached, and of course the outputs we built (Don't fall in love with what you do, fall in love with why you are doing it)
The format is free.
Some teams are doing collaborative demos across different platforms, with some story-telling.
Some are playing with the audience.
Some teams are preparing after-movies.
✋ Personally, I am a big fan of presenting the problem by showing the user experience as it was before: Broken, boring, too long. Focusing a lot on the problems.
Then presenting what we did with the new experience, focusing a lot on the solutions we brought to the product.
Finally concluding by showing the impact of what we just presented: User feedback and data points.
✋ Personally, I am a big fan of presenting the problem by showing the user experience as it was before: Broken, boring, too long. Focusing a lot on the problems.
Then presenting what we did with the new experience, focusing a lot on the solutions we brought to the product.
Finally concluding by showing the impact of what we just presented: User feedback and data points.
🎶 ACT 2: I can show you the world
After the demo, each team is 🎤 Pitching an opportunity.
The pitch is the presentation of the wished scope and the expected impact that the team wants to deliver in the next cycle.
The pitch is prepared by all the members of the team (engineers, designers, product Managers) and presented by the product manager.
Once again: the format is free.
All that matters is that the team is able to convey :
- What outcome they want to reach ...
- ... thanks to what output.
✋ I like to make my pitches as if they were "trailers for a future demos".
I present the problem with the current user experience, I present what I plan to build with anything that can make it interesting: early designs, interactive prototypes, storytelling:
Some PMs like to explain much more in detail the reason behind their team choices.
🎶 ACT 3: Is this the real life? Is this just fantasy?
Most of the time (if not always 😊) pitches are too idealistic.
We forgot some tasks or some duties, we assumed a department will be able to fully support us, etc, etc.
This is why the remaining part of the festival is used to "reality check" each pitch: This is the role of the 🍷 Speed dating.
With the speed dating, each team gets the opportunity to stress test their plans, receive feedback and understand different perspectives from stakeholders. It's also the time to understand our dependencies better
At Ricardo, each opportunity team meets the following stakeholders and tries to answer the following questions:
- SRE team
- Did we take into account all the infrastructure aspects of what we plan to create?
- Engineering heads
- Is technical debt handled?
- Are post-mortem actions from past incidents taken care of?
- Did we consider our engineers' well-being? (Personal projects, technical training, etc)
- UX team
- Did we plan research efforts?
- Do we need UX writing?
- Customer Care team
- Are the main customer pain points taken care of?
- Do we need to train customer care agents for big new features
- Is our help center up to date?
- Does our internal customer care administration tool need new functionalities?
- Data Intelligence team
- Can we generate insights based on what we plan to build? (Do we know what to track, and how ?)
- Are we lacking insights, and do we need to plan big data analysis (Like cohort analysis)
- Marketing team
- Do we have a go-to-market strategy, and do we need the marketing team to support us
- Business Development team
- Did we take into account our key accounts?
- Do we need to talk or interact with our key accounts?
- SEO team
- Can we use what we plan to build as an opportunity to promote our product?
- Are there SEO risks related to what we plan to build?
✋ Speed dating is exhausting.
I like to bring the whole team with me, and assign a note-taker for every session (10 minutes per session).
I received great feedback from some developers that are learning or discovering some aspects of our work in these sessions (the research efforts for much later, the marketing campaigns we are trying to create to advertise our new features).
🎶 ACT 4: By now you should've somehow realized what you gotta do
As you may have guessed, the opportunity teams usually finish the speed dating with a list of things they initially overlooked, a bunch of dependencies they did not think about, and a more accurate picture of the availability of each department that must support their opportunities.
Naturally, the next step is to revise the scope of the opportunity based on every learning of the speed dating sessions.
In other words: We 🗺 Plan
We take the initial (and idealist) opportunity pitch and all the outputs generated from the speed dating, and we create from these a realistic plan.
This is when we ruthlessly prioritize between opportunities, operational work, and requests so we build the best possible plan while keeping in mind the constraints of running our business
The plan is composed of the scope that we commit to deliver during the next cycle and the milestones we plan to hit.
This plan takes into consideration everything:
- Features we plan to develop
- Support from other departments
- Quality work: Bugs, Technical debt, Design and UX debt, Post Mortem actions, Technical improvement
- Research effort
- Holidays, Training, Personal projects
- etc
This plan is a commitment from the team.
✋ The more we prepare and refine what we bring to the festival, the more accurate our estimations are.
During this session we try to answer these questions:
- Do we all have the same understanding of what we plan to deliver, and why?
- Did we plan all the dependencies that we knew or that we discovered during the speed dating?
And then we put a rough estimate on each user stories and place them on a timeline.
We try not to overthink the planning, as we will refine these tasks every week during the cycle anyway.
Finally, we decide what is not making the cut.
We try not to overthink the planning, as we will refine these tasks every week during the cycle anyway.
Finally, we decide what is not making the cut.
🎶 ACT 5: Snap back to reality
Finally, we close the festival with the 🎯 Final Team Presentations.
Each PM goes back on stage and presents their committed planning, focusing on the delta with their initial (and idealistic) pitch.
Everyone leaves the festival with a clear picture of what we are going to deliver, why and when, and with the certainty that most of the dependencies and other blockers will be handled
The Festival Preparation
During a cycle, the team dedicates some time to prepare what they want to pitch next.
During the 4th week of a cycle, the team meets the leadership team for a "cycle preparation", where they have the chance to "rehearse" their pitch.
This session is twofold:
💬 It is a discussion between the team and the leadership team.
🚦 It is a decision meeting: the pitch is either green-lit or some aspects need to be revised before the festival (For example: maybe the expected impact is not aligned with our company OKRs)
During the 4th week of a cycle, the team meets the leadership team for a "cycle preparation", where they have the chance to "rehearse" their pitch.
This session is twofold:
💬 It is a discussion between the team and the leadership team.
🚦 It is a decision meeting: the pitch is either green-lit or some aspects need to be revised before the festival (For example: maybe the expected impact is not aligned with our company OKRs)
Conclusion
We just ended our 20th edition of the festival 🎉
We are still adapting, trying, practicing. Our festival is and will always be a living process
We are still adapting, trying, practicing. Our festival is and will always be a living process
Practice isn't the thing you do once you're good. It's the thing you do that makes you good
- 💬 Malcolm Gladwell
I joined the company 11 cycles ago (1.5 years ago), it's amazing to see the result of our practice.
We are becoming more and more predictable and impactful.
1.5 years ago, for cycle #9, my team and I committed to delivering a proof of concept of a delivery service.
The plan was invalidated within the first week:
We forgot to plan technical debt and our delivery provider was not ready to provide us with usable APIs.
We could have predicted it!
We could have predicted it!
Last cycle (cycle #19), we completed all our main product goals (spread across iOS, android, and the web), technical goals, and quality goals.
We are not working faster, even if it feels much faster.
We just know where we are going now, we are predictable.
1.5 years ago we were entering a maze every new cycle, now we still enter a maze but with google maps and some nice drone shots to show us what danger lies ahead.
- 💬 Me, just now 🤘🏻
.jpg?disposition=attachment)