Project Management

Scrum is NOT Agile

From the Agility and Project Leadership Blog
by
A contrarian and provocative blog that goes beyond the traditional over-hyped dogma of "Agile", so as to obtain true agility and project leadership through a process of philosophical reflection.

About this Blog

RSS

Recent Posts

Has Scrum outlived its usefulness? Should Scrum just go away?

The rise of Agile’s SAFe is like a bad episode of the movie Groundhog Day

Marcel Proust’s recursive novel: Why the concept of iteration in Agile is shortsighted

Forecast for 2015: The beginning of the end of Agile?

Google considered the best US company to work for due to HR agility



Anyone involved with Agile hears that Scrum is the most popular project management method within the umbrella of Agile practices.  But Jim Coplien (one of the chief founders of the Design Pattern movement) argues that Scrum’s root is really not from Agile, but rather the Toyota Production System (TPS).  I’ve heard him say this in various lectures, but in this interview he states this very directly:

For now I have hope that the TPS ideals, and particularly as they are manifested in Scrum, can show teams how to marry complexity with planning. I think it’s important to point out that agility and TPS often have opposing foci and, further, that Scrum is more about TPS principles than about agile principles. Agile was a software-specific manifesto penned in 2001; Scrum goes back to 1993 or 1994. We can say that agile came from Scrum, very late in the game — not vice-versa. More realistically, they both emerged from a growing realization in the 1990s of the need to support complex system development. Scrum emphasizes the systems thinking components of such changes and I hope those prevail in the intermediate term.

I actually agree with this and had actually written about this in one of my earliest articles for Gantthead.  What do you think?  Do you agree with this assessment or not?

Posted on: December 05, 2013 04:50 PM | Permalink

Comments (25)

Page: 1 2 next>

Please login or join to subscribe to this item
Hello Don,

Great information here. I agree that SCRUM was around long before Agile.

Actually, Hirotaka Takeuchi and Ikujiro Nonaka identified the initial concepts of Scrum, including the word “Scrum” itself in their white paper, “The New Product Development Game" in the mid 1980s as your previous article notes. In this paper the authors describe the initial development of self-organizing teams and other SCRUM characteristics at Fuji-Xerox (and other firms) as early as 1978 for the FX-3500 medium-sized copier development project.

Interesting article, but I can't agree. Agile as a method, done well, is always a tension between complete "agility", and the need in any real business or endeavour to have some structure, formality, and predictability. SCRUM is simply one (well-proven) way to manage this tension, but the existence of the tension itself is simply real-world rather than idealism, and doesn't mean that this isn't agile.

As for which came first - Agile or SCRUM, this is effectively chicken or egg. The Agile Manifesto was an important event, but did not mark the first conception of Agile, in fact it was a result of recognition of what some of us were already doing - I was one who was managing an Agile method for Development and other types of work, some of it not really IT at all. before either Agile or SCRUM were heard of, back in the late 1980s. I was interested in Harlan's information on the history of actual formalisation and papers on this, because at the time those of us who were doing this were in isolation making it up as we went, at best occasional discussions at trade shows where we'd discover others were doing similar things.

Hi, Bernard — I think you miss the broader point of my plaint. It's not about who's first but about the fact that agile and Scrum are quite different. Scrum has an agile vernier that relates to its aspects of self-organization and feedback, but its foundations relate to value and planning. I do think that few people understand that Scrum predates both XP and the Agile Manifesto.

One can contrast typical agile implementations (such as XP) with the TPS foundations and their reflection in Scrum, on many points. Scrum is about up-front planning; agile about "deferring decisions to the last responsible moment." Agile is about choosing practices in the moment; TPS about embracing standards. Agile is typically nerd-focused while Scrum is usually more value-focused. Agile tends to be about techniques while Scrum is a framework. Agile tends to be focused on doing whereas Scrum is focused on thinking and then doing.


I think I see more Scrum implementations fail from sliding into agile than from backsliding into silo techniques or those things typically called "waterfall."


