Along the interior of the stockade, 19 feet from the stockade wall, was a line of small wooden posts with a wood rail on top. This was the “deadline”. Any prisoner who crossed the deadline could be shot by guards stationed in the sentry boxes. 
“The sponsors, developers, and users should be able to maintain a constant pace indefinitely” – Agile Manifesto.
The real problem with deadlines, is that any deadline longer than a day or two you are asking people to fail. What you are really measuring with deadlines is the ability to estimate. If you are trying to convince people to get something by a deadline, the only way they could get something done by a deadline is by getting better and better at estimating. This is something you cannot do, even with experience. 
I’ve seen this movie before. The plot is simple: First, you take an urgent date-driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers. Them you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment. And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date.
Last week I attended the Agile Australia Conference. I will post a conference report soon, but thought I would share the 2 main takeaways I had from the conference. One is the DevOps movement and the second is Continuous Delivery.
DevOps is a new movement seeking to achieve the business need for rapid delivery of software products while maintaining the stability of live environments. It uses two approaches: first, promoting closer collaboration between development and operations; second, applying practices shared with agile (collaboration, automation, simplicity, etc) to operations processes such as provisioning, change management, and production monitoring. It encompasses culture, processes, and tools – all supporting better communication, faster feedback and delivery, and more predictable outcomes.
With continuous development of working software, we need to get the changes into Production as quick as possible through Continuous Delivery so we can shorten the feedback cycle and so the business can maximize the ROI.
This recent Dilbert comic strip reminded me of a situation when a client was raising cosmetic defect as severity 2.
It is often not clear what a defect is and at what level to raise it at (despite agreed severity descriptions) as my example above shows. And some defects are raised without being related to a requirement. Or defects raised because of a feature being “not user friendly”.
Regardless of the reason and how you label the ‘defect’, I treat all defects the same – it is a piece of work required by the client that needs to be prioritized with other work. So the approach is to put all work (defect, enhancement, new feature etc) into the product backlog. As part of the planning process, the Product Owner will prioritize the items on the backlog for the next iteration and/or release. So if a cosmetic defect is more important (has greater business value) than a new feature, then it should be placed higher so it gets completed first.
Keeping all work in the product backlog, makes planning simpler and helps manage the flow of work. It also ensures the client is in control and be the judge of what is important to their business.
We sometimes hear that business is not getting value out of IT. Technology and tools are constantly improving but we often have missed expectations. The need to align business and IT is getting more important.
Incorrect assumptions of what the client needs often leads to incorrect actions resulting in wasted effort.
Next time you speak to your customer, clarify what they mean and speak in their language. Get the customer to provide real life examples and elicit feedback along the way. That way you will move towards aligning IT with the business and deliver greater value.