John Luif

If you have not read Brad’s post on Scrummerfall you should.  Brad speaks of a very common pitfall about people adopting SCRUM without adopting any development practices to help the team develop great software. 

Many folks out there find waterfall and all the documentation it brings gives them a sense of comfort.  Maybe it is because they can say “It is in the requirements” when the arguments start at the end of the project when the wrong thing was delivered (yes I’m assuming something was delivered other than paper).  Or the comfort could be a CYA move that people get out of requirements signoff, basically it just creates an argument in waiting.

So why are we seeing Scrummerfall?  Well, my first observation is most methodology in companies is driven by project managers and not involving developers.  The developers have to be part of the culture shift that comes with being Agile since they are the ones actually building the deliverable.

Believing that a methodology is the road map to success is a false hope, in the end it is all about people.  If you have a team that hates each other and a client that does not want to be involved in the project then there is not much chance for success no matter what methodology is used.  Know when to walk away from a deal when you see the people just are not there to make the project be a success, that is also part of the courage of Agile.  Being “Agile” involves a lot more work than just saying it.