Episode 286: How to Migrate from Waterfall to Agile (Premium)

This episode is reserved for subscribers of the Premium Podcast. Learn how to subscribe to the Premium Podcast to access this interview and transcript...

This episode is sponsored by The Agile PrepCast for The PMI-ACP Exam:

Migrating from using a waterfall-based approach to agile project management is challenging. No doubt about it. Are there any best practices that you can follow in order to ease the migration pain?

Shawn Dickerson (www.linkedin.com/pub/shawn-dickerson/1/97/607) says yes there are. In fact, by the end of this interview you will have heard a list of about ten or so ideas, tips, best practices and pitfalls to consider before, during and after migrating from W to A. These tips will help you manage risk management in agile projects, especially during the difficult transition phase where everything feels new and slightly risky.

And of course, I open the discussion by asking Shawn about the #1 success factor to consider for such a migration.

Below are the first few pages of the transcript. The complete transcript is available to Premium subscribers only. 

Podcast Introduction

Female voice: The Project Management Podcast’s feature Interview: Today with Shawn Dickerson, Go-To-Market Director for AtTask.

Cornelius Fichtner:Hello, Shawn and welcome back on the program!

Shawn Dickerson: Thank you! It's very good to be back. Appreciate it.

Cornelius Fichtner: First things first. What would you say is the number one factor that makes going from Waterfall-based project management approaches to Agile a success and why?

Shawn Dickerson: I think the number one thing which may not be intuitive is realistic expectations because from our experience, it's usually not one or the other. It's usually not where a completely Agile shop or where completely Waterfall shop.

There are certain elements, certain types of projects that lend themselves to a Waterfall type methodology. Anything that's about producing a physical product or maybe an audit or compliance-type effort, or even in the IT world infrastructure projects, actually managing of servers, those type of efforts lend themselves to a Waterfall methodology.

Whereas Agile works very well if we're talking about a software development effort or anything that is services related and repeatable in that sense.

So really, it's about number one would be just smart about where you start this effort. Don’t be too rigid about either methodology and realize that the reality is probably going to be a mixture of the two just because most enterprises even going through an Agile transformation have certain types of work that lend themselves to one or the other.

Cornelius Fichtner: Why do companies want to make the shift to Agile in the first place? I mean what's the promise of Agile?

Shawn Dickerson: Well, there are a couple of things. Number one for those types of work that lend themselves to Agile like software development, the promise is to deliver products faster and to deliver them more aligned with customer requirements. Because rather than a process where all of the requirements are defined and locked down at the beginning of a project, it's very iterative. Every couple of weeks, you are reviewing with customer stakeholders what has been accomplished, is it in line with the initial expectation. So ideally, you're delivering a product faster that the customer is more excited about. And it also gives you a little more flexibility, a lot more flexibility actually as requirements change. I'm sure your audience is very familiar with project requirements that change throughout the course of a project.

On the flip side in an Agile environment, it's also a lot easier to introduce scope creep and expanding scope of features into a given project so that can be a danger. But there are a lot of potential gains through an Agile methodology.

Cornelius Fichtner: And when you look at your customers that have done this migration, does the reality live up to the promise?

Shawn Dickerson: For many of them, it has. But the caution I would add that it's like anything else. An Agile transformation depends on what you put into it. If you consider a successful project, the elements of a successful project, you can think about executive sponsorship, engaged stakeholders, team members that are willing to participate and follow an established work flow or process. If the same elements are in place, Agile has a much better chance of being successful than if they're absent.

Cornelius Fichtner: Alright! Let's look at some best practices in regards to doing the migration from Waterfall to Agile. What would you say are the high-level steps that should be followed as you do that Waterfall to Agile migration?

Shawn Dickerson: Well actually, come at that a little bit of a different way. I'll talk about kind of the inverse of that which is: What are the common pitfalls that people run into that halts that transformation or that causes problems?

Number one would be no training. So without any kind of training for a group that is trying to adapt the Agile methodology, that poses a lot of challenges. Sometimes a company or a group will decide: "Hey, we want to employ Agile in certain areas of the company." But they won't provide any instruction on how to assign stories or plan sprints or so forth and the project leaders assigned to manage those teams are sometimes not trained on how to wrap iterations into an overall Waterfall plan. So that's one is that there's just the proper training isn’t given about what Agile means and how it works.

The second would be if there's simply no buy-in. Culture is a huge key to success in implementing an Agile strategy. But without management's buy-in, the team can be siloed, disconnected, forgotten and in some instances we've seen just eventually disbanded. Managers are responsible for showcasing the value of their teams and that means that getting that stakeholder buy-in is important, very important to an Agile transformation.

The last thing I would mention particularly in the enterprise, it's different if you're say, a software development company that all of your work process are based on Agile. But for most enterprises, there's going to be a mixture of work methodologies and that means that there has to be some type of translation between the two.

For example, it's great if you've got an Agile development team that's being iterative and working in sprints and delivering pieces of product every 2 weeks, but the executive team likely doesn’t care about any of that. They want to know what's the delivery date and what does that final feature set look like. So it's important that there is some translation there between the Agile teams and the rest of the business.

Those are 3 you can obviously consider the inverse of those as the way to approach it. But those are some common pitfalls that we see. Zero training, zero buy-in and zero translation.

Cornelius Fichtner: Do you have an example for us from one of your customers maybe where such a migration went well?

Above are the first few pages of the transcript. The complete PDF transcript is available to Premium subscribers only.