Scrum can lead to BAD software and engineering too....

Scrum

Scrum if you didn't know by NOW, is essentially micro-managment of software engineering at a  high level and of software engineers; work on these small prioritized tasks within estimated time constraints ranging only in hours, report daily on the progress and any issues so that they can immediately be addressed.  Cue up a variety of metrics that attempt to get more from the process then is put into it,  violates fundamentals of thermodynamics but keep trying: Velocity is killing Agile! This falls out from several principles of what is known as the "Agile manifesto" where Scrum was formed as an empirical process control model covering each principle in it's own way.  There is of course much more to it but boiled down that's the 1000 ft view on purpose and history.  I say micro-management in a good way here, it's tough to build complex software while forecasting delivery under modulating customer requirements if everything is allowed to run amok.  The rest of what Scrum promises however (product mgmt with a more accurate gauge of release and feature dev control) and BETTER ENGINEERING is highly debatable.

I'm pro Agile and Scrum really, but I don't think it's the answer to every problem or is in fact even an SDLC though many treat it as one.  There are also agile engineering practices to consider which Scrum does NOT address though it's great at measuring SOME of the results.

Scrum evangelism,  borderline idiocracy

Most of what you hear from Scrum advocates (esp newly minted ones) are some pretty broad characterizations about more traditional SW engineering practices that fall outside of what they have come to perceive as "agile".  Scrum offers a relatively easy to understand and implement process that can work.  The downside is evangelism behind Scrum that must somehow include as example by contrast the myriad of bad engineering practices and flawed management models that must have existed before; or anything else used today for that matter.  The truth is that MANY very large, robust, and successful projects have been built and sustained using Waterfall, Spiral, or something simply done using solid system engineering practices, RUP comes to mind.

What's worse is that many Scrum practitioners confuse engineering activity and practices with the Scrum process control, NOT THE SAME!  It should be clear that "value" in the Scrum sense relies primarily on practices not outlined in any manner by Scrum itself.  A  lot of what is in the engineering domain that Scrum proscribes, comes from XP (Extreme Programming) another Agile methodology.

Scrum is better then....

 Usually it's the dreaded waterfall, bane of all human endeavors! I challenge anyone that claims "Waterfall" as a failed model to describe it and point out that it must be anything other then employment of proven design, analysis, and development techniques that can be iterative and "agile" in many respects. I'll explain....

Waterfall is an SDLC, and Scrum is not!!  SCRUM is not an SDLC or project management methodology!

The proof of this is that it simply doe not illustratively inform on, design, architecture, release planning, QA process, and maintenance.

 In fact take a look at wikipedia's page on waterfall and you will find that the model described, requirements->design->implementation->verification is essentially what ALL development models adhere to no matter what they exactly call themselves.  It's only the level of scope and iteration between phases that defines a more agile approach.  Despite some shuffling with the verification you can't very well implement software without having some design that must have come from requirements, no? Even breaking down a goal or user story to something that can be developed is in effect design though it may not include specific technology.

Here is an SDLC that looks pretty much Waterfallish and I think it's easy to see how Scrum could be used inside such a lifecycle Design->Implement->Test.

If I were to make those arrows bi-directional and collaborative across roles I end up with something akin to Kanban, another agile process for software development.

Scrum is a tool realizing Agile principles but not the only one. 

There is a fair amount of largely non descript software development methods in industry leveraging from various methodologies while avoiding what doesn't fit.  I was recently turned on to Steve Yegge's (Google) blog post  good-agile-bad agile  demonstrating successful emergent practices.  In another more recent article agile-hybridization Christopher Goldsbury discusses not only hybrid approaches using Agile philosophy, but some great examples where Scrum is not a good fit for adoption or success.


 Scrum succeeds in being easy to understand and fairly rapid to put into place.  At the same time, the failure of Scrum to achieve desired results might be more nuanced and difficult to pinpoint.  On considering the Adoption of Scrum, I work in a highly matrixed environment where we move between projects ranging from pure research to near production level.  Thank God becasue it keeps me away from full time Scrum and endless Sprints.  The diversity of people's roles  and their locations are also in flux at MIT, no one size fits all methodology is going to succeed there.  Ken Schwaber's book, "Agile Project Management With Scrum" has some great stories about the failures encountered in bringing Scrum to new clients.  However;  it seemed that every failure listed was was attributed ONLY to mistakes in implementing Scrum and no exploration of other possibilities, admittedly it's a book about Scrum after all.