Agile Software Development needs to separate itself from Scrum. And, Scrum needs to quit doing agile such a disservice.
I’ve seen it a few times now where agile practices, get the root cause treatment for flailing methodologies. I hear way too often “we’re an agile shop; we do Scrum.” And, I’m also seeing more and more organizations attempting to apply Scrum to CMM-centric projects.
First Step: Remove agile from methodologies. Agile practices should stand alone, as simple actions taken by individuals, teams, and stakeholders in support of any given methodology. [Good agile practices won’t preclude process success, but can prevent many process pitfalls. Practices can make {closer to} perfect {software} – but, process can not.]
Second Step: Accept that Scrum is not agile, in of itself. [Just because the process is broken down to more iterative steps does not imply agile anything. In fact it could be concluded that the real Agile says they aren’t related at all: “Individuals and interactions over processes and tools”.]
Obviously, there’s a lot more to be said here. I’m intentionally keeping this short…with the hopes that I will continue the thought in subsequent, more focused, posts.
Funny, you post this now. I was just reading the Agile Manifesto today and wondering how some of those principals aligned with what we are doing we Scrum. I am anxious to read your follow up posts.
The implementation of Scrum takes many shapes and forms; is it your implementation of Scrum or Scrum philosophy that is the culprit? Scrum doesn’t have that many steps and it’s left to the individuals to implement.
Process isn’t evil since it communicates expectations or guidance and is trainable or repeatable. Teams of 10 need extremely little process while teams of 100 need a little more. The bad part of process is when people use it as a weapon. People taking the mindset that I will control you by citing the process. The other day I identified the process and asked a question around why we were implementing something in a particular way. The person became frustrated and responded, Obviously you don’t understand the process and recommended that I take the training again. They didn’t want to think about it or discuss it; just quote the process to end the conversation.
The Manifesto is not banning processes but it is putting it in perspective. There can not be a process for every situation and the individual or interaction take precedence. The process and tools should be malleable and versions.
The goodness of a software project or methodologies rests upon the behaviors and execution of the people. I’ve worked on successful modified waterfall and Scrum teams; the methodologies are grease for the machine but if your parts are messed up then it really doesn’t matter which grease you use.