This is the group photo during last weeks “Nothin But Agile Project Management” course March 3-6th at the Sheraton Eau Claire in Calgary, Alberta. From left to right: Rob from Petro Canada, Maria from Shaw, Me, Nina from CGI, Mark from Petro Canada, Kelly from Hatsize, Wendy from Petro Canada, Jason from IBM, and of course Jonathan the course instructor in front. The course was put on by Jonathan Rasmusson, an active participant in the agile community. Jonathan walked through an entire mock project “Bubble Battle” based on agile project management methodologies and best practices from inception to closing and hand-off. The course was an intense 4 days with workshops and group discussions on agile experiences both good and bad, as well as very important lessons learnt (which I love to hear about). View the rest of the pictures from the course at  http://www.flickr.com/photos/59259399@N00/sets/72157604097180657/. I highly recommend the course to new and existing project managers who want to know more about how agile works and what it looks like because soon I truly believe it won’t be called “Agile Project Management” anymore but instead just “Software Project Management”. Why you ask..? It works, it has proven itself to me, it makes the team happy, it makes clients happier, it reduces waste, it produces high business value software quickly, it continues to improve in whatever ways it can and will not be the same today as it was yesterday and it will be even better tomorrow… I can go on and on but I will stop now :-).

I’ve been practicing Scrum as an agile project management methodology for a while now and in the last year I’ve been lucky and able to implement many grass roots “pure” style methodologies. So, it led me to think “where did Scrum come from” (the software version not a scrum from the sport of Rugby) and what significance it has in influencing the software management/development community? What was it before the likes of DeGrace and Stahl referred to it in Wicked Problems, Righteous Solutions? What was it before Ken Schwaber and Jeff Sutherland used it in their companies then presented a whitepaper on the topic at OOPSLA’95? These questions lead me to this article “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka. The article was published in a 1986 article of The Harvard Business Review. That struck my interest so I immediately ordered it from the original source. The article has this intro:

In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method – as in rugby, the ball gets passed within the team as it moves as a unit up the field.

The article goes onto identifying the 6 characteristics of the holistic approach to new product development.

1. Built-in instability – management sets challenging goals but doesn’t specify exact work plan.
2. Self-organizing project teams – autonomy, self-transcendence, and cross fertilization.
3. Overlapping development phases – Type B, Type C, sashimi, rhythm, and pulse.
4. Multi-learning – multi-level learning and multi-functional learning.
5. Subtle control- self control, group control, and control by love.
6. Organizational transfer of learning – transfer to other divisions and other new product development projects.

For more details you’ll have to read the article (ask me for hard copy). It also mentions many scenarios where the holistic approach to product development many not work such as; requiring constant team effort throughout the development process, scaling to large projects like those in the aerospace business, or in an environment where a genius makes the invention and hands down a well-defined set of specifications for people to follow (in software development AKA “code monkeys” who follow predefined design documents written by a master architect weeks/months prior).

Managerial behavioural changes also need to occur in order for the company to achieve high speed and flexibility. The article points out 3 things that need to change in a company:

1. Companies need to adopt a top management style that can promote the process.
2. A different kind of learning is required. From a depth-based individual learning (highly competent few) to breadth-first group learning across different levels of the organization.
3. Management should assign a different mission to new product development. Most companies treat new product development as a means for future revenue, but sometimes it should be a catalyst to bring about organizational change.

The article references projects from these large multinational companies like Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, and Hewlett-Packard. The original context was in the manufacturing industry but I found it really interesting that for such an old and very rigid process structured on Taylorism that the software industry (which is a lot newer) is behind in times when it comes to updating it’s process engineering methodologies. The manufacturing industry has revolutionized their processes, which is evident in the lean manufacturing principles of the Toyota Production System (TPS), while the software industry is only now (in the last few decades) starting to catch up!

I leave you with the last sentence from the article:

What we need today is constant innovation in a world of constant change