Want to have a heated argument? Just bring up the topic of development methodology. Every person has his or her own preference. Just Google the topic, there are thousands of opinions out there and enough ‘Guru’s’ that are more than willing to come out and teach you the way to software development heaven for a price. If your like me and have spent any time in the software development field you’ve probably tried a number of different methodologies and even sought to combine them. Some have been discredited, others are the flavor of the day. I’m probably an outlier in the sense that I can make any of them work. The difference is that I’ve come to realize when to use specific methodologies and when to avoid others.
Although there are many let’s talk about the three most common: Waterfall, Scrum and Agile. My goal here is not to talk about the strengths or weaknesses of the methodologies themselves, but when it might be in your best interest to use them.
Waterfall
Waterfall is by far the most widely discredited methodology, typically associated with large monolithic organizations.
When to Use
There are specific instances when you want to use the Waterfall methodology. The first is when the clients organization is reminiscent of a Dilbert cartoon. I’m sure we’ve all seen them. All puff, no accountability, he said/she said. Waterfall is a nice way to cover the backside. This is especially true if you get the feeling that process management is non existent. I have worked with plenty of customers that really don’t know how their business runs. Waterfall is documentation heavy and it’s a great way to point out that your customer may want to focus on core business processes rather then letting them think that the piece of software you’re building will help save the day.
The second instance when Waterfall might be advantageous is when the owner of the project changes continuously. Often times this means that the next owner doesn’t have the same solution in mind. If your working in Agile or Scrum this can lead to a never ending project. It’s OK if you’re on a per hour basis, but fixed bid or you don’t have your CYA in order it could turn into a loss of money or worse: a blame game.
Agile
Agile is what I would call the ‘soup of the day’. Everyone from the ‘Guru’s’ in Silicon Valley to the prolific software book writers (you know who you are) are in to it.
When to Use
Agile, from a developers prospective, is easy money. Little to no overhead, refractor on a whim, no thought to it. There are only two requirements: A strong Customer who knows how the business works but may not be technology savvy, and a strong IT team meaning Product Manager, Project Managers and the like. Both Customer and IT have a good relationship. The focus is on the product. I love Agile, but you need the right corporate environment, the right Customer, and the right IT team for the methodology to be effective.
Scrum
Scrum is a flavor of Agile. From my experience Scrum is what happens when the first two methodologies enter into a phase cleverly coined by one of my colleagues as ‘Epic Failure’ (hat tip to Sam).
When to Use
Scrum actually has its place. Also knows as the ‘Get‘er done’ methodology. Scrum is great when the Customer and the Engineer both know the business well and both know what needs to happen to make the product work. Engineers love it because it lets them do what they love to do: develop. Customers love it because there is constant and regular interaction with their product.
Scrum is also a great way to develop software if you have a weak Product Manager and Project Manager. Which, by the way, is often the reason for failure in the first two methodologies. It’s a great way to make them feel involved without putting your career on the line.