Estimates and deadlines
We feel very strongly about estimates and deadlines in software projects. In general, we think they are useful tools to monitor the velocity and effectiveness of a development team and keep it connected to the actual business problems that are being solved.
However, we have often seen them being (mis)used against, rather than for the team. Our approach towards estimating projects and taking on deadlines is a bit unconventional and is at the core of what allows us to ship high-quality products that make our clients happy.
Here are some resources which have informed our views on the matter of estimates and deadlines in software projects:
We estimate, but not too much
Development teams should provide estimates that help making useful business decisions: in Scrum, for example, story pointing is useful to decide what stories to work on over the next sprint, and to act swiftly when external factors or issues in the workflow affect the team's velocity. Estimates can also be useful to decide whether the business can afford working on a project, given its current priorities and available resources.
What we are strongly against is having a team provide estimates with the mere purpose of keeping them "in check." Not only does the practice create stress and resentment, it actively harms the quality of the product. People are generally bad at estimating, which means if you constantly negotiate estimates or hold their estimates against them, they will compromise on whatever aspects they can in order to keep their word. The end result is a broken product that will cost you time and money to keep running.
When you ask us for an estimate, we will ask back: what is the purpose of this estimate? Then, we will work with you to strike the right compromise between having enough context to make informed business decisions and creating an ideal environment for the development team to work in.
We accept reasonable deadlines
Closely tied to estimates is the concept of deadlines. In an ideal world, of course, deadlines would not be needed at all and everything would take exactly as long as it needs to take. In the real world, though, things are much different: circumstances outside of our control (Black Friday, vendor transitions etc.) are often at play and sometimes we simply cannot afford to wait forever.
We understand this, and we will be happy to accommodate reasonable deadlines justified by real business requirements. What is important is being transparent with your developers about the context and the needs that have led to this deadline, and why it is important to your business. This enables the team to be aligned with your objectives, and to suggest solutions and compromises that will allow you to reach them.
We do not, as a rule of thumb, accept deadlines that are not motivated by an external factor, and are simply put in place out of fear that the team will underperform. We bring our best selves to work with all of our clients, no matter whether we have a delivery date or not. Like estimates, unmotivated deadlines only harm the quality of the end product.