Book Review: The Art of Doing Twice the Work in Half the Time

Jeff Sutherland is one of the founders of Scrum, a methodology for agile software development. But even if you are not involved full time in software development, The Art of Doing Twice the Work in Half the Time (Crown Books, 2014) is a quick and easy read that attempts to educate a general manager about the virtues of agile development and apply the principles to non-software development projects.

The idea behind Scrum is simple. Projects are difficult. People have no success in defining requirements up front. So, the alternative process is to phase and iterate the project, something I wrote about in our book, Riding The Tiger, back in 1997. Even more importantly, the goal in any project is to get better. Delivery of the phase needs to be accompanied by figuring out what you can do better and what roadblocks can be removed.

Why should you care about agile project management? The simple answer as the title implies is that you get more work done in less time. The book title claims a 4X improvement. Other scrum specialists suggest 8X improvement is not unreasonable particularly in software where at the end of each Sprint, reviewing opportunities for improvement is part of the scrum process.

The book is filled with illustrations of projects where the simplification of scrum product results from IT projects at Medco to home renovation. In a story that we can all relate to, Sutherland tells the story of two projects on identical home renovation projects. The Scrum approach took 6 weeks. The non-Scrum approach with the same team took three months.

The principles behind Scrum are easy to understand. You have three roles: Product Owner, Scrum Master and project team. The product owner's job is to be ruthless in prioritizing what needs to be done. The Scrum Master's role is to make sure that roadblocks are removed. The team is a self organizing team that takes responsibility for delivering what they have agree to deliver in each phase or Sprint.

There is however, a philosophical twist to scrum. It's open management. As with kanban, project work is always on display, categorized as backlog, being worked on or completed. Making information visible makes it harder for managers to play political games, conceal lack of progress or demand extra work.

Scrum is also psychologically sophisticated. It assumes that your motivation is affected by your control over your work. It also denies the "sweat shop" assumption that keeping people busy all the time and demanding overtime is the best way of keeping productivity. That may have been true in a textile factory in the 19th century, but it's not true for knowledge workers. Underscheduling people gives them time to work at higher quality, help each other and generate higher levels of team equality.

There are many good books about Scrum. Mike Cohn, Kenneth Rubin and Ken Schwaber have excellent books on the subject, but Jeff Sutherland's book is a good recommendation if you need to educate a manager about a new approach to project management.

Interesting Data on Agile Development from Rally

Interesting Data on Agile Development from Rally

I attended a useful presentation from Rally Software last night in downtown San Francisco.

The presentation focused upon the results of research into almost 10,000 agile teams and their characteristics, an ongoing project of Larry Macherone, Director of Research at Rally.

Rally is now reporting from its database of projects on four key dimensions of performance:

1. Responsiveness (based on Time in Process or Time to Market).
2. Quality: (defect density based on defect count divided by person-days)
3. Productivity: based on throughput/divided by team size (user stories and effects completed in a given time period).
4. Predictability: based upon throughput variability (standard deviation of throughput over three monthly periods divided by average for 3 months).

Relationships Emerging

- Productivity is correlated with whether the team is dedicated to the project. The higher the dedication, the higher the productivity.

- Quality, as measured by defects is higher for teams spending less than 50% of their time on the project.

- Team stability tends to be quite low in the sample data, which likely has a major overall effect because stable teams have 60% better productivity, 40% better predictability and 60% better responsiveness.

- Teams that do "full Scrum" i.e. estimating story points and task hours have 250% better quality, but teams that do lightweight Scrum, using story points alone perform better overall with better productivity, predictability and responsiveness.

-Teams that aggressively control work in progress cut process time in half, have only 25% as many defects, but have 34% lower productivity.

- Teams with 7 members plus or minus 2 provide the most balanced performance. Smaller teams of 1-3 have 17% lower quality but 17% more productivity, presumably due to less time spent communicating.

As Larry pointed out in his presentation, metrics are easily abused. Story points are easy to count, but make no allowance for stakeholder satisfaction, value for end user, or other quality metrics.

Nonetheless the presentation is worth reviewing.

Teamwork Brilliance

Teamwork Brilliance

I recently watched a presentation by Ed Hoffman, Chief Knowledge Officer at NASA. His presentation has many good points about project management with knowledge workers, but perhaps the most interesting, and dare I say brilliant approach used in the Cassini/Huygens project to visit Europa, one of Saturn's moons is how architecture and resource allocation was managed.

The problem in brief is that a space mission, must rather like a modern smartphone, deal with tradeoffs between weight, energy consumption, budget and data transmission rates. With 18 or so projects from 17 countries, the normal practice would be that three or four projects would be dropped, because they would be ranked at the bottom of the list.

But in a highly complex project that consists of hundred of scientists and varying degrees of flexibility with respect to technical characteristics and budget available, the NASA project team realized that a formal system for managing trade-offs might benefit from a market place. So they constructed a market, where individual project teams could make trade-offs. Some projects could do with less weight if it they were allowed to spend more for example. The net result of this teamwork inducing allocation approach was the unusual result of all the projects ending up in the mission.

And of course, it's very motivating when this kind of pattern of resource allocation reassures scientists and engineers that their work and careers will benefit.

Quite simply brilliant. There are, I think, lessons here, for architecture, scrum and agile development generally.