Here are my comments on the book:
How do you increase your productivity to do twice the work in half the time? Dr. Jeff Sutherland, one of the inventors of Scrum software development process, states that the scrum method of planning and executing as opposed to the traditional waterfall method will allow one to significantly increase their productivity levels. The scrum method is a 11-step cycle starting with picking a product owner, followed by picking a team, then a scrum master, and etc. The cycle then ends with a reflective meeting where improvements can be made for future projects. Here are some of the points to the book:
1. I’ve read numerous times that one of the biggest factors of workplace productivity is autonomy, which makes sense as no one likes to be told how to do their job. I believe that this is one of the reasons why Google has been consistently rated the number one place to work in the world as they always value input from their employees. They trust their employees enough to do their work and how they choose to do it as well. This then translates into greater work related satisfaction and creativity. For those of you who run some sort of business where you have employees and want to increase retention, a suggestion would be to stray away from that traditional corporate management style and give them more autonomy. “My team and I spent a few weeks reading hundreds of papers and books and articles on the organization of teams and product development. Then one day, one of the developers came in with a Harvard Business Review paper from 1986, written by two Japanese business professors, Hirotaka Takeuchi and Ikujiro Nonaka. It was titled, “The New New Product Development Game.” Takeuchi and Nonaka had looked at teams from some of the world’s most productive and innovative companies: Honda, Fuji-Xerox, 3M, Hewlett-Packard, and others. They argued that the old way of doing product development, typified by NASA’s Phased Program Planning system—a Waterfall system—was fundamentally flawed. Instead, the best companies used an overlapping development process that was faster and more flexible. The teams were cross-functional. The teams had autonomy. They were empowered to make their own decisions. And they had a transcendent purpose. They were reaching for something bigger than themselves. Management didn’t dictate. Instead, executives were servant-leaders and facilitators focused on getting obstacles out of their teams’ way rather than telling them what and how to do product development. The Japanese professors compared the teams’ work to that of a rugby team and said the best teams acted as though they were in a scrum: ‘…the ball gets passed within the team as it moves as a unit up the field.’“
2. Work in small groups. By working in small groups, you cut down on the number of communication channels amongst members which translates into greater efficiency through less waste. This is exactly how Amazon and Google operate. For Jeff Bezos, founder of Amazon, he’s got something called the ‘two-pizza team’ model which states that teams should be small enough to be fed by two pizzas. If the big players are doing it, something’s working well. “The team dynamic only works well in small teams. The classic formulation is seven people, plus or minus two, though I’ve seen teams as small as three function at a high level. What’s fascinating is that the data shows that if you have more than nine people on a team, their velocity actually slows down. That’s right. More resources make the team go slower. In software development there’s a term called “Brooks’s Law” that Fred Brooks first coined back in 1975 in his seminal book The Mythical Man-Month. Put simply, Brooks’s Law says “adding manpower to a late software project makes it later.”8 This has been borne out in study after study. Lawrence Putnam is a legendary figure in software development, and he has made it his life’s work to study how long things take to make and why. His work kept showing that projects with twenty or more people on them used more effort than those with five or fewer. Not just a little bit, but a lot. A large team would take about five times the number of hours that a small team would. He saw this again and again, and in the mid-1990s he decided to try to do a broad-based study to determine what the right team size is. So he looked at 491 medium-size projects at hundreds of different companies. These were all projects that required new products or features to be created, not a repurposing of old versions. He divided the projects by team size and noticed something right away. Once the teams grew larger than eight, they took dramatically longer to get things done. Groups made up of three to seven people required about 25 percent of the effort of groups of nine to twenty to get the same amount of work done. This result recurred over hundreds and hundreds of projects. That very large groups do less seems to be an ironclad rule of human nature.“
3. When problems arise, fix it before moving on as it’ll create even more problems in the future. This is one of the reasons why Toyota, at one point, was able to significantly reduce their defect rate. Toyota gave their employees on the automotive line to stop the whole line of cars to fix any spotted defects. The logic behind this was that if that particular car had that defect, other cars potentially would have it too. When you spot a problem, fix it before it causes even more problems. “This tendency—for the process of fixing things to get harder as more time elapses—represents a similar limitation. When you’re working on a project, there’s a whole mind space that you create around it. You know all the different reasons why something is being done. You’re holding a pretty complicated construct in your head. Re-creating that construct a week later is hard. You have to remember all the factors that you were considering when you made that choice. You have to re-create the thought process that led you to that decision. You have to become your past self again, put yourself back inside a mind that no longer exists. Doing that takes time. A long time. Twenty-four times as long as it would take if you had fixed the problem when you first discovered it. I’m sure you’ve had this experience yourself in your own work, and the lesson is one you were probably taught as a child: Do things right the first time. The only thing the data now adds is that if you do make a mistake—and we all make them—fix it as soon as you notice it. If you don’t, you’ll pay for it.“
By Ryan Timothy Lee
Thank you for reading! Please join my Facebook group here, like the post, or share it.
Check out the book here: