https://twitter.com/kartar/status/619587592300969984
Reliable software delivery is welcome, and an ideal trait of a great product engineering team. Most would trade off a slightly slower pace of delivery to gain predictability.
This level of execution is tough to come by. The team needs to learn to work well together but that isn’t enough. Just as all teams aren’t equal, all problems aren’t equal too. You may be able to get into a predictable rhythm when it comes to estimating the time it will take to deliver a screen when the API is already stable, but if there are more unknowns (usually the case) it gets harder. And then there is true R&D. You can’t predict the unknown, so if a team doesn’t understand how they are going to solve a problem then your estimate could be wildly off.
The thing is: that is OK! This is how creative work happens!
One frustration I have with The Business wanting fixed deadlines is that they rarely appear to have time to understand any of the nuance, risk, and unknown. They want a date, even if it is a false sense of security and doesn’t represent reality. Tools such as LiquidPlanner that try to put in as much of the uncertainty as possible can help visualize this nuance. If you are giving an absolute amount of work then chances are you are very wrong. Favor ranges over absolutes and push to get people thinking in that way. Understand how any fuzzy prediction gets clearer as it gets closer (like the weather!).
This is often a tough sell, which I have always found interesting given that 90% of the projects have all had the goal posts moved, often near the end. Teams can be scared to change the date because “we don’t want to be flaky” so they keep holding their breath and hoping that heroics or luck will save the day. Sometimes they do, but do you want to run your business (or life) that way?
I feel awful when an engineer saves the day through heroics as it means that I didn’t do my job. Great engineers have done this countless times in my teams, and I celebrate them whilst feeling the personal frustration.
We naturally want to keep commitments, and being good partners is very important, but transparency and doing the work as a team is more critical than keeping false views. Transparency allows for understanding and an easier changing of scope and incremental tweaks along the journey.
Then you get to one of the worst sins: shipping to hit the date. Teams persuade themselves that the risk is worth it, that it is “good enough”, and prioritize the commitment to partners over customers. This tends to burn you though, as what really gets remembered? the quality of the product. If it is buggy, or suffers downtime, the team will be scrambling and paying the price for some time. There will be pressure to ship something, especially if it has slipped a couple times, but what is actually remembered is the product and how well it performs. That extra couple of weeks of testing and polish may be critical, so we shouldn’t take the talk of “MVP” as meaning “ship stuff that isn’t tested” (MVP is about the feature set, not the quality).
Some dates are more sacred that others. If you are in retail you understand that there is a bit of a difference in shipping functionality in October vs. February. You have to be ready for Black Friday and the holiday season. This means that your processes need to change accordingly. Not only do you need to account for those periods where the “dates can’t move” (and thus scope etc has to), but minimize the importance of dates at other times during the year to give the teams a freaking break.
I know that someone promised some feature to some team for a March 1st ship date. You know what, software happens, and the fact that it ships in April isn’t the end of the world.
Be proud of what you ship, and how the customers experience you, and prioritize that above politics. The politics will probably take care of themselves: when the product does ship and it does well, the stake holders will appreciate it and will forget that it was a little late. The customers (and stake holders) won’t forget the product that shipped on time but blew up in everyones face.
I have had this post in the queue for awhile, but it felt like I should finish it up and post it on the day that NASA comes to Pluto 72 seconds ahead of schedule on a 9 year mission.
That is both impressive, and showcases the trade offs needed to get precision.
What is also interesting is that we can get the drone to Pluto, billions of miles away, but we can’t keep up the website that talks about it. Huh!
I will take a drink and tip my hat to the engineers at NASA as we watch game time at 5:36pm Pacific Time!