Part of my original post was incited by seeing multiple organizations attempt to combine Scrum with traditionally “waterfallish” paradigms such as CMMI, and IPDS - as well as value management concepts like Earned Value Management. The results of such efforts is a burden on the developmental layer, where agile is really intended to impact, by virtue of generic software engineering practices. Again, the intent is to discuss, in lighthearted fashion, the delta between Scrum and Agile - based on my assertion that Scrum IS NOT Agile.

Scrum is an Agile process that can be used to manage and control complex software and product development using iterative, incremental practices.

Why is the Agile in ControlChoas.com’s capitalized? To me this implies that Agile itself has some formal definition. This is a difficult rationalization for me. Not that Wikipedia is the end-all, be-all source, but it appears to resolve “Agile” to the Agile Manifesto (mentioned above). “Agile methods are a family of development processes, not a single approach to software development”, as pulled straight from Wikipedia. For the lack of a better definition we’ll stick with the Manifesto. The notable Martin Fowler has a few thoughts of his own relative to the subject, found here. I don’t necessarily see this as a “school” issue…but, can understand that there are different tendrils to follow within and around this discussion.

So, considering what Scrum IS and what Agile IS…why is it Agile that gets the blame when Scrum flails, falters, or fails? Let’s go back to the Agile definition from Wikipedia for a second. Family of development processes? I disagree. Agile is a family of development practices, that enforce a given process. Practices, not processes. Remember, Agile is about people (and by definition people over process). Scrum is about process. Agile is about self responsibility. Scrum is about accountability. Thus, the answer to the question is: Scrum is dependent on solid Agile practices…without which Scrum is no better than any other methodology. But, if Scrum is about accountability which side is really at fault for lack of performance. I’m hoping at this point you understand my cynical take on this. Logic would lead us to Scrum and Agile being symbiotic. Scrum, coming from the accountability camp, must be able to “point” the blame somewhere - and it can’t be its own fault.

I stated that “…Scrum needs to quit doing agile such a disservice” in my previous post. In my opinion Scrum is not holding up its end of the bargain. Scrum too easily arrives at “Process over People”…and thus contradicts many of the practices described under the Agile umbrella. As was pointed out in a comment to the previous post, Scrum is implementation specific. I suppose this is true in theory…but, I think really Scrum is a formally defined (not standardized) practice. It was also said that “…process and tools should be malleable”. It has not been my experience that Scrum provides process flexibility. Indeed, maybe I am just getting exposed to bad Scrum - it is definitely possible.

At the end of the day, Scrum must be agile (lowercase a) in order to accommodate all of the benefits of Agile practices. Scrum is definitely not a one-size fits all delivery mechanism that can be sold as Agile. And Agile is not a process (or stream of processes), that can be fixed, or optimized. I see Agile practices as resources and tools that I use to optimize Scrum with.

Hopefully this clears up the intent of my thinking a bit. I realize this isn’t any more focused that the previous post. But hey. Have to create the boundaries first. I promise to pinpoint where I think the issues lie with Scrum (hint: two-letter acronyms).