How do you adapt traditional project management into a rapidly changing environment? One that is characterised by shifting priorities and high uncertainty. Arguably, you don’t need to – project management has always had the tools for this. But, with the Agile Manifesto of 2001, software projects have a new paradigm. A modification of traditional approaches, called Agile Project Management.
And make no mistake… Agile has become a ‘Big Thing’. In fact, it bears some of the hallmarks of a fad, while also having a lot to offer an informed organisation with wise and pragmatic project leaders to call upon. But, as with all good ideas, it also attracts its converts and zealots.
Of course, here at Management Pocketbooks, we tend to eschew extreme and simplistic ‘right versus wrong’ arguments in management. We’re here to suck out the good stuff and brief you on what it is and how to benefit from it.
Arguably, it is how Nonaka and Takeuchi took some of their thinking forward that has led to a far bigger transformation. In 1985, they co-wrote an article for the January 1986 edition of Harvard Business Review. Called ‘The New New Product Development Game’, this article was instrumental in revolutionising the discipline of Project Management.
Takeuchi and Nonaka gave us a new way of thinking about how to develop products and deliver projects. And they coined an evocative sporting metaphor for their process, which has stuck: Scrum.
Born in 1935, Ikujiro Nonaka gained a BS in political science at Waseda University, then started work at Fuji Electric, where he created their management programme. Nonaka left Fuji in 1967, to study at the University of California, Berkeley. He was awarded his MBA in 1968, and his PhD in Business Administration, in 1972. He took posts at US universities, before returning to Japan, as a professor at the Graduate School of International Corporate Strategy, Hitotsubashi University.
Born in 1946, Hirotaka Takeuchi got his BA from the International Christian University, Tokyo. After a short spell working at McCann-Erickson, he went to the University of California, Berkeley, where he got his MBA in 1971, and his PhD in 1977. During his time at Berkeley, he also worked summers for McKinsey & Company in Tokyo and, more important, met Nonaka.
Takeushi took a lectureship at Harvard in 1976 until 1983, when he joined Hitotsubashi University School of Commerce, where he became a full professor and Dean of the Graduate School of International Corporate Strategy. He stayed until 2010, when he returned to Harvard, as Professor of Management Practice, where he is now.
The New New Product Development Game.
In January 1986, Harvard Business Review published ‘The New New Product Development Game‘ by Takeuchi and Nonaka. This was about a new way to do New Product Development, or NPD. They drew on the idea of ‘ba’ – a Japanese coinage of Nonaka’s, meaning a meeting place for minds and the energy that draws out knowledge and creates new ideas.
They also took a look at the Toyota idea of teams coming together to solve problems. They introduced a sporting metaphor from the game of Rugby; that of the scrum. They used scrum to denote the way teams work together intensively when the ball goes out of play. In a work environment that demands creativity and innovative problem solving, this is just what is needed.
The model they created for Scrum Teams is of a cross functional group that can work autonomously to resolve its own problems. Their organisation is ’emergent’ meaning there is no assigned leadership or structure; it just emerges from the effective collaboration of its members.
To work best, a Scrum Team needs to be co-located, and work together full-time. This allows a high level of cross-fertilisation of ideas, and a dedication to working on their shared problems, tasks, and initiatives.
Scrum as an Agile Project Management Methodology
Agile project management seeks to avoid the all-or-nothing approach to projects that used to characterise traditional approaches – especially when done in a way that slavishly follows a set of ‘rules’. Although good project managers have always incorporated a lot of plan-do-review (the Deming Cycle), the growth of software development projects demanded an increase focus on agility and incrementalism.
In Scrum projects, a Product Owner is responsible for detailing the business requirements and ensuring that the business gets a good return on its product development investment (RoI). The Scrum Team, led by a Scrum Master, selects one subset of functionality from a product backlog of undeveloped functions, divides it into tasks, and works intensively on developing the outputs for a fixed time, known as a Sprint, which is usually 30 days.
Each day, the team gets together for a daily Scrum Meeting to share learning, report progress, discuss challenges, and solve problems. At the end of the sprint, the team should produce a working product that is stable and useful. After a reflection and learning process, the team then works with the product owner to define the subset of functionality it will work on in the next sprint.
The team continues like this until the Product Owner concludes that the next sprint would not create enough additional value to justify the incremental cost.