Japanese Origins of SCRUM

I'm going to be giving a presentation tomorrow to my work colleagues on the origins, concepts and philosophy of the agile project framework called Scrum. As I am currently taking weekend classes as well as self studying for the PMP certification exam, the whole topic of project management has been on my mind quite a bit. Studying the traditional project management methodology of PMI in conjunction with research into Scrum for my presentation, has been an interesting study into the contrasting views with respect to project management from both sides.

This is not to say that either is right or wrong, or better than the other, but one is geared toward the dynamic and ever changing nature of software development [Scrum], whereas the other is a general framework for ALL kinds of project management endeavors. A blog for a book I just purchased, called "Head First PMP" acknowledges this, as they state "the PMBOK wasn’t written specifically for developers. A lot of projects that use the PMBOK processes and principles are things that you can’t do iteratively — like, say, highway construction or building a skyscraper... These are things that Agile doesn’t address because they’re just out of its scope."

The most interesting thing that though, that was revealed in my research into Scrum, was a reference to a paper by Hirotaka Takeuchi and Ikujiro Nonaka titled "The New New Product Development Game" which was referenced in the original book by Ken Schwaber titled quite appropriately "Agile Software Development with SCRUM". Published in the Harvard Business Review in 1986 it was a landmark paper and had many ideas in it that are now quite fashionable both in Agile project management and the general business landscape as well.

On the very first page is where the Scrum metaphor is defined as "a holistic or 'rugby' approach — where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements." But to simple assign this paper as the backdrop for how Scrum got it's metaphorical name, is to do a disservice to a short paper with some very profound ideas on management.

They highlight 6 main aspects to their management framework, which include the following:

1. Built-in instability
2. Self-organizing project teams
3. Overlapping development phases
4. “Multilearning”
5. Subtle control
6. Organizational transfer of learning

Any one of these topics could be a whole research thesis on their own, but they are at pains to emphasize that all these ideas must be taken as a whole and have full involvement from both the implementors and management at all levels. This is in agreement with the Agile community, especially with its emphasis on customer involvement since without their deep involvement and commitment, the whole notion of phased deliverables would not be possible.

I like Takeuchi and Nonaka's very modern ideas of employee autonomy and self transcendence that is achieved with self organizing teams. As they state "the project teams appear to be absorbed in a never-ending quest for 'the limit.' Starting with the guidelines set forth by top management, they begin to establish their own goals and keep on elevating them throughout the development process. By pursuing what appear at first to be contradictory goals, they devise ways to override the status quo and make the big discovery."

There are many other modern ideas such as giving employees an allocated time away from work to pursue independent research much like Google does today. The site 3M at the time who "encourages engineers to devote 15% of their company time to pursuing their 'dream.'" I would definitely appreciate my company encouraging such a thing!

I especially think their ideas of "multileaning" or what we would now call "cross functional" teams is a pretty important idea. There's a problem especially in the technical fields such as software development, where developers can get compartmentalized into a specific role and tagged as being the "Java guy/gal" or "DB guy/gal" and pretty much do nothing but that. This not only leads to burn out, but also keeps them aloof and completely ignorant of what other team members are doing. This is not to say that Designers should start coding C# or Business Analyst to build web pages, but using something like pair-programming with pairs from different departments would allow teams to better understand and appreciate what the other members do as well as picking up and possibly taking on a new skill set they might otherwise have not know they had an interest in.

In the final paragraph, they conclude "multinationals must achieve speed and flexibility in developing products; to do so requires the use of a dynamic process involving much reliance on trial and error and learning by doing. What we need today is constant innovation in a world of constant change." This was stated more than 20 years ago, but is more relevant today and will be so for the foreseeable future. It's has been both enlightening as well as a little sad that many companies then and today have yet to come to grips with this.

I highly recommend getting a copy of this paper and referring to it periodically if you are in involved in project management or any kind of business for that matter.