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.

No Surprises

My cat EzriI have a rule that I apply to my cats and to my coworkers. *  It’s one of those rare circumstances when over-generalization actually works.

One of my cats gets medicine every day, and she likes it about as much as you’d expect a cat to— not at all. Every day we go through the same routine: I measure the dose, she runs, I catch her, I take her to the medicine, I give her the dose, she runs again, and we’re done.  After all of that she’ll be waiting for me on the couch, completely unafraid.  She always knows when the bad stuff will happen.

It took me a while to realize how that reasoning could be agile.

“Do you think you surprised them?”  I don’t remember what prompted my manager to ask that question.  I might have been talking about a problem I was having a hard time solving.  I might have relayed some tidbit I heard in a meeting.  I might have mentioned some test case that broke a new feature.

Whatever prompted the question, I did surprise my manager.  Here I had someone on my team who’s primary job it was to reduce risk and I surprised them with bad news.  I didn’t have to do that.

In fact, most teams have someone like this.  They usually have the title of manager.  They are the ones who are expected to know when things will ship, what’s keeping the team from shipping, and what happens if the team doesn’t ship.  They definitely want to know what might be a problem and how likely those problems are.

The question stayed with me.  I had a simple rule about what I should say in status meetings: if I don’t say something now, will I surprise my manager later?  I didn’t want to inundate my manager with trivial, but trivial information wouldn’t be surprising.  Thus the rule has a built in filter.

It was a few years later that a different manager asked me, “I know you don’t want to surprise your project manager.  What about the rest of your team?”

I was a little sad that didn’t occur to me sooner.  It’s not solely the job of people with manager in their title to mitigate risk.  It’s part of everyone’s job on the team, including mine.  Again, I don’t want to go on about problems that aren’t likely, but trivial information isn’t surprising.  It’s a different problem if I can’t figure out what my team thinks is trivial.

So now I try not to surprise anyone, feline or human.

* What can I say: cats get page views.