Tag: T-Shaped skills

Article Review: The New New Product Development Game

A look back at a 1986 Harvard Business Review article provides insight into the roots of Agile and its application.

No, there isn’t a typo in the title. 🙂  The title of this blog entry was taken (borrowed?) from a very interesting article published in the Harvard Business Review from January 1986.  Scaled Agile Inc. (the developers of SAFe) references it to make a number of points concerning how to best structure Agile teams.  In particular, Scaled Agile Inc. references the article’s assertion that:

  1.   The “relay race” approach to product development [i.e., Waterfall] conflicts with the need for speed and flexibility.
  2.   That a holistic or “rugby” approach [a la Agile] where, “a team tries to go the distance as a unit, passing the ball back and forth” better serves highly competitive environments.

The things that strike me about this article are:

  1.   It was published in January 1986.  A good 15 years before the Agile Manifesto was published.
  2.   All of the examples are product development efforts outside the software development realm:  Xerox copiers, HP printers, Honda cars, Canon cameras.
  3.   The fact that they likened the process to Rugby (a foreshadowing of Agile-Scrum).
  4.   The focus on self-organizing teams – A major item in the list of Principles of the Agile Manifesto:  “The best architectures, requirements, and designs
    emerge from self-organizing teams.”
  5.   Encouragement of contributor autonomy – A major component of the SAFe principle of unlocking the “intrinsic motivation of knowledge workers.”
  6.   Fostering of “Self-transcendence” – Similar to the concept of Ba: an old Lean term brought to new relevance in Agile-Scrum and SAFe circles.
  7.   Emphasis on “Cross-fertilization,” known in Agile as “Cross Functional Teams.”
  8.   The article’s concept of “Overlapping development phases” roughly translates into the Agile idea that SDLC phases (planning, analysis, design, implementation, and maintenance) should not be separate phases at all but should, instead, be performed concurrently within a specified time-box (iteration/sprint), on a small scope of work, with overall system scope accruing incrementally and iteratively.
  9.   The recognition that for all of this to work, we need management to change away from linear and static product development thinking.
  10.   The recognition that, “A different kind of learning is needed.”  By this they mean engineers need to have both deep skills and broad understanding to be effective in cross-functional teams that execute in less structured environments:  “T-shaped skills.”

I recommend organizational leaders and managers read the article to gain perspective on the thinking that led to Agile, so they may better understand how to adopt it within their respective organizations.  Engineers of all disciplines and current Agilists will also benefit from a better understanding of how real cross-functional, self-organized teams are formed and behave.