Posted on: July 10, 2026 12:07 AM |
Permalink
Celebrating 40 Years of Scrum: Revisiting the Origins, Achievements, and Overlooked Limitations
About this Blog
RSS
Recent Posts
The Ethics of Externalising Risk: Rethinking “Fail Fast” and MVP in Product Development
Quantum Physics for Year 3: Agile success as a foundation for AI. An Ethical reflection
The Tribe Agile Coach role and the spirit and values of the Agile Manifesto. An ethical reflection
Navigating the Ethical Landscape of Project Management: Insights and Recommendations
Categories
Agile, Artificial Intelligence, Benefits Realization, Change Management, Communications Management, Complexity, Consulting, Decision Making, Disciplined Agile, Diversity, Earned Value Management, Estimating, Ethics, General, Governance, History, Innovation, Knowledge Management, Leadership, Lessons Learned, Metrics, Organizational Culture, Product Management, Risk Management, Scope Management, Scrum, Social Impact, Stakeholder Management, Teams, Testing/Test Management, Using PMI Standards
Date
Comments (9)
Please login or join to subscribe to this item
Important reflection. I would add one historical and conceptual distinction.
Takeuchi and Nonaka’s article was published in 1986, so 2026 marks its 40th anniversary. The 30-year milestone more accurately refers to the 2025 anniversary of Scrum’s formal public presentation at OOPSLA in 1995.
Their research supplied an important source of inspiration and several contextual warnings, but it did not describe the Scrum framework that was later formalized and subsequently evolved through its own history and definitions.
The limitations of the holistic product-development cases they observed should therefore not automatically be treated as built-in limitations of Scrum itself. Some remain highly relevant warnings about context, scale, sustainability and cultural transfer. Others need to be reassessed against what Scrum later became and what the framework actually claims to address.
Perhaps the deeper lesson is not simply that Scrum has hidden limitations. It is that a team-level framework becomes misleading when organizations expect it to solve problems of enterprise governance, large-scale integration, scientific discovery or organizational design on its own.
Honouring the full legacy requires examining both the original research and the framework that followed, preserving the inspiration between them without treating them as the same object.
Takeuchi and Nonaka’s article was published in 1986, so 2026 marks its 40th anniversary. The 30-year milestone more accurately refers to the 2025 anniversary of Scrum’s formal public presentation at OOPSLA in 1995.
Their research supplied an important source of inspiration and several contextual warnings, but it did not describe the Scrum framework that was later formalized and subsequently evolved through its own history and definitions.
The limitations of the holistic product-development cases they observed should therefore not automatically be treated as built-in limitations of Scrum itself. Some remain highly relevant warnings about context, scale, sustainability and cultural transfer. Others need to be reassessed against what Scrum later became and what the framework actually claims to address.
Perhaps the deeper lesson is not simply that Scrum has hidden limitations. It is that a team-level framework becomes misleading when organizations expect it to solve problems of enterprise governance, large-scale integration, scientific discovery or organizational design on its own.
Honouring the full legacy requires examining both the original research and the framework that followed, preserving the inspiration between them without treating them as the same object.
Thank you for observing the 'mistake'. I wanted to see if there is someone else who knows that Scrum was defined in 1986.
IIMHO, the Scrum defined in the Scrum Guide is a kaizen implementation in software development.
I fully agree that we should honour the legacy, at least by mentioning that Scrum was originally a scientific research, not a certification scheme.
IIMHO, the Scrum defined in the Scrum Guide is a kaizen implementation in software development.
I fully agree that we should honour the legacy, at least by mentioning that Scrum was originally a scientific research, not a certification scheme.
Thank you, Stelian.
I think we are very close in our interpretation.
My only distinction is between the 1986 research that inspired Scrum and the framework that was later formalized.
Preserving both histories, while keeping them conceptually distinct, helps us better understand both the original contribution of Takeuchi and Nonaka and the subsequent evolution of Scrum itself.
I also agree that Scrum shares important characteristics with continuous improvement.
I was particularly interested in your reference to Kaizen.
Do you see that relationship as something historically documented by Scrum's creators, or as a conceptual interpretation based on the similarities between the two?
I have generally understood them as related, while remaining historically and conceptually distinct, so I would genuinely be interested in hearing your perspective.
I think we are very close in our interpretation.
My only distinction is between the 1986 research that inspired Scrum and the framework that was later formalized.
Preserving both histories, while keeping them conceptually distinct, helps us better understand both the original contribution of Takeuchi and Nonaka and the subsequent evolution of Scrum itself.
I also agree that Scrum shares important characteristics with continuous improvement.
I was particularly interested in your reference to Kaizen.
Do you see that relationship as something historically documented by Scrum's creators, or as a conceptual interpretation based on the similarities between the two?
I have generally understood them as related, while remaining historically and conceptually distinct, so I would genuinely be interested in hearing your perspective.
Hi Luis
I don't know if Jeff and Ken have hands-on experience with Lean Six Sigma, but initial versions of the Scrum Guide introduced the framework as a process improvement approach: "Scrum Teams are designed to optimize flexibility and productivity". There is also no evidence that the Harvard research paper inspired the Scrum framework.
Like most Agile frameworks that become part of the certification circus, Scrum evolved from a productivity tool to a prescriptive process. SAFe was born from the author's exposure to Lean Six Sigma at Motorola; DA was initially a Lean Agile framework. IMHO, the only true Agile framework was XP, unfortunately survived by the worst concepts introduced: Story Points and burndown chart.
I don't know if Jeff and Ken have hands-on experience with Lean Six Sigma, but initial versions of the Scrum Guide introduced the framework as a process improvement approach: "Scrum Teams are designed to optimize flexibility and productivity". There is also no evidence that the Harvard research paper inspired the Scrum framework.
Like most Agile frameworks that become part of the certification circus, Scrum evolved from a productivity tool to a prescriptive process. SAFe was born from the author's exposure to Lean Six Sigma at Motorola; DA was initially a Lean Agile framework. IMHO, the only true Agile framework was XP, unfortunately survived by the worst concepts introduced: Story Points and burndown chart.
Luis, I was around when software development was done by internal teams, unstructured and without any management skills. And yet, we built the entire software infrastructure for large enterprises. I learned XP in 2000, by accident, because my company decided to train us, but most of the Agile practices were around for decades. I believe that the OO, especially c/c should be credited for how software development is done today more than any Agile framework.
Before moving to project management, I was managing a software company with 97 excellent developers. Compared with what I do in a project, it was a walk in the park. Scrum and SAFe are NOT project management tools, and the bastardised kanban is something that is neither Lean nor Agile. To their credit, the XP authors didn't create a certification and did not develop new versions. Scum ceased to be Agile when the Scrum Master role became the replacement for a project manager.
Before moving to project management, I was managing a software company with 97 excellent developers. Compared with what I do in a project, it was a walk in the park. Scrum and SAFe are NOT project management tools, and the bastardised kanban is something that is neither Lean nor Agile. To their credit, the XP authors didn't create a certification and did not develop new versions. Scum ceased to be Agile when the Scrum Master role became the replacement for a project manager.
Thank you, Stelian. I appreciate you sharing your perspective and experience.
I think we may be approaching the discussion with slightly different objectives. My questions were not intended to challenge your broader views on Scrum, XP or Agile. They were simply aimed at distinguishing between historical evidence and conceptual interpretation.
I was particularly interested in two points that I don't think we have yet clarified.
First, whether there is documented historical evidence that Scrum's creators explicitly associated the framework with Kaizen, or whether that relationship is better understood as a conceptual interpretation based on the similarities between the two.
Second, I was interested in the historical basis for your statement that the 1986 Takeuchi and Nonaka paper did not inspire the later development of Scrum, as I have come across sources suggesting otherwise.
If you are aware of primary sources addressing either point, I would genuinely appreciate the opportunity to read them. I always find it valuable to compare different historical sources and interpretations.
I think we may be approaching the discussion with slightly different objectives. My questions were not intended to challenge your broader views on Scrum, XP or Agile. They were simply aimed at distinguishing between historical evidence and conceptual interpretation.
I was particularly interested in two points that I don't think we have yet clarified.
First, whether there is documented historical evidence that Scrum's creators explicitly associated the framework with Kaizen, or whether that relationship is better understood as a conceptual interpretation based on the similarities between the two.
Second, I was interested in the historical basis for your statement that the 1986 Takeuchi and Nonaka paper did not inspire the later development of Scrum, as I have come across sources suggesting otherwise.
If you are aware of primary sources addressing either point, I would genuinely appreciate the opportunity to read them. I always find it valuable to compare different historical sources and interpretations.
Hi Luis
1) There is no evidence that the Scrum Guide creators had exposure to kaizen or Lean Six Sigma. My opinion is solely based on my experience with Lean Six Sigma.
2) Ken's article references the Harvard research only as the inspiration for the name SCRUM. Scrum (SCRUM) was introduced as developed based on his experience with software development, especially OOP. "Our new approach to systems development ... is an enhancement of the iterative and incremental approach to delivering object-oriented software initially documented by Pittman and later expanded upon by Booch." IMHO, Takeuchi and Nonaka studied the product development process, from a managerial point of view, not (object-oriented) software development from a developer's perspective.
1) There is no evidence that the Scrum Guide creators had exposure to kaizen or Lean Six Sigma. My opinion is solely based on my experience with Lean Six Sigma.
2) Ken's article references the Harvard research only as the inspiration for the name SCRUM. Scrum (SCRUM) was introduced as developed based on his experience with software development, especially OOP. "Our new approach to systems development ... is an enhancement of the iterative and incremental approach to delivering object-oriented software initially documented by Pittman and later expanded upon by Booch." IMHO, Takeuchi and Nonaka studied the product development process, from a managerial point of view, not (object-oriented) software development from a developer's perspective.
Thank you, Stelian. I appreciate you taking the time to clarify your perspective.
I think our discussion highlights an important historical distinction. The 1995 paper clearly presents Scrum as an enhancement of iterative and object-oriented software development, so it would be inaccurate to portray the 1986 Takeuchi and Nonaka paper as a complete blueprint for the framework that followed.
At the same time, I would also hesitate to reduce the 1986 paper to the origin of the name alone. It is cited in the 1995 publication, and Jeff Sutherland has subsequently described it as one of the important inspirations for the first Scrum implementation, alongside his own software development experience and other influences.
More broadly, I see a parallel with the relationship between the Toyota Production System and what later became known internationally as Lean. The production system existed long before researchers at MIT introduced the term "Lean". Likewise, Takeuchi and Nonaka's research and the Scrum framework are historically connected, but they are not the same object.
Perhaps the broader lesson is that the history of management ideas is rarely linear. Frameworks seldom emerge from a single source. They usually evolve through the integration of multiple streams of research, professional practice and subsequent conceptual refinement.
Preserving those distinctions does more than clarify Scrum's history. It reminds us that understanding the evolution of management knowledge requires distinguishing historical evidence from conceptual interpretation, and original inspiration from subsequent development. Maintaining those distinctions allows us to honour both the original contribution of Takeuchi and Nonaka and the framework that Scrum ultimately became.
I think our discussion highlights an important historical distinction. The 1995 paper clearly presents Scrum as an enhancement of iterative and object-oriented software development, so it would be inaccurate to portray the 1986 Takeuchi and Nonaka paper as a complete blueprint for the framework that followed.
At the same time, I would also hesitate to reduce the 1986 paper to the origin of the name alone. It is cited in the 1995 publication, and Jeff Sutherland has subsequently described it as one of the important inspirations for the first Scrum implementation, alongside his own software development experience and other influences.
More broadly, I see a parallel with the relationship between the Toyota Production System and what later became known internationally as Lean. The production system existed long before researchers at MIT introduced the term "Lean". Likewise, Takeuchi and Nonaka's research and the Scrum framework are historically connected, but they are not the same object.
Perhaps the broader lesson is that the history of management ideas is rarely linear. Frameworks seldom emerge from a single source. They usually evolve through the integration of multiple streams of research, professional practice and subsequent conceptual refinement.
Preserving those distinctions does more than clarify Scrum's history. It reminds us that understanding the evolution of management knowledge requires distinguishing historical evidence from conceptual interpretation, and original inspiration from subsequent development. Maintaining those distinctions allows us to honour both the original contribution of Takeuchi and Nonaka and the framework that Scrum ultimately became.
Luis, I think that we are on the same page. With all due respect, although Jeff remains a significant contributor to the approach proposed by Ken, in my opinion, he is also one of the main reasons for the apparition of the Scrum certification circus.
I remember the introduction to the PSM certification. A good intention, but money talks, and nowadays, PSM is no different from CSM.
I've been in software development for over 40 years. In Romania, we had no exposure to OOPSLA or other consultant-led conferences, but we did what decades later would be called Agile.
In my experience, the Agile enablers were not the frameworks. In 2001, the only framework widely used in the industry was XP, a framework that is survived by its worst practices: story points and velocity/burndown chart. I believe that the real enablers were the pC and the object-oriented languages. In the mid-80s, I moved from FORTRAN on PDP11 to c/c on PC. It was not only a different way of coding but a different way of thinking and designing software. That thinking and the easiness to build new versions of software required a new structure/management. Like Lean Six Sigma, born from the needs of mass production, the MASD version of Agile was born from the need to bring some order into the chaos when software development became building HTML pages :)
I remember the introduction to the PSM certification. A good intention, but money talks, and nowadays, PSM is no different from CSM.
I've been in software development for over 40 years. In Romania, we had no exposure to OOPSLA or other consultant-led conferences, but we did what decades later would be called Agile.
In my experience, the Agile enablers were not the frameworks. In 2001, the only framework widely used in the industry was XP, a framework that is survived by its worst practices: story points and velocity/burndown chart. I believe that the real enablers were the pC and the object-oriented languages. In the mid-80s, I moved from FORTRAN on PDP11 to c/c on PC. It was not only a different way of coding but a different way of thinking and designing software. That thinking and the easiness to build new versions of software required a new structure/management. Like Lean Six Sigma, born from the needs of mass production, the MASD version of Agile was born from the need to bring some order into the chaos when software development became building HTML pages :)
Please Login/Register to leave a comment.
ADVERTISEMENTS
|
It is wonderful to be here in the great state of Chicago. - Dan Quayle |
