Software Engineering, Project Management, and Effectiveness
Daniel Cook has a great PDF on the 8 Laws of Productivity. The subtitle is “8 Productivity Experiments You Don’t Need to Repeat.”
It’s the synthesis of Dan’s learnings and research over the years on how to create more productive teams.
Right up front, Dan defines productivity as work accomplished, minus work required to fix defects, and minus work required to fix bad design decisions. He adds that it’s possible for productivity to be negative when workers end up doing more harm than good. Dan says, “People commonly measure ‘what was accomplished’, but often this is a poor measure of productivity. It is possible to check in code and design decisions that must be later fixed or removed at great cost. If you only measure work accomplished, you could generate great ‘productivity’ numbers but never ship a working product. The real measure of productivity is valued working code in customer hands.”
Here are the 8 Laws of Productivity according to Cook:
What happens if you try to improve productivity by working longer, either through more hours in a week, or more hours in a day?
Cook summarizes the results: <40 hours and people aren't working enough > 60 hour work week gives a small productivity boost The boost lasts 3 to 4 weeks and then turns negative
Cook tells us that according to Ford, and 12 years of experimentation, 40 hours was the most effective.
Interestingly, an early XP practice was 40 Hour Week, before it became Sustainable Pace. The main idea is that "productivity does not increase with hours worked."
A key point here is that "After a certain tipping point, teams tend to be more destructive than productive." (see InfoQ on Sustainable Pace)
I've experience the benefits of a 40 hour work week and wrote about it in 40 Hour Work Week at Microsoft.
An interesting data point is that 6 of the top 10 competitive economies prohibit employees from working over 48 hours/week. (See MBA on Bring Back the 40 Hour Work Week.)
What happens if we work harder in bursts? Can we take advantage of the burst that comes from working overtime? What happens if we crunch for a week and then 'only' 40 hours for another week? Are there other patterns of scheduling work that might be more efficient?
Cook summarizes the results:
Do the same rules apply to creativity and problem-solving as manual labor?
Cook summarizes the results: Studies show that creativity and problem solving decreases faster with fatigue than manual labor. Grinding out problems by working longer on average result in inferior solutions. Lack of sleep is particularly damaging.
If many workers self-report that they are the exception to the rule and can work longer with no ill effects, and overtime workers report they are getting more done, is this true?
Cook summarizes the results of measurements where Team A works overtime and Team B does not: Team A feels like they are doing much more than Team B. Yet, Team B produces the better product.
Does productivity change for various team sizes and which size team produces the best product?
Cook summarizes the results: Productivity for small groups is shown to be 30-50% higher than groups over 10 Cost of communication increases dramatically for groups larger than 10 Smaller groups don't have enough breadth to solve a wide array of problems well
Interestingly, the Navy Seal create super teams with teams of 4.
What is the most productive physical work environment? Are cubes, individual offices or team rooms most effective? Every individual has an opinion, but what is best for the team?
Cook summarizes the results: Studies show 100% increase in productivity Being nearby means faster communication and problem-solving Few external interruptions to the team (not the individual) means higher productivity
How should workers of different disciplines be organized? Should teams be composed of a single discipline? For example, all programmers or all artists? Or should teams be mixed?
Cook summarizes the results: Cross-functional teams produced more effective solutions in the same time Cross-functional teams have more likelihood of generating breakthrough solutions There is some negotiation of norms of front, but this is a short-term loss
What percentage of team capacity should be officially scheduled? 110% to promote people to 'stretch'? 100% because that's what they can do? 80% because slacking is good?
Cook summarizes the results: Scheduling people at 100% doesn't give space to think of creative solutions Not lost time: Passionate workers keep thinking The 20% goes into new idea generation and process improvements Producing 20 great features is usually far more profitable than producing 100 competent features
Dan included some of his research sources:
Crunch in the Game Industry IGDA - Articles - Why Crunch Mode Doesn't Work: 6 Lessons - http://www.igda.org/articles/erobinson_crunch.php InfoQ - Why Crunch Mode Doesn't Work, by Ben Hughes - http://www.infoq.com/news/2008/01/crunch-mode
Best Team Size Is Your Team Too Big? Too Small? What's the Right Number? - http://knowledge.wharton.upenn.edu/articles.cfm?articleid=1501 Team Performance and Team Size - http://www.teambuildingportal.com/articles/systems-approaches/teamperformance-teamsize.php
Sickness and Overtime Correlation Relationship between self-reported low productivity and overtime working - http://cat.inist.fr/?aModele=afficheN&cpsidt=15461524
Prioritization First Things First (book) - http:///en.wikipedia.org/wiki/First_Things_First_(book)
4 Day Work Week Alternative Work Schedules and Work–Family Balance: A Research Note - http://rop.sagepub.com/cgi/reprint/28/2/166
Team Spaces "Rapid Software Development Through Team Collocation" IEEE Transactions on Software Engineering, Volume 28, No. 7, July 2002
INFOQ: Does Sustainable Pace Mean a 40 Hour Work Week?
MBA on Bring Back the 40 Hour Work Week (Info Graphic)
40 Hour Week (C2 Wiki)
10 Big Ideas from Getting Results the Agile Way
40 Hour Work Week at Microsoft
How I Use Agile Results