I heard this sentence multiple times during my career, and sometimes said by myself.
This sentence carriers at a lot of assumptions, beliefs, and responsibilities:
You can plan in advance
Product/project can define better specs
Tech can estimate the time to deliver
The space I found this sentence the most is during retrospectives, when we expect something to take less than it is taking/took. Usually, we ask during the retro:
What happened?
What could have done differently?
“We just need to plan it better next time”
And most of the time we tried to plan better, we made things worse. Because the more dangerous belief is that you can know in advance.
After walking the walk, we know a lot more. What helped us to gain the knowledge was the movement, the execution based on imperfect information.
Walking the walk, we reduce risk, we iterate fast, and we often communicate our learnings with the rest of the team, and organization.
Yes, that will imply rework, frustration, and feeling of waste.
Yet, that was what was needed to gain knowledge and move forward. That had value on itself.
What to do instead?
Identify if we are moving the responsibility to product
We all want to make our job better, and asking for better requirements is an easy ask.
“If I knew this in advance, this wouldn’t take this long.” - Every dev at some point in their career.
Instead, aim how you can collaborate with product to reduce the unknowns and gain rapid knowledge. Instead of full functional implementations, aim for short experiments.
Move from Factory Dev into Product Dev.
Identify if we could fall into the analysis-paralysis trap
We love certainty. We all do. Yet, that’s not reasonable. And with AI, this illusion is even harder to spot.
We cannot know everything in advance, nor it is useful. Some sort of upfront is reasonable, aiming to have a full plan from backlog to prod not useful.
Instead of assuming that more upfront planning would help, ask which areas would have worked better, and which areas wouldn’t be identified regardless of how much planning made.
Make those scenarios explicit, identify the things that took the most to learn, and the cause of learning it late.
Then you can ask yourself and the team “what can we do to expedite learning on these areas?”
Maybe the solution isn’t more research, but microtools to learn faster as you develop.
At this point, I want to introduce you the concept of Moldable Development.
If you are interesting on a new way to understand software, I would recommend you to take a look at it. I will write about my experience about it in the future.
What would you do instead?
Reply in the post on how did you approach this situation, I’m sure we all faced it at some point, but super interested to know how did you overcome the situation.
