Keeping the Train on Schedule

The Protagonist

Joe was a decent developer. He generally got his work done on time, kept skills up to date, helped out coworkers… all standard things that a developer should do.

The Situation

One day, Joe walked into his manager’s office to deliver some unpleasant news. Joe said “So, code complete is in two days, and I haven’t even started the foobar feature. I don’t know if it can even be done in time, it will be tight at best.” Manager furrowed his brow, this was unpleasant news indeed. Foobar had been promised to customers and other features were depending on it. Manager asked “What happened? Why is it running late?” Joe answered, “Well, on the last thing I was working on, the fizzbuzz feature, the designer kept coming up with changes. I kept on thinking it was just a small change here and there, it’s just another couple hours of work. But it kept happening and kept happening, and the next thing I knew, it was today and the rest of my work was at risk.”

To spare you the suspense, don’t worry: Joe busted his butt and got the foobar feature done in time and everybody was happy. But it didn’t have to be this way.

How Could This Happen

As a developer, there numerous forces trying to drive the priority (sometimes inappropriately) of what what you work on. Managers, co-workers, QA, customers and support… Many people can derail your attention and lead you to believe that their item is the most important. What happened in the situation above was scope creep (or perhaps just insufficient initial design) initiated by a fellow member of the team.

Prevention is the Best Cure

Obviously it’s best to not have to bring up uncomfortable news in the first place. Some ways we can avoid this kind of derailment:

  • Stronger definition of done: with a clearly defined scope, we can more easily recognize when we are being asked to do out of scope work, and we can more easily shift these requests to a later work item.
  • Recognizing scope creep: we should be able to say no (or defer to a higher decision maker) when someone asks for something that really is out of scope.
  • Daily standups: with high visibility into everybody’s progress, derailment can be recognized and mitigated earlier even if the developer does not recognize it.
  • Be cognizant of time spent: the hours for each task are estimated at the start of a sprint for a reason. When going over the estimated hours we should raise the issue with management as early as possible.

Conclusion

As software engineering professionals, it is our duty to be vigilant and recognize derailments and ensure that we are always working on the most important thing first.

Advertisements

Leave a comment

Filed under Software Engineering

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s