Estimating with a "yes, and..."
When presented with a hard deadline, consider committing to some version of what's wanted instead of saying it can't be done.
Full disclaimer: this post is about a concept that I haven't validated yet. It was presented to me recently. I find it intriguing and am in the process of trying it out myself.
Timing is everything
When your team is hyping up a new idea and placing it on the roadmap, there's nothing worse than hearing that it can't be done in that amount of time.
I'm usually that person. Over the years I've learned that things usually take longer than expected. And having some extra time to ensure people don't forget to write automated tests and write their code in a composable way is valuable for team morale when revisiting a feature. But it's hard to be the bearer of bad news. Especially when everyone's getting jazzed up.
What usually ends up happening after I request more time or a reduction in scope:
- Other devs on the team stay quiet. Fully expecting struggle to meet the deadline. Working weekends, longer hours, etc.
- Management still wants to move forward with the expectation and deadline.
- After some back and forth and painfully time-consuming planning and estimation breakdowns to every last detail, we're able to get more time allotted on the roadmap.
An alternative approach
My boss had an interesting counter to my request to reduce the amount of unique tasks that we're expected to ship in the next, 30, 60, and 90 day roadmaps. He suggested that we ship everything on the list, but are flexible in the scope of what each of these things look like.
For example, we have 7 large features to ship as a team of 4 over the next 90 days. It's also the end of the year and there are many holidays and vacations to factor in. We can timebox each feature in X weeks and only ship what we can in that amount of time.
In other words, we only ship MVPs. But without a pre-defined scope of what an MVP for this feature is. Almost like a bunch of hack-a-thons.
The challenges
Defining the scope of something as you're building it seems difficult, but helpful. You have to contain your excitement and focus on not over-engineering it since your time is so limited.
Holding in so many features in your head is hard. You have less time to tinker and experiment on a good approach before committing to it. Less time for writing automated tests. And less time for unexpected things to happen.
Having stakeholders cram in as many features as they can and giving a thumbs up that they'll see some working version of that on a specific date seems risky to me. In my experience, stakeholders might say they want an MVP, until they start to use one and wonder why it's missing so many features they were excited about.
But after writing all of these challenges out, they all feel like they remove any of the fluff of building things. No wasted effort on planning, tinkering, etc. Just pure development.
Culture of shipping MVPs
For context, I'm working at a small startup right now. We have 13 employees, 4 of which are engineers. And lots of big ideas and talent to bring anything we want to life.
Except for a few years at Amazon and AWS to see what FAANG was all about, I've worked at startups for most of my career. I love moving quickly, taking a bias for action and re-routing as needed. Especially without a lot of bureaucracy to make a decision. Or trying to plan out every last detail of something. Which inevitably changes anyways.
In theory, having a culture of setting a scary deadline, but with the expectation that we'll do as much as we can, sounds like a decent idea. One worth trying out and talking about afterwards.
It requires trust that no one is distracted with unnecessary requests or meetings. And trust that we're shipping the best product we can within such a short time frame. Trust that things will be missing, follow up will be needed and dates might be missed. It feels like an "actually agile" approach
I feels like many teams say they're agile, but are really waterfall with two week sprints.
Another requirement to me for this to work is to use these "heads down development, sprint hack-a-thons" sparingly to avoid burnout and prevent accumulating too much tech debt. There's a lot of value in writing more automated tests, tinkering with new patterns and refactoring commonly used parts of the codebase that are painful to iterate on.
Conclusion
I'm excited to try this out over the next 90 days. And will post about my findings afterwards. Stay tuned and happy coding! SL
