We’re going to go Agile! Hallelujah. No more Waterfall projects.
…
So when do we start?
…
Now? But … But … OK
…
I hate to ask, but now that we’re agile what do we do? How exactly does this work? I mean, we’re sort of in the middle of the project and now you want to change how we do things?
…
To those of you who have made the jump into the brave new world of Agile Methodology, discussions like this may seem eerily familiar. The first part isn’t what’s scary. It’s what sometimes comes next that can be truly frightening.
…
You know what? It’s April and we already have a project plan that goes until November. Let’s just chop it up now into Sprints. That way we can tell our business partner that this won’t impact the schedule. In fact, according to Agile, we should have the business partner at all of our morning Scrum meetings. I’m sure they’ll understand that they’re not supposed to say anything. Just be sure to tell the developers to mind their manners. We can tell our business partner that in exchange for more involvement and more testing from them we can allow them to make changes to the plan on the fly because that’s one of the great benefits of Agile. In fact, from what we’ve been told, we’ll probably get done a lot sooner.
…
While this may seem absurd blurted out in a single paragraph, in the real world this can happen if the conversation takes place over the span of weeks or even months. A series of reasonable proposals and assumptions strung together the wrong way can lead into this slow descent into madness.
Let’s call this the Agile-Waterfall Hybrid approach. Developers will only have to work 8 hours a day and the business can make as many changes as they want to the spec. Right?
We Did What The Book Said. What Went Wrong?
The problem isn’t with Agile or Waterfall. Both development methodologies can work when utilized correctly. The problem lies in mixing the two and forming a toxic methodology sludge.
OK, Smart Guy. So What Should We Have Done?
1. Start with a new project – Never make the switch to a new methodology in the middle of an existing project.
2. Don’t try a new development methodology with new technology – This falls into the “don’t bite off more than you can chew” category. Don’t try to implement a new development methodology in a project that is introducing technology to the organization. In other words, if your company is a .NET shop, your first Java project isn’t the time to switch from Waterfall to Agile.
3. Don’t plan beyond your current iteration – As an organization experienced in Waterfall, it will be tempting to try to figure out what all your iterations will look like at the beginning so you can give the business an overall delivery date. DON’T. This doesn’t work and will invariably lead to the Waterfall-Agile Hybrid trap. Instead, embrace the concept of delivering something usable in small iterations. If you cannot do this, you’re not ready to switch methodologies.
4. Remember dependencies when planning your sprints – It’s alarmingly easy to plan out a sprint where your development team looks perfectly load balanced on paper and still completely misses your deadline. How? Because you forgot to consider dependencies. In other words, Developer A needs to write a shopping cart GUI. We know that a lot of it depends on web services and at first this seems fine because we have the web services work already in the plan. The problem is that we have both the web service work and the shopping cart GUI due at the end of the same sprint. This looks great on paper, but the shopping cart GUI can’t possibly finish on time because everything it does relies on web services that need to be done largely before the GUI works begins in earnest. It is true that some of the work can be done against a stubbed WSDL, but the proverbial rubber only meets the road when there is live data coming thru that web service. With dependencies factored in, your plan could dramatically change!
5. Choose a first project that will have high value to the business but low complexity – The idea is to try to get a series of quick wins with the new methodology to gain organizational confidence and to create momentum.
I’ve been on fantastic Waterfall projects and I’ve also been a part of incredibly successful Agile projects. There are advantages and disadvantages to both methodologies that have been argued extensively for the past decade. It’s critical to remember that these methodologies are different enough that they cannot be mixed.
Moving from a Waterfall methodology to an Agile approach will take time, effort, and patience and there will be mistakes made along the way. While this post discusses how to mitigate some of the more catastrophic problems, there will be other bumps in the road. The key is to understand the challenges up front so the organization as a whole is prepared to make the journey together.