Are Deadlines Agile?

I had two weeks. I hadn’t fallen behind; I didn’t procrastinate. That was all the time I was given to work on the final assignment— a rather interesting project at that— for my data structures class.

There were classic answers to the problems given in the assignment: this should be a class, that should be a list of that class, an so on. It wasn’t a poorly designed project. There was a right way to do it, but my grade didn’t depend on doing what was right.

I got an A by breaking the rules.

Finishing that assignment started a habit I spent a long time breaking. Some of the worst code I’ve written or the decisions I regret the most came from the pressure to meet a deadline. Though I’ve gotten better, taking the fast route is still a temptation. I’m not alone there either: when deadlines approach others try to cut corners with me in quality, process, or features with me to make a ship date.

With that potential to cause harm, do deadlines fit in with agile processes? Are deadlines agile?

There’s not a guide to dictate if something is or is not agile. There is a good set of principals, however, laid out in the Agile Manifesto.

Individuals and interactions over processes and tools

By definition deadlines are part of a process: they are the end of it. They are also a tool that is often misused. The Agile Manifesto lists points as a core set of values and the value here is that the process should fit the individuals, not that the individuals should conform the process.

Agile or Not Agile: Not Agile

Working software over comprehensive documentation

As painful as it is to admit, software that ships often does work. My grader in data structures didn’t care that I threw out the class material; I was graded on the fact that my assignment gave the right outputs for the given inputs. Customers often have the same, singular care.

Agile or Not Agile: Agile

Customer collaboration over contract negotiation

Customers can’t use software that hasn’t shipped. A properly stated deadline can also help the development team and the customer have an informed conversation and, for example, decide together if that last feature is really needed now or if it can wait until the next release.

Agile or Not Agile: Agile

Responding to change over following a plan

Having a date that will not change is not responsive. Moving to kanban from scrum taught me that arbitrary time boxes don’t respond to a changing environment either. Since we can’t predict the future our plans can’t account for everything that inevitably happens.

Agile or Not Agile: Not Agile

Final score: 2 to 2

A tie.

Darn.