The Software Must Be ‘Done’ by the Due Date

My examination of enterprise agile development based on the article I wrote for the Tools Journal called “10 Tips for Succeeding with Enterprise Agile Development” is nearly complete. Let’s talk about delivery dates…deadlines…schedules…drop-dead dates.

Meeting dates is important. Let me repeat that — “Meeting dates is important.”

Some agile development practitioners seem to believe that being agile means not committing to software delivery dates. They say something like, “The software will be ready when it’s ready”. That’s wrong! The software must be ‘done’ by the due date.

No one can run a successful business amidst uncertainty and doubt, particularly an enterprise-scale business. Customers, investors and partners need to know when a product or service will be available. It may be a completely new service or an upgraded product. Either way, we all want to know when it will arrive!

It’s vitally important for companies to set delivery dates and hold them firmly. Too often, I see companies set software end dates only to move them when it becomes painfully obvious that there’s no way to deliver as scheduled. It’s quite common to see dates moved several times before the software arrives — or the project gets canceled. Wrong move!

Meeting dates is important.

1. Set realistic delivery dates that the development team has helped set and has committed to meeting.
2. Do not move the end dates.

Everyone in the company needs to get the message that dates are important and they will not be moved. Once that message sinks in, behaviors will change and people will come together in a coordinated effort to deliver on time.

Now the bad news…

The business will NOT get everything it wants. I said dates have to be met but I never said anything about delivering every feature and function in the requirements document or user story backlog. There needs to be flexibility somewhere and it belongs in the software requirements.

The business needs to prioritize and sequence the software requirements or backlog. If the schedule has been vetted by the team, the most important items will get done by the deadline. Anything that doesn’t make the cutoff, will get rolled into future software updates.

A critical success factor is having the development team estimate the work effort and buy into the delivery dates. The traditional approach of having senior managers define the requirements, pick an arbitrary end date, then force it upon the developers is a guaranteed disaster. Stop doing that!

This collaborative approach will require a cultural change at many companies. It’s a change that’s well worth the effort.