Sunday, September 28, 2008

Rules of Productivity Presentation

How do we get more work done? It is a question that every manager and every passionate worker faces. Yet, for the most part, teams operate on gut instinct and habit. The results are less than optimal.

Over the years I've been collecting small pieces of research on various factors that actually seem to improve productivity. I've assembled eight of these experiments into a PowerPoint presentation. Feel free to use the graphs and data within to spread these practical ideas throughout your own teams.

Topics covered include:
  • The idiocy of prolonged overtime
  • The unintuitive connection between doing more and making better products.
  • Ideal team sizes and work environments
These lessons are particularly applicable to the game industry since it has some of the least educated management of any group in the software industry. In general, this is not their direct fault. We simply have a culture that tends to look inward (or at the movie industry) for solutions. A broader education on management and work practices, despite its ability to dramatically improve our games, typically takes a back seat to meeting the latest arbitrary, urgent deadline.

Download the presentation here:
take care,
Danc.

33 comments:

  1. I look forward to every entry, you always get me thinking :-)

    ReplyDelete
  2. Great slides, another one to add to my "should handover to my boss"-folder.

    I would have liked an experiment on "true" 4-day week schedules (not like http://www.forbes.com/2008/08/18/careers-leadership-work-leadership-cx_tw_0818workweek.html) but that concept hasn't been tried by many companies yet.

    ReplyDelete
  3. I'm wondering if this would be more effective if the references were embedded in-line.

    I liked the Ford references etc. but it got a bit lighter after.

    ReplyDelete
  4. On the 'true' four day week, France is always brought up as an example of the negative impact of reducing work hours.

    If you ignore the posturing, the little data I've been able to find on the experiment was interesting.
    The expectation was that people were at maximum productivity and forcing a reducing in hours would cause employers to hire more workers, thus reducing unemployment. This didn't happen.

    Instead, productivity overall increased by 6%. About 90% of the hour reduction was taken care of by increased productivity. So people worked less and got pretty much the same amount done.

    Now, if you are the French government, this is a bad result since your unemployment is still high. If you are a business who is paying hourly wages and utility costs, this is actually a good thing.

    There were actually competing proposals to the 40-hour work week in the 1920s-30s. Kellog promoted a 30-hour work week and claimed a 3-5% productivity boost over 40-hour weeks. They stopped doing this in the 1985 for political reasons (not a loss of efficiency)

    take care
    Danc.

    ReplyDelete
  5. I was trying to research effects of crunch earlier and having a hard time, because I was limiting my search to academic literature. So, thanks for this -- it answers a lot of the things I was wondering!

    Some open questions:

    * Your reports only compare a 40-hour week with a 60-hour crunch. What about 45 hours? 80? Is the productivity falloff linear or logarithmic? Is there a point where, even within a single week, you hit negative productivity immediately?

    * On the question of whether there are variations between individuals: yes, we all like to think we're the superhuman exception, but that still doesn't answer the question. There MUST be at least SOME variation between individuals, even if it's only minor. What's the standard deviation? What percentage of us can safely work 41 hours, or 42, or whatever (and conversely, what proportion of us need to work LESS than 40 to stay productive -- not because we're slackers, but because that's just our optimum range)?

    * Is there a difference between overtime that's mandated from above, versus voluntary overtime from a motivated developer who REALLY wants to get that extra feature in before the next build, and as long as they're in the flow anyway, may as well get it done? Obviously there's a morale penalty when developers feel like they're being punished with overtime for the producer's mistakes, but how does that translate into a productivity difference (or does it)?

    * Are there demographic differences in productivity and effects on crunch? For example, I found that women were more susceptible to feelings of depression during crunch time, while men were more likely to start or increase smoking and drinking. Do differences emerge between sex, age, income level, position (i.e. are artists more or less affected than programmers or designers), or education level?

    * How can we be sure we're not confusing cause and effect? Is it that people under crunch make poor decisions, or that people who make poor decisions anyway are more likely to make the additional stupid decision of crunching?

    * Aside from productivity, what other effects does this have outside the office? Do people under extended crunch suffer a higher rate of divorce? Heart attack? Suicide? Motor vehicle accidents and deaths? Worker's Comp claims? Other things that, in turn, are going to boomerang to reduce their office productivity even further? If the studies listed didn't control for these, it makes it harder to separate the primary effects of overworking versus the second-order effects.

    ReplyDelete
  6. I really like most/all of the ideas presented in those slides.

    I think I'd have a hard time selling them to a managerial type though. A lot of the earlier slides refer to studies/research to support their numbers, but it seems to drop off pretty quick and then you've just got a slide full of references at the end.

    Where does the 10-70% figure on your slide about 4 x 10 hour days come from? That seems like a massive margin for error.

    ReplyDelete
  7. Appreciate the comments on the data. I'll update this presentation so that the data sources are more clearly presented. Currently, many (though not all) of the numbers are in the reference articles (but that seems to be hard to parse)

    Travis: I double checked the number for 4x10 work days and the upper value was in the study I was looking at was a 60% increase in productivity: http://marriottschool.byu.edu/news/release.cfm?article=387

    Some (like one I found on prison guards) show increased job satisfaction, but slightly lower productivity. This variation is one reason why I only recommended that you look into it as an option. The flextime meta studies say that flextime seems to generally be beneficial as an option, but different alternative workworks appeal to different employees.

    Another thing that concerns me about 4x10 is that knowledge workers appear to get more frazzled when they work longer hours in the same day. There is the risk that bad decisions are made at the end of the day.

    Ian raise some wonderful questions. Here are a few guesses.
    - Many art tasks are closer to physical labor and require fewer intense problem solving skills. Based off personal experience I suspect that these map more closely onto the 40-hour week sustainable rate.
    - Programming and design related tasks are almost all pure problem solving. These may benefit from a 35-hour week sustainable pace.
    - One of the links shows the correlation between overtime and sickness. http://cat.inist.fr/?aModele=afficheN&cpsidt=15461524
    - I suspect crunch is more of a social norm than something done by stupid people. Otherwise you'd have to argue that almost everyone in the game industry is below average intelligence, which I certainly do not believe. Lack of education and difficult to change habits are the most likely reason for inefficient work practices.

    Productivity is certainly is a broad topic with a lot of variation. My hope is that folks adopt work practices that are at least somewhere in the ballpark of reasonable and then adapt to their specific situation as needed.

    take care
    Danc.

    ReplyDelete
  8. Thanks for that, it's all awesome stuff. Really makes me think about how I approach my own work.

    ReplyDelete
  9. I don't see any references for the claimed boost to productivity from a closed team room; am I missing something?

    ReplyDelete
  10. Here's the article that talks about the closed team room: “Rapid Software Development through Team Collocation” IEEE Transactions on Software Engineering, Volume 28, No. 7, July 2002 (Link

    Here is another interesting article
    http://www.possibility.com/Cpp/SoftDevOfficeLayout.html

    ReplyDelete
  11. Dan,

    Another great article!

    One comment. You say:
    "Schedule 20% below possible velocity if you are running a scrum team".

    1. Scrum teams aren't "run" (managed). They are self managing.

    2. You don't "schedule" a team. The team that you are a part of "commits" to work.

    3. Velocity is sustainable. A Scrum team commits to the work they can sustain based on previous sprints. No need to pad 20%.

    Such command-and-control language! ;)

    Have fun at PH!

    Clint

    ReplyDelete
  12. Hi Clint!

    Here's an interesting issue I've had with Scrum...(it is quite possible that I've been doing it wrong in my past six years of Agile. :-)

    I've found Scrum teams are ferociously efficient. Everyone has something to do all the time. The moment you stop a task, there is another one waiting. In general, this is a good thing.

    However, it is common that important yet fuzzy tasks such as brainstorming on the next set of products or trying out a wacky idea for improving the product don't happen.

    They are usually ideas that occur during downtimes. They often only make sense to the individual until they written up or prototypes. Often 'getting permission' leads to 'no' since there are very often concrete ideas that have already been determined to have high priority.

    And yet, this sort of grass roots ideation can be very effective in creating great solutions instead of just planned solutions.

    When we commit to a set of tasks that fill up our entire velocity, these activities don't seem to happen. I'm curious if anyone has any ideas of how to encourage them in a scrum environment.

    take care
    Danc.

    ReplyDelete
  13. You did a lot of good research. I could do more with this if I could see more complete references.

    I followed the links in your reference section, but I did not find much actual data. Is there any evidence less than 100 years old that working more than 40 hours results in less work done? Your slide is specific here - predicting a decline in productivity after 4 weeks of overtime, and referring to studies in hundreds of industries - but the links just refer to ancient data, the frustration of working long hours for EA (who wouldn't be frustrated?) and Chapman's purely theoretical construct. The one exception was the agile game development chart, which was derived from real burndowns. Very useful.

    Where are the actual studies on team size? The articles that you linked to were extremely wishy washy. However, your slide was much more specific - small teams with 30-50% higher producivity than groups over 10.

    ReplyDelete
  14. You might consider taking into account people working less hours than “normal.” After our son was born, I had to cram a 50-hour work week into a mere 20 hours, with all the results you might expect. While it is a nice idea of working less to increase productivity (see, e.g., Ryan Carson’s post about his 4 day work week experiment), working less hours than your proposed normal 40 hours/wk. can be as detrimental to productivity as working much more.

    ReplyDelete
  15. When we commit to a set of tasks that fill up our entire velocity, these activities don't seem to happen. I'm curious if anyone has any ideas of how to encourage them in a scrum environment.

    You could always try mandating it. See Google's "20% time". One pre-determined day every week, no work allowed on current work tasks.

    ReplyDelete
  16. You can open the pptx file and 'save as' office 97-2003 file. This way it saves as a .doc file and we can open it!

    ReplyDelete
  17. I think this is a great article Danc! I have one tidbit to add...

    Several years ago, I had a job where I worked 4 days a week, 10 hour shifts. At first I was horrified by this, but I quickly learned that this was a magical number for me. I was able to get more done in 10 hours because I spent fewer hours in the total work week "ramping" up every morning. The three day weekend was perfect. On Friday I was recovering, Saturday, having a good time, Sunday, stress-free and looking forward to work on Monday. I'd always dreaded Mondays, but not while I was working my 4 days a week / 10 hours a day job! Oh how I miss those days...

    ReplyDelete
  18. This is awesome. I posted a summary on Venture Hacks:

    Individuals

    1. Work 40 hours a week. (Working more feels like you’re doing more, but you’re actually doing less.)
    2. Work below capacity (say 80%) during those 40 hours.
    3. Consider spreading 40 hours across 4 days instead of 5.
    4. Get the sleep you need; allocate 8 hours.
    5. If you need a short productivity boost, work more for 3 weeks. But expect an equivalent reduction in productivity afterwards.

    Teams

    1. Work in small cross-functional teams (< 10 people).
    2. Put team members in a dedicated and closed room.
    3. Try not to split people’s time across multiple teams at once.

    ReplyDelete
  19. Excellent presentation and it makes a lot of sense. I read the comments regarding the weakness of the references and I'd like to remind everyone that it's been put together based off his experience as well.

    Sometimes you just realize things when you see them across an industry. Having read many articles across various productivity improvement mechanisms, a few books on self-management and on running a business, and various other information on small teams, extreme and agile programming practices, etc., I'd have to say that I myself, along with my co-workers and even now our boss (who we've pitched this presentation to) is in agreement with most all of the experiments.

    I'd like to add as a note that you also have to keep in mind what type of responsibility is laid on the worker versus in a small business versus in a large business. I work in a small company, and so we have increased responsibility within our respective spheres of work, and yet, even though we work the standard 40 hour week, we tend to be more productive than someone in a similar position in a bigger company, simply because we have more things we need to get done. It happens, I think, because you feel more satisfied with your job if you're getting more responsibility, not to an extreme, but say, in comparison with friends you may have that are not being shouldered with as much responsibility.

    That could be specific to me, but I know at the least that my co-workers feel the same way. We like doing more because we know we're valued more, and our team is very closeknit and small in size, but we handle a lot of direct customers.

    Overall, great presentation Danc.

    ReplyDelete
  20. Your presentation reflects my experience in a number of organisations and it makes a lot of common sense. I have posted my opinions on my blog. I am a great advocate of the 'Power of the Door' as a way of improving productivity, increasing team communication and just getting the job done.

    ReplyDelete
  21. While I tend to agree that 40+ hour work weeks are not worth it, the Henry Ford anecdote is highly suspicious.

    Given that Ford already controlled his company, there was no need for new laws to get a more efficient work week. In fact, he would have made more money if competitors stayed on a less efficient schedule.

    Laws are typically an entry barrier to competition, benefiting only the established players.

    ReplyDelete
  22. Great work! Speaking as someone who has managed the workloads for teams for the last ten years (web design groups for e-commerce sites), this data fits almost exactly with my own daily experience. I always plan for a baseline of about 6.5 "productive" hours per day for each person on the team and always try to avoid crunch at all costs, even jumping in myself to alleviate the workload. If an overload of work must remain on a single person's desk, I try to limit overtime to 3 days if possible. These are the rules I live by in scheduling work and I can see first-hand the decrease in productivity that happens when I do not follow my own rules.

    ReplyDelete
  23. Danc,

    I enjoyed the presentation and the thoughts collected over the years of experience. I may use it to persuade some of the people in my team that tend to follow many of the commonly accepted bad practices.

    I also want to share another well written research article that I felt related to this topic. It's actually a study done by the Air Force regarding the effects of sustained operations and sleep deprivation. Although the study is applied to Air Force operations, I feel that the lessons drawn from it can be applied to any field.

    http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA407468&Location=U2&doc=GetTRDoc.pdf

    Enjly!

    ReplyDelete
  24. This is an extremely intriguing post related to productivity, but I wouldn't necessarily agree with its accuracy. Its impossible to identify that (40 hrs/week) creates the optimal work schedule for productivity. This is completely subjective and differs for the individual. You can't look at it with such an unfocused lens. You have to look at it by the hour and measure productivity within that time frame. The best tool I've ever used to increase productivity, even past 40 hours/week is a vision board, a collage-like representation of images that represent your goals. This really helps focus you to your desired outcomes, and nothing else. I'd highly suggest reading this free downloadable chapter from John Assaraf's new book "The Complete Vision Board Kit" here: www.TheVisionBoardKit.com.

    Again, what an interesting post.

    ReplyDelete
  25. Danc, this is a great presentation. About my only objection is that in the PDF format it's more difficult to access. I would love to see it laid out on a website or wiki as a general resource. I don't know how much of this is especially "new", but it's clear and intuitive and that's even better. I'm not sure if you get notifications on these comments, so will touch base via email (when I remember!) to see if you'd be interested in letting me turn this into resource pages on Gamewatch. Thanks for the great post.

    ReplyDelete
  26. Hi Erin! Feel free to drop me an email at danc [at] lostgarden.com

    I've been looking for a version of this data in a format that I could present to teams who don't necessarily like to read. There didn't seem to be one so that is why I assembled this as a Power Point presentation.

    It'd be great to convert it into a web page as a resource.

    take care,
    Danc.

    ReplyDelete
  27. Would like to see evidence from experiment 6. Results not congruent with my experience.

    - Bob

    ReplyDelete
  28. Bob,

    Here's a research paper on the topic.
    http://possibility.com/Misc/p339-teasley.pdf

    There are some nuances to the implementation of team spaces that matter immensely. Was your team working towards a common goal? Was the team larger than 8 people? Was the team isolated from other groups that introduced noise and interruptions? Where there side spaces where people could have privacy for personal tasks or side meetings?

    And as always, people and their social norms matter. If someone has a personal belief that they work best alone then anyone asking people to work together in a shared space will be seen as an attempt a coercion. Hire people that fit a high productivity culture.

    Also some folks are simply bad at a skill called group intelligence. Interestingly individual IQ doesn't directly correlate with the ability for groups to solve problems together. (Three factors here that correlate positively with group intelligence: Are you female? (.4) Can you correctly interpret the faces of others? Do members take turns when talking and listening? (.6))

    People are messy. There are great and effective practices out there, but you may not have the right people or the right implementation to experience the benefits. So fix that. :-)

    ReplyDelete
  29. This comment has been removed by the author.

    ReplyDelete
  30. This presentation contains lots of great advice! I just had an experience which proves a lot of its points: I was pushing hard to try to get a complex mix of Internet telephony technologies to work together, but running into recurring, time-consuming problems. When I finally took a break and stopped pushing, I recognized the real problem: making a large feature set a higher priority than the reliability of core functionality. I solved the problem by getting rid of the whiz-bang features, which resulted in a simpler, but far more reliable system. The moral? I've been "crunching" for too long. It's time for me to work shorter hours and get more done!

    ReplyDelete
  31. I recommend reading "Work Sucks: the Results-Only Work Environment" as further research; it was written by the team at Best Buy that radically changed that company's approach to the work week by abolishing 40 hour requirements and more. The games industry would benefit from taking these developments seriously as well.

    ReplyDelete