It's funny you call Agile a method. As established, it's a manifesto, though I agree that both the attitudes and practices long predate its authorship. Many of them were there in Scrum, and most of them were in the Lisp groups at MIT several decades earlier: Richard Gabriel talks occasionally on this topic.

A few more things:

  • Agile is about emergent architecture; Scrum experts advocate it up-front
  • Agile is about individuals; Scrum is about teams
  • Agile diffuses responsibility; Scrum has explicit accountabilities
  • Agile is largely do-inspect-adapt; Scrum is largely inspect-plan-do

Copious sources and citations on request, but I trust that you have already done your own research.


I could go on. The fact is that a deep appreciation of the history — both back through the patterns work which bridged Nonaka''s work to Scrum (according to Nonaka) and back through Nonaka''s predecessors, and the general history of software practice going back many years (pair programming was first taught by Von Neumann, for example) — makes it pretty clear that there are two worldviews here. I think that Scrum and Crystal have elements of both, but most people who call themselves agile and who align with agile methods lack the more deliberate elements one finds in Scrum.


For more on this, see Lean Architecture, by Coplien and Bjørnvig.

James, you seem to have a lot to say about what Agile "is", but where are you getting these absolutes, and how does defining that Agile has to be a certain set of things an Agile approach?

You also seem to have taken maybe one or two experiences with Agile and extrapolated that to a misunderstanding of the whole thing. Just a few examples:
Agile is about emergent architecture; Scrum experts advocate it up-front? No, wrong. SCRUM experts advocate having AN idea of architecture up front because it is necessary to have some sort of starting point and without some idea of architecture it is hard to build other ideas, but SCRUM does NOT say that this cannot change as better ideas emerge, it is just an idea floated out into the work to trigger thoughts.

Agile is about individuals; Scrum is about teams? A false distinction. Anyone who has worked in team development knows that it is about how you get individuals to work together. An Agile approach that involved a single individual sitting somewhere in an isolated room with no contact with anyone else doesn't fit the Agile manifesto which emphasises "interactions" and "collaboration". SCRUM is 100% those interactions and collaborations and is absolutely Agile.

Agile diffuses responsibility; Scrum has explicit accountabilities? Again false. Diffused responsibility is still responsibility, and in SCRUM some of this is diffused to the team as a whole, and some diffused to individuals, which is absolutely Agile - because it changes in an Agile way to match whatever way the work develops.

Agile is largely do-inspect-adapt; Scrum is largely inspect-plan-do? Complete garbage that one I'm afraid - SCRUM is absolutely NOT inspect-plan-do, it involves building something (DO), demonstrating what was built (INSPECT), and then identifying what should be done to change that (ADAPT), precisely what you said Agile is.


Bernard,


I'd welcome you to one of my Scrum courses to learn what Scrum is.


Scrum starts with a planned Product Backlog (PLAN), created by analyzing the market (INSPECT) and implemented by the developers. Where you get the idea that they implement first is beyond me


Show me any accountability in the Agile Manifesto. Show me teams in the Manifesto; I can show you individuals.


The Scrum PO is accountable for ROI, and the ScrumMaster is accountable for the process. If the team isn't delivering you fire the ScrumMaster. If the PO isn't delivering enabling specifications (yes, we use the "s" word) to the team, or getting ROI, then she's fired.


Jeff Sutherland, the inventor of Scrum, says he has never done and would never do a software Scrum without up-front architecture.


Where am I getting these? My work was one of the foundations of Scrum. I'm currently a partner with its inventor in his company, Scrum Inc. I am working together with the community leadership to create a rationalized definition of Scrum in pattern form.

Yes, I honor my experience but also honour the authoritative sources. Your arguments are ad-hoc and appeal to no source. If you want to stand on humpty-dumpty definitions, then you will always win. But we are professionals here who should be doing due diligence in the history, groundings, and rationales of the founders. I feel I am doing that. Your post shows clearly that you are not.

James, I agree with most of what you're saying. I do, however, find it interesting that Jeff does Scrum with up-front arch/design. Do you know of anyone else doing it this way, or telling that this is "the Scrum way" of doing it? I typically hear the opposite, that up-front design/arch is a potential waste and that emergent architecture is "the scrum way" of adressing this topic.

All very interesting comments. However. SCRUM was around long before Jeff Sutherland so to say he is the inventor of SCRUM is incorrect. As I mentioned in my previous comment, SCRUM was first implemented in the late 1970 and early 1980's in Japan. The current form of SCRUM is based upon that early manifestation of self organized teams.

Hirotaka Takeuchi and Ikujiro Nonaka identified the initial concepts of Scrum, including the word “Scrum” itself in the 1980's.

Harlan, If you want to go way back, Nonaka-sensei got the term from rugby (actually, from a slight misunderstanding that it was one team at a time that created this configuration) in which case your logic would lead one to believe that Scrum was invented in the world of sports. What Nonaka-sensei and Takeuchi-san described in their paper was empirical observations about innovative developments in Honda, Canon, NEC and other companies. Toyota's PS has always been held up as the primary example of these practices but it's likely that Honda does them even better. Their work inspired Sutherland to create the framework we know as Scrum today, but Scrum is not the same as TPS: Sutherland borrowed from other sources and added other innovations. The Daily Standup comes from my research at Bell Laboratories on the inadequacy of ISO process standards (http://jeffsutherland.com/2007/07/origins-of-scrum.html). To TPS and the "New, New product development game" framework Jeff added time boxing — which Nonaka-sensei recognizes as a brilliant, key addition that he omitted. Jeff split the Chief Engineer role of TPS into the ScrumMaster and the Product Owner for a number of reasons he has written about. So that is the real history as I know it from Nonaka-sensei and Jeff themselves first hand. All of this information can be found with a Google search. I am not sure what sources you draw on. Did you just make them up?

James, why do you assume that because I have presented information that may not agree with your point of view that I made it up?

My sources include the Harvard Business Review, the white paper I referenced in my post of December 6th, as well as MBA courses I have taken in which we were being taught the usefulness of self organizing teams in the last century. If you would read that post, you would see that in fact, Fuji-Xerox was where self-organized teams were first observed.

I completely agree that SCRUM has evolved beyond it's initial inception; however,it is still the foundation of self organized teams. It seems to me, based on your comment, that Mr. Sutherland built upon that foundation to create what we now know as SCRUM. I am not now, nor did I intend to disparage anyone's work, but SCRUM in various forms has been around for a long time.

Harlan, given that you gave no credit to those whose ideas you related here, I presumed them to be yours. At that I think you misinterpret the sources you mention above, at least from what I know from my acquaintance with the authors and the very works you cite.


More broadly, the properties you seem to focus on hardly started in Japan, but are timeless. They tap into basic human social behavior. Self-organized teams have been around for thousands of years in human behavior and even longer in animal behaviour: bird flocks, herding instincts, and insect swarms knew nothing of Fuji-Xerox. The entire Yugoslavian society was explicitly managed as a self-organizing entity before Fuji-Xerox. The entire Japanese industry was shaped from origins that go back to the Eisenhower post-war construction that long predate Fuji-Xerox, and those practices have much earlier roots in Buddhist notions of harmonizing within nature.


If you want to get the lineage of inspiration right: Nonaka-sensei and Jeff Sutherland themselves (they teach together at Harvard) trace Scrum''''s history back in part to his HBR papers in 1986 and 1991, followed by the organizational patterns work from 1993, which in 1995 more or less combined into the framework we more or less know today (Source: Nonaka-sensei''''s slide from the January 2013 Scrum gathering in Tokyo). Jeff also traces the ideas back to even more ancient traditions from a Hindu perspective on commerce, and he also brought in ideas from robotics.


Scrum taps into ideas much broader than the citable, narrow field of project management , and limiting yourself to the last century (why in the world would you do that?) where you seem to draw your citations. Even at that I think you mis-cite the HBR paper, which used Scrums only as a metaphor. Jeff Sutherland used the name largely because he wanted a name so stupid that no one would use the ideas because of the name.


I think we agree that individual Scrum principles have millennia of history behind them. That is a truism: you can find no interesting facet of human endeavor for which that is not true. As a concerted framework, Scrum emerged as an integration of these ideas at Easel corporation in 1993 or 1994, and it became more formally defined starting in 1995. While you will find parts of it earlier on, I challenge you to cite a source that shows the same patterns of governance in any earlier framework. We don''''t credit the Romans with the invention of the car because chariots had wheels, but that reasoning seems to exactly parallel your logic.


For a better description of the lineage of these ideas back through the centuries, you might read "Ultimate Agile Stories III," published in Japan last year, edited by Yasuo Hosotani.

But this thread started not with the origins of Scrum but of the agile nature or not of Scrum. I take the word "agile" from the 2001 Manifesto; any other definition is likely to lead to arbitrariness. Scrum certainly has "agile properties" in the vernacular sense of the English word, but its paradigm is very unlike the paradigms of methods such as XP that exemplified agile''''s roots. And those roots were grounded quite a few years after Scrum was already up and running. So it makes more sense to say that Agile is Scrummy than to say that Scrum is Agile.

Frederick, Great question. I think that the summary insight here is that it''s not how much you do, but what you do. (This isn''t original with me: I''m stealing it from a Twitter feed I saw several months ago. I''m unable to find the exact source right now but will keep looking.)


The principle is that efficiency comes from planning — in particular, planning the dependencies between the decisions you will have to make. You lay these out up front and structure the dependencies to give you the greatest flexibility. It''s what lean calls a decision structure matrix (DSM). Think of these as meta-decisions.


In Agile, the results come from doing and from getting feedback — not from planning or thinking (show me "planning" or "thinking" in the Agile Manifesto). You need both, of course, and Scrum had both from the beginning. When XP came along it retained Scrum''s notion of feedback but discarded the planning — perhaps as a way of gaining nerd''s favour and fanning management hopes of reducing paperwork and architecture budgets. Augustine''s ne quid nimis got lost in the excitement to get to market.


The decisions themselves must be made before context boxes them in — a phrase that lean people call "the last responsible moment." That term became co-opted by agilists to justify the lack of up-front analysis and design, in reaction to the sins of the 1980s in front-loaded projects. It originally meant almost exactly the opposite of what the agilists mean by it (see the Negative Iteration paper from the Lean Construction Institute, http://www.leanconstruction.org/media/docs/05.pdf).


Doing too much up front is also waste — e.g., developing libraries, platforms, and other service code that anticipates the eventual demand for such segments of code as part of a larger development that delivers end-user value. It''s difficult to get these things right up front. And it''s costly — it''s too front-loaded and entails too much development before you get either feedback or value. It''s inventory.


However if you don''t get the form right up front, it leads to rework when the time comes to deliver value (e.g., use cases). Good architecture reduces rework. The good news is that it doesn''t take long to do a great architecture. Current practice leads to long lead times (sometimes many months) on architecture because it''s rare that you have the right stakeholders involved until the architecture review, and then it''s too short of an interaction, and it''s almost always politically unacceptable to make changes at that point. One sprint should be plenty to get a robust, solid architecture — delivered as concrete APIs (usually as ABCs in most contemporary shops).


So, again, it''s not "how much" you do but what you do, and when. And, of course: everything in moderation. This isn't about religion but about value.


There is a good amount of systems dynamics theory behind the separation of data form and functional form, and such reasoning is one of the reasons that DCI works and is catching on. I know many companies that are taking this approach — both with and without DCI and, for that matter, with and without Scrum. I have one 150,000-employee client who will be rolling out this approach in their systems over 2014. I think all of Sutherland's VC startups work this way, but you'd have to ask him. I know a lot of Finnish startups that work this way. The Ruby community is one of the biggest growth areas for DCI, and we see dozens of examples there in the U.S., Japan and Europe. Every one of these that I know of has been happy with that aspect of results, though it does raise the kind of insecurities among people who have made a career of such things as we find in the responses above.

I think James' posts here are really inappropriate in tone. He unjustly criticises and even abuses anyone who dares post any view that doesn't agree with his and seems to consider himself the sole source of all knowledge and truth.

This is a discussion forum for people to post their views, but also listen to others and to engage in a professional manner, not go one some semi-messianic crusade of dispensing dogma and demanding compliance with this from others.

James, if you read this please go back and dispassionately review your posts - they are incredibly arrogant, sometimes outright abusive and patronizing, and very unprofessional, and not only are inappropriate to such a forum, they will also do harm to your professional image.

Bernard,

Oh, I feel that my tone is perfectly in line with the provocations. "Arrogance" is to set one''s self above the facts, to not check the facts, and to make unprofessional claims in a public forum that malign or misrepresent an industry lightening rod. Further, the "contributions" were in no way constructive but served only to puff up the ego of the poster.

I know it''s embarrassing to be demonstrated wrong, with citation, in a public forum. It''s unprofessional to shirk away from the argument and to resort to an insecure position where you become emotionally accusatory.

Understanding, and progress, depend on dialectic. I choose to use suitable rhetoric that is in line with the facts, and which emphasizes the facts, to make my point. If I accused anyone unjustly, then please respond with a point-by-point analysis. So, policeman, bring the facts and charge me. What would you do to one of your people who, instead of confronting a wrongdoer with facts and the law, yelled at them about how inappropriate their behaviour was?

Please go back and "dispassionately read" this thread. I think you will see that you are the one with his ego engaged. I am merely representing the standings, history, and grounding of the phenomenon that has been misrepresented by you and others here.

I love to be proven wrong James, because that is how I learn, but not to be abused and criticised without foundation, and those who never listen or consider that they may be wrong will never improve.

You dismiss every counter view, and do not do so with "citations", but just patronising "if you attending one of my courses you'd know something about this", clearly indicating that there is no source of knowledge you value other than your own dogma.

Last comment from me on this subject, as I don't waste time on closed minds. Others will read your abuse and refusal to consider anyone else can have a valid point, and make their own judgement.

Bernard,

You're welcome to leave the thread; your departure emphasizes the point I was going to make that there's little evidence here to support your claim about loving to be proven wrong.

I think you'll find I substantiated every rebuttal either with a direct reference to the literature or to the original sources in person.

Yes, my style is direct, but it is more subtle than you give the media credit for. Oh, I read carefully and listened well, and am amazed that you accuse me of doing otherwise. I responded to what I read as challenges. The first two posts here (one of which was yours) made unsubstantiated (and, as it turns out, incorrect) disagreements with my fairly well-considered position. I, too, am willing to be proven wrong, but the key word here is proven. I expect professionalism from someone who posts in a forum like this, and that includes either appealing to sources or formally justifying your position.

I'll end by pointing out that your reaction when finding out that your arguments were wrong was not to explore whether you might have misunderstood the emotive content of my response (which your response clearly indicates is so), but jumped into accusatory mode. The issue of agile and Scrum are deeply human agendas, and it takes forbearance and humour to delve into these issues. I feel I accorded those to all here. No one ever responded when I asked for pointed concerns, and you exit with the issue unresolved. Fair enough. I know where you stand, and that's that. Hope it's not too offensive to say that, but that's where it ends.

For those capable of reasoned discussion, I'm clearly not leaving the thread, just not bothering to argue with those who are incapable of doing so in a professional and mature manner. Sticking your fingers in your ears to claim no-one has countered your ideas, and then claiming victory because you had the last word isn't valid in any reasonable discussion forum, in fact most of us grew past that after kindergarden.

I'm more than happy to continue debating on this subject with anyone who wants to on a professional basis. It is an interesting debate, I hope not spoiled by one individual's immaturity.

Having designed, implemented and run TPS based systems in the 80''s and 90''s, and also developed software for the last 30 years using a variety of methods and philosophies including Agile and Scrum I would say that neither Scrum nor Agile are derived from TPS. TPS is a process, Agile is a philosophy. One could argue that TPS embodies much of Agile philosophy or that the underlying philosophy of TPS was adopted by the framers of the Agile Manifesto. But a philosophy is not a process.



Agile was never meant to be a process, but a set of values. In as much as scrum is practiced as a process it may or may not be Agile. It all depends on the values driving the choice to use Scrum.


Also it is important to understand that TPS is at its core a set of methods for repeating a process. It may be high mix or low mix but it is repetitive. Software development at its core is not repetitive. A software team is brought together to build the first of its kind, not make the same thing over and over again. When the software is done and in use, at most some remnant of the team may stay in place for maintenance. Which is also not repetitive in nature. This is a huge difference between the goals of TPS and software development, and will obviously make a huge difference in the methods each employs.


Agile was a response to attempts to impose a fixed set of processes and methods to software development as if developing software were a repetitive activity, instead of recognizing that each software project is a one of a kind endeavor. Team members may bring the same set of tools and techniques from other projects along with their own domain knowledge, but each project is it''s own beast and must be tamed in its own unique way. Agile is a set of values to apply while trying to tame the beast, not recommendations for specific methods or process. In Agile the values and circumstances recommend the process, not the other way around. And as circumstances change, Agile values may indicated that the current process or method must be discarded. This is why Scrum is not Agile. At best it is something that an Agile team might find useful for some or all of a project. Just as they might find a white board or post-it notes useful, neither of which is Agile.


Hi, Gene,

I''m not sure years of experience qualifies one to pronounce whether Scrum is agile, lean, or TPS. It''s probably better to compare via the literature or, better, go to the sources. Also, there is an additional caution: I see you''re from the U.S. As Liker notes in his book, most U.S. projects that claimed to be TPS were far from it. I don''t know your own situation but it is indeed something to be aware of, and it is something that the Japanese are aware of.

Jeff Sutherland, who invented Scrum (Ken Schwaber "re-packaged" it in 1995) names TPS as his source, and has done so from very early on. He split the Lead Engineer into the PO and the ScrumMaster, retained the practices of andon, shojinka, pull, chaku-chaku, jidoka, and later incorporated heijunka and amplified the notion of kaizen mind. It has always been based on the same value stream model as TPS.

Witness to this are Nonaka-sensei''s recounting of this history in his talk in Tokyo in January 2013, where he traces the history of Scrum from his own work through the Organisational Patterns to Scrum. Nonaka-sensei''s work is based on that from several companies, most of which are held to have inherited their practices from a single common source. In Japanese dialectic there is some controversy about whether the source actually is Toyota; there are strong roots of this idea in Honda. for example, and Hitoshi Yamada-san''s work figures strongly either in disseminating these ideas or as being close to the original source. Whatever its history, it is what we today call TPS that was at the definitive origins of Scrum.

The recently published book, Ultimate Agile Stories III (Yasuo Hosotani, Ed.), published in Japan, has as its cover illustration a world map showing the flow of ideas from Japan to the U.S. and then back to Japan. The Japanese Scrum culture knowledgeably views it this way (it includes a good number of people in the Toyota constellation, such as ?? ???? and Kiro Harada-san).

If you disagree I suggest taking this up with Nonaka-sensei and with Jeff Sutherland, because I think that''s what they''re teaching together at Harvard these days. (And I think they can predate your 30 years, FWIW, as do I...) We certainly don''t want them misrepresenting history...

Tracing the origins of Scrum establishes it's history. Not its agility.

Page: 1 2 next>

Please Login/Register to leave a comment.

ADVERTISEMENTS

"Nothing defines humans better than their willingness to do irrational things in the pursuit of phenomenally unlikely payoffs."

- Scott Adams

ADVERTISEMENT

Sponsors