Making the Right Choice – Agile vs. Waterfall

Trying to decide whether to stay with Waterfall or make the move to Agile on your next project?  There are some big differences between the two methodologies that you need to be aware prior to making the switch.  In this post I’ll highlight the differences and call out key areas to consider prior to moving to Agile.

Trying to decide whether to stay with Waterfall or make the move to Agile on your next project?  There are some big differences between the two methodologies that you need to be aware prior to making the switch.  In this post I’ll highlight the differences and call out key areas to consider prior to moving to Agile.

There are four key themes that separate the two methodologies.  When considering a change, it is important that you and your organization are ready to move from the “old” waterfall thinking on the left in the chart below to the “new” Agile thinking on the right.

Should you stay with Waterfall?

Agile is not right for every project team and is absolutely not a silver bullet that will solve your organizations delivery problems. In fact, if you are already struggling, trying to change to a new methodology might make things worse. Prior to making the transition to Agile there are two key areas to consider – resources and organization.

Resources

A large number of resources will not be able to handle working in an Agile environment. Prior to selecting project team members it is important to know if the resources you have in mind are ready for life on an Agile team.  There are three areas to think about before selecting team members:

• Co-location – Tight collaboration is a key tenant of Agile but it is not for everyone.  The collocation and continual back and forth between team members can cause tension and create stressful team dynamics. 
• Discreet Work – Many team members like to finish their work and move on rather than stay with the same team of people for an extended time. 
• Performance – Agile is quick to single out individual performance issues.  Not everyone is ready for this type of scrutiny. 

Organization

Having committed resources is important, but having buy in from your organization is critical.  If the leadership team is not ready to support the Agile methodology, you can almost guarantee that Agile will not be successful.  When assessing your organizations readiness, consider the following:

• Is the leadership team ready to support a shift in thinking from the big bang approach to smaller iterative delivery cycles? 
• Can the organization accommodate the frequent delivery of increments?
• Is there a commitment to push Agile to other parts of the organization such as release management and production support?
• Has the business bought in to Agile?  They will be required members of the project team and must actively participate to make Agile work.  In many cases they are not willing to give up their “day job” to support the project team.

Getting Started

If you have the right project team selected and commitment from business and IT leadership to support the Agile philosophy you are off to a great start, but it is only the beginning.  As you start your first project, consider the following:

• Make sure requirements are prioritized by the business up front
• Start small and prove success, don’t try to build enterprise system 2.0 out of the gate
• Plan for resistance – even though you have leadership buy in, not everyone will be supportive
• Keep Iterations/Sprints short in duration (2-6 weeks)
• Deliver business value early and often.   Naysayer’s quiet down quickly when the team is delivering working software
• If at all possible have the team co-located.  While a distributed team can work, there is a tremendous amount of intangible value you get from co-location
• Do not start the project unless you have business representation.  Without the business, Agile will not work.

With these tips in mind, you should have a smooth entry into the world of Agile software development.