The Project Date - Kill It!

Tom DeMarco recently published an article in IEEE Software suggesting he may have been wrong in stating that metrics are a requirement for successful software development.

He questions his timeless statement, “You can’t control what you can’t measure”, realizing that control is not the most important aspect of a software project.

But there was a small section on the second page of the article that was especially thought provoking. DeMarco makes the following hypothetical statement.

“I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you  have to be ready to package up and deliver what you’ve got as the final product.”

Imagine for a moment how this would change the software development landscape. So much of software development is dominated by that single date - the date the project must be finished. It dictates most of what we do, and when we do it. It’s typically one of the first things we know about the project - when we need to be finished. The date drives the project. Every software development team strives to finish by that preconceived date, often making significant compromises along the way. Sadly, these dates are often pulled out of thin air (the CEO’s birthday, perhaps?), yet are written in stone as the date we have to be done.

The date makes agility counter-intuitive and encourages development practices that we know don’t work. Removing the date makes agility intuitive. Seems kinda far-fetched, heh? I’m not so sure. Having thought about this for a while, I’m not convinced it’s too far away from the notion of internal and external releases.

Imagine the profound affect it would have on how we went about developing software if there was no date. Imagine if that date was unknown to us. It could be tomorrow or it could be a year from tomorrow. Imagine how we’d be forced to change how we work. We’d be forced to emphasize software quality throughout the development process. We’d be forced to ensure we always have a functional product. It might go something like this.

We kickstart the project by hosting a meeting with our customers. In this meeting, we establish some high level goals for what the system must do. Basically, a sketch. We’ll call this our initial project plan. The development team is already busy setting up their development infrastructure - the version control repository, the IDE, test harnesses, automated build script, some code inspection tools, the datasources, and the important frameworks we’ll use to develop the system. We don’t have time for waste, so we only do what’s going to provide value.

At the same time, we put together some wireframes and mock-ups, and a week after that first meeting, we share these mock-ups with our customers. They may like them or they may hate them. For those they like, we start implementation. We know we must move quickly, but we must be careful to ensure we have a functional product at all times. If the build fails, we have to fix it. We can’t let quality degrade beneath acceptable levels. We have to be ready at all times to package the system, and make it available to our customer. We have to establish our cadence - our sustainable pace.

It’s obvious that we have to show value early and often. Our customer can demand the system anytime they wish. They can also cancel the project at anytime, as well. The only way to ensure the future of the project is to demonstrate value. Intense and frequent collaboration is in our best interest. It’s in the best interest of the project, too!

To afford ourselves the slightest possibility to deliver the system in one week after the customer’s request, we have to test early. Quality must be baked in from day one. We have to ensure we can package and deploy the system quickly. We must have the ability to perform the entire lifecycle on a moment’s notice. We can’t wait to run our load tests, capacity tests, or failover tests. It’s in our best interest to do this as often as we possibly can. To ensure we have the ability to test as often as we’d like, we’ll want to automate as much of this as possible.

In general, we only have time to perform practices that directly contribute to the delivery of software. Estimates? We don’t have time to estimate, nor is there a reason to. The business gives us their highest priority scenarios, and we implement them to the best of our ability. If they like the direction we’re headed, we keep funding. If not, the project’s over. And when the customer feels they have a system that’s going to provide value, they get it when they want it. Requirements signoff? We don’t have time to signoff on requirements and then resist change. In this world, it’s in our best interest to serve the customer, embrace change, and prove that we can respond to their needs quickly.

Doesn’t that sound productive, intuitive…and fun? There are so many fascinating and amazing ways to build upon this scenario. Imagine it for a moment. How do you see it playing out. Good? Bad? Ugly?

From http://techdistrict.kirkk.com