Loading ...
Sorry, an error occurred while loading the content.

Takeuchi and Nonaka's limitations (Was: Scrum without ScrumMaster)

Expand Messages
  • Wouter Lagerweij
    Hi Ged, Interesting question! My understanding of that article is that is describes a number of situations where companies went through a marketly different
    Message 1 of 1 , Dec 15, 2011
      Hi Ged,

      Interesting question!

      My understanding of that article is that is describes a number of situations where companies went through a marketly different product development cycle than they were used to doing, and found some great advantages. The article does describe those companies as in need of drastic change, and in fact specifically mentions that as a success factor ('can be legitimized in a time of war').

      Scrum was based on these ideas (and others!), but very specifically meant to be used during normal operations. (at the famous sustainable pace)

      In that light, let's look at those limitations:

      On Thu, Dec 15, 2011 at 1:03 PM, Ged Byrne <ged.byrne@...> wrote:
      My understanding is that it is based on Takeuchi and Nonaka's "The New New Product Development Game".  Within the 1986 Havard Business Review article the authors urged caution because of the approach's limiitations:
      Some words of caution are in order.  The holisitc approach to product development may not work in all situations.  It has some built in limitations:
      •   * It requires extraordinary effort on the part of all project members...
      They actually mention 60-100 hours of overtime a month (that would make for 50 to 60 hour workweeks?). That is not our goal, but can be understood from the 'company in trouble' point of view.
      Not necessary! Note that the rest of the article does stress (...) the need for balance between letting go, but setting challenging goals. I think that is something that does come back in Scrum. 
      •   * It may not applyl to breakthrough projects that require a revolutionary innovation...
      I'm not sure I agree with this. It seems too based on the 'revolutionary ideas come from lone inventors' misconception. Especially if you allow for a good amount of failure, and use some sort of set-based design, your chances of finding something really new should be larger than normal.
      •   * It may not apply to mammoth projects like those in the aerospace business...
      This is certainly true. As you can see from the literature around Scrum and Agile, scaling those concepts can be hard. You have limits to the effectiveness of your communications, for instance. Working around those limits is where we're learning:-) Mostly, though, the same problem would exist in a more classically run project, except that there the limited forms of communications are accepted as normal.
      •   * It may not apply to organisations where product development is masterminded by a genius.
      Well, genius is sparsely spread. (Present company excepted, of course.) And even then will also make mistakes. Not too worried about that one. Of course, those situations where it is run by someone who *thinks* he's a genius could be *real* trouble...
       Scrum, however, acknowledges no limitations to it's applicability:

      Rethink what Scrum could mean for your complex project. Whether you're building the next ipad app, shipping dog food across the country, or running a charity event, Scrum can help. Scrum offers benefits for any kind of team, including improved teamwork, better communication, and faster results.

      What is the difference between Scrum and the New New Product Development Game that removes all of the limitations observed by Takeuchi and Nonaka?

      I'm not trolling, I would genuinely like to know.

      Is it the application of the Skunkwork's approach, so that an appropriately sized dedicated team of individuals can be produced from even the most sprawling and centralised of organisations?

      One of the differences between what's described in that paper and Scrum is that in Scrum (and Agile in general), the feedbck loops are usually much shorter. Even in a large project, there is supposed to be continuous adjustment of requirements because the customer can see intermediate results. In software, this is much easier than in manufacturing. This makes the learning process much quicker.

      As we discussed earlier, combining such a process with practices to assure high quality works very well, even when not combined with 'hand-picked' teams. Good people wlll always help, though:-)


      Wouter Lagerweij         | wouter@...
    Your message has been successfully submitted and would be delivered to recipients shortly.