This blog post reminded me to write down my argument against using heavy process to do planning. “The Case for ‘Developer Experience‘” or full link https://future.a16z.com/the-case-for-developer-experience/?
This particular quote is my inspiratioin
So if I were to coin a law, it would be this: Any system of sufficient size and maturity will always involve multiple languages and runtimes. Software is heterogeneous, and until we as a community accept this fact, we’re upper-bounding how far we can get with developer experience. I call this The Software Heterogeneity Problem, and it has significant consequences for software development, management, and performance.
I’ve argued that building software is much more of an Art than Science. The teams who follow the agile manifesto strictly over plan this artistic endevor of birthing software from nothing with T-shirt sizing, rule of thumb and or fibonacci numbers in 2 week increments of a sprint. What I’ve observed in the real world of software engineering in 20 years is that during the planning and estimation process:
- engineers who are inexperience would over promise (under estimate) and work over time in order to meet their deadlines, thereby burning out or over time they learn to pad their estimates.
- senior engineers would know to pad their estimates by an order of 2X because they know from experience that they will encounter unknowns during implementation no matter how much time they spend up ahead to do story breakdowns.
- for all engineers, they are held to their original estimates (even though they are told they are not) so they try their best to deliver what they promise in the short 2 week sprint cycle. What happens with unexpected discoveries?
- If they had to cut corners to make the delivery : They would file a technical debt for themselves or worst yet, for another team member, to fix later.
- They are unable to deliver what they promised and the ticket gets carried over to the next artificial sprint. This is not a problem, unless the next sprint: the team decides their left over work is not a priority anymore and the cost of context switch in future sprints now becomes a huge mental overhead. Even worst if someone else other than the author has to take over the left over work
My recommendation for high performing software engineering teams is to try:
- Engineering managers: Build the trust with engineers, empower them to make smart choices.
- Give them the ownership of a feature over a reasonable long period of time (like 3 months or quaters) and trust that they will deliver what they promise.
- Give them the freedom do all the discovery, breakdown, don’t let a tech lead or anyone else do it for them
- Using the sprint structure for them demo, work and break down dependencies and a candance and milestone to check in
- Ignore sprint to sprint estimations (don’t do them at all)
Some disclaimer and background here
- I have been an individual contributor much longer than an engineering manager. As an IC I was part of a team of 2, back in 1990’s, and we built and deliver on the #1 website in the world with Yahoo! News serving 100 million users. As a team lead of 12+, we have delivered many production websites with unmovable deadlines such as multiple US elections. As an architect for 300+ engineers, we deliver on infrastructure and platform products for 130+ websites internally.
- As an engineering manager, I’ve worked on internal tooling without artificial deadlines, so my view could heavily biased.
- As an IC I’ve build tools that have endured with the highest NPS scores humanly possible at 81. The best tool I have built and my top engineers have built were don’t without the sprint structure.