Scrum is NOT Agile

Gene,

One needs to be both a bit Hegelian and operational here. I can substantiate the history from documents (and I trust you can, too). I can show you the TPS principles at work in current Scrum teams.

I agree with respect to agility — given both the definition of Scrum in the Scrum Guide and the definition of agile in the Agile Manifesto. If you have different definitions of Scrum that substantiate your claim I''m happy to hear them. If you have research evidence (substantial evidence that goes beyond limited personal anecdotes) that substantiates your claim I''m happy to hear it.

Maybe you are responding to someone else, but my response said little about agility. It seemed odd to me that you would again raise the issue of the comparison with agile. It seems like we put that issue to rest here some time ago.

In the mean time we have a research program (Scrum PLoP®) that has been going for five years to collect broad practice and it seems to bear out the claims that I make above. You are certainly welcome to apply to join that effort if you want to make grounded claims and make a contribution to literature other than blogs and discussion groups. My claims are more than opinion. I offer you the opportunity to show that yours are, too.

Posted: Mar 30, 2014 6:00 PM

Gene,

One needs to be both a bit Hegelian and operational here. I can substantiate the history from documents (and I trust you can, too). I can show you the TPS principles at work in current Scrum teams.

I agree with respect to agility — given both the definition of Scrum in the Scrum Guide and the definition of agile in the Agile Manifesto. If you have different definitions of Scrum that substantiate your claim I''m happy to hear them. If you have research evidence (substantial evidence that goes beyond limited personal anecdotes) that substantiates your claim I''m happy to hear it.

Maybe you are responding to someone else, but my response said little about agility. It seemed odd to me that you would again raise the issue of the comparison with agile. It seems like we put that issue to rest here some time ago.

In the mean time we have a research program (Scrum PLoP®) that has been going for five years to collect broad practice and it seems to bear out the claims that I make above. You are certainly welcome to apply to join that effort if you want to make grounded claims and make a contribution to literature other than blogs and discussion groups. My claims are more than opinion. I offer you the opportunity to show that yours are, too.

Posted: Mar 30, 2014 6:02 PM

Like I said, I've been doing software development for a long while. I remember when Agile appeared. They didn't call it Scrum or XP or any of the existing methodologies. They didn't even call it Agile, but others did. In as much as Agile is the vision and philosophy described in the Agile manifesto, not only is Scrum historically not Agile, it's not Agile because it is a process. And processes are something that are not preferred by Agile. And I really do not care how many historical documents you can produce. The Agile Manifesto is there for all to read. If you care to, you will see that it is not about process. It is about values.

"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more."

Posted: Mar 30, 2014 6:11 PM

Don't get me wrong. TPS is a great tool for setting up manufacturing facilities. For software development, not so much. Two very different things. For instance, an Agile team might find it useful to create and toss prototypes. TPS would not tolerate this since it is wasted effort. TPS would try to eliminate prototyping as much as possible. An Agile team might shelve whole subsystems for indeterminate periods of time. TPS would not tolerate this in-process WIP. An Agile team might all travel to a domain experts office many times. TPS would consider this transport waste. Waste of movement. An Agile team might re-factor the same code many times. TPS would consider this a waste of hours. The question would be, why didn't the programmer write it correctly the first time.

TPS is fine to apply to repetitive process. Software development is not a process in the TPS sense. It is a project. A one time effort to achieve an acceptable result in an acceptable time.

TPS can be applied to the creation of software distribution media (a repetitive process) but not to create the actual software that will go onto the media.



Posted: Mar 30, 2014 6:42 PM

Thanks for sharing

Posted: Jul 6, 2017 8:07 AM