AgileIQ Blog

Work Harder

  

 Email Article  

Tweet  

  

by James Rosko

A manager I once worked with got out of an executive meeting, walked over to development, and said, “I’ve been talking with the VPs and everyone has to work harder.”  Fred, the manager, continued by saying, “We’re going to have to be creative about how to get all this work done.”  I took Fred aside and said asked him, “by ‘creative,’ you mean work more hours don’t you?”  He replied, “Yes, I mean work more hours.”

Before you criticize Fred, let’s try to understand what it means to “work harder,” “be creative,” and more importantly how a development organization should respond.

From a laborer point of view, working harder means move faster, take shorter breaks, push through the pain, and work more hours.  All of these seem intuitive...  Before college, I worked at a greenhouse.  When my greenhouse boss said to work harder, he’d then add, “move faster,” “get back to work,” and “this needs to be done today.”

At the time Fred made his appeal, our two Scrum teams worked on two major projects.  I asked Fred, “What are some specific things a software development organization can do to work harder?”

From a programming point of view, typing faster doesn’t solve much because a developer invests substantial time in reading code, discussing tools and frameworks, and choosing names for things. However, a few programmers I know might benefit from a refresher course in typing.

I suppose developers can take shorter breaks, but the the Pomodoro Technique suggests an optimal work/break schedule.  Essentially, it prescribes how long you should engage in a focused activity before taking breaks, and how long each break should be.  As you repeat the technique, the schedule changes.

According to Fred, working harder also means working more hours to complete the projects.  Working more hours gives a diminishing return on investment and should only be used in exceptional cases.  It does not increase long term productivity.  I consider working overtime an Agile antipattern.

Now that we’ve established that the traditional definition for “work harder” doesn’t fit for a developer, let’s address the goal of what is needed by working harder.  After all, working harder is a means, not an end in itself.  As Fred himself said, the goal is to “to get all this work done.”

The “get it done” phrase is popular among managers.  I believe managers say this when they know what they want done but don’t know how to increase organizational productivity.  The Agile development process increases organizational productivity over traditional models by prescribing  team focus (swarming), immediate results (low work-in-progress), high morale, and other best practices like pair programming and high quality (see XP programming).  

 When we adjust the speed at which we deliver software at the same cost, quality traditionally suffers.  Following Agile/XP practices, we can attain high quality over the long term by focusing development effort on the highest-priority project first.  That way, the business gets the most important project completed soon, with high quality, and the lesser important projects done a little later.

I told Fred working overtime might give us the appearance of getting more done, but we wouldn’t actually be delivering as much high quality software.  Instead, we should focus on the highest priority project first and use XP programming practices to obtain high code quality at a sustainable pace so that we can continue to meet business objectives.

In the end, the executives realized the project dates they committed to weren’t in line with what the business was able to deliver.  Following Agile and XP practices, the development organization got the highest priority project shipped first, a big win for the company, while at the same time kept reasonable commitments and working at a sustainable pace.