[2025] Waterfall to Agile Project Management: Step By Step

Adoption of Agile practices in project management is growing at an astonishing rate- roughly 10% per year. Why is that? What does everyone think they're going to gain? Waterfall project management has served us well for many years. Why change now?

So you've decided you're going to try Agile. That's great, but what does it really mean? It's definitely changing more than just the processes. It's changing the way everyone thinks. That's the big paradigm shift. It's kind of like going from a flip phone on which you can make and take calls to a smartphone on which you can do that, surf the net, many other things. In any project management methodology, we rely on the triple constraints.

No matter what, your company is a business that needs to make and maintain profits. Can Agile help with that, or is Agile just another expensive gimmick? Well, every year, numerous companies set about moving to Agile. Each of them has their own goals and objectives in mind when they start their transformation. Most of them find benefits they didn't even realize they could have when they started. One of them is improved profitability. 

Lots of people move to new homes every year. No one likes to move. It's expensive, time-consuming, and stressful. So why do they do it? More space? Shorter commute? Larger yard? All of the above? Well, for every person that moves, there's a unique set of reasons for doing it. If you start the process of moving without understanding your goals, you'll likely end up moving again within a few years.

What's it like where you work? Do you enjoy going to work every day? Why do you like it? Or what would you change? Seems a rather strange set of questions to consider, doesn't it? I'm here to tell you it's not, not at all. The things that you like about your company are the things you'll need to capitalize on in your agile transformation. On the flip side of the coin, any elements you don't particularly like are things you'll have to work through or at least prepare to address. 

Would you buy a car without a test drive? Why not? You can look up the manufacturer's spec sheet and see pretty quickly whether or not it will meet your needs. Two doors or four, four cylinders or six, convertible or not- why bother with a test drive? Well, the test drive tells you a lot about the car from steering and handling to how it accelerates and brakes. Many companies realize they want to test drive Agile practices before they make the commitment to move the whole organization.

A transformation to Agile can be very complicated. To take this on without the right leader is not going to lead to success. You're going to need what we call a sponsor. The sponsor acts like the captain of your ship. He or she is defining the destination and ensuring the ship is on the right course. The sponsor is a role that's critical to the success of the team and the overall transformation. The sponsor needs to keep the executive team up to date on a regular basis.

That means the updates are not relegated to the weekly staff meetings. It means that the sponsor is doing regular touch points or walkabouts where they're sharing informally with their peers. How do you find the right sponsor in your company?

he Agile Manifesto was a revolutionary document, when it was written in 2001. It codified the basis and framework for newly emerging, lightweight development practices. It says, "We are uncovering better ways "of developing software by doing it, "and helping others to do it." Through this work, we have come to value individuals and interactions over processes and tools. Working software over comprehensive documentation.

Customer collaboration over contract negotiation. Responding to change over following a plan. 

What's in it for me? Commonly called the WIIFM factor. It applies to everyone, including the executives you're trying to woo into your camp. In order to get the green light to go Agile, you need to understand how they think, how they, as executives, are measured, and how Agile can deliver to their needs. You can simplify this for yourself a little bit. 

Before you begin addressing the needs of your execs, you need to paint a picture of why a change, any change, is necessary.

What prompted your initial investigations into Agile as a solution? What problem are you trying to solve? 

 A transformation to Agile can be very complicated. To take this on without the right leader is not going to lead to success. You're going to need what we call a sponsor. The sponsor acts like the captain of your ship. He or she is defining the destination and ensuring the ship is on the right course. The sponsor is a role that's critical to the success of the team and the overall transformation. The sponsor needs to keep the executive team up to date on a regular basis.

That means the updates are not relegated to the weekly staff meetings. It means that the sponsor is doing regular touch points or walkabouts where they're sharing informally with their peers. How do you find the right sponsor in your company?

Selecting the right pilot project can set you up for success. Key criteria to look for in a pilot project are size, priority and risk, depth and breadth, and customer engagement. Let's look a little deeper into each of these. First, consider size. You want a project that will run at least four weeks and no more than 12. Why? Well, anything shorter than four weeks won't give your pilot team enough time to really stretch their wings with the new processes

Generally, there are four varieties of people you'll run into during your Agile transformation: Brilliant and collaborative, brilliant and hard to work with, people that challenge every initiative, and people that hate change and avoid it at all costs. While I'm not advocating that you load your team with Agile detractors and change haters, I am encouraging you to consider what will get you farthest on your Agile journey. Consider this, if you build your team only around the Agile enthusiasts, you miss an opportunity to bring along some naysayers.

To fulfill these needs and skills, you'll need the following full-time roles: Scrum Master, Product Owner, Developer, Business Analyst, or BA, Quality Assurance Analyst, or QA, a Database Analyst, or DBA, and Subject Matter Experts, or SMEs. These team members can be loosely divided into two units, the Customer Unit and the Development Unit. While they serve separate purposes, they are one team.

Have you ever watched C-SPAN after a government controversy has erupted and a committee is interrogating witnesses? I've watched those scenes and I'm always very empathetic with the individual in the hot seat. They look so uncomfortable and scared. Better them than me. Then again, I've been in similar hot seats during my career. Thankfully, never televised. I've experienced meetings where I didn't prepare well enough. I didn't spend enough time anticipating the difficult questions that would be thrown at me. Maybe you've experienced this too.

It's opening night. The announcements have all gone out, the script has been memorized, the stage is set, and the players are ready to go. You're about to become the emcee of one of the greatest kickoff meetings you'll ever hold. Nervous? Don't be. You're ready. You know how to prepare for a big kickoff. This one, however, is a little bit different. You're asking everyone present, sponsor, executive team, pilot team, stakeholders, to go onstage with you for the premiere of something brand new, never seen here before.

There is nothing more frustrating than being assigned a project and not being given everything you need to be successful. Your pilot team is new to agile. You and your sponsor need to ramp them up quickly. The very essential, tactical preparations you need to make to clear the way for a successful pilot are training, processes and tool assessment, collaboration space. At an absolute minimum, you'll need to send the whole team, yes all of them, with your sponsor, to an agile 101 class or an agile bootcamp.

- A common misconception about Agile is that teams do no planning. In fact, you've already completed one element of planning: your product vision. You're ready for the next step now, and that's building your roadmap. This is, very simply, a high level estimation of when the project's features will be delivered. The roadmap only covers the coming three to six months. That's because you can't effectively estimate or plan beyond that horizon. One of the core Agile values is responding to change over following a plan.

Just enough planning, just in time. Agile Planning hinges on these two statements. By limiting the amount of effort spent on planning things far into the future, Agile is able to embrace change. Agilists accept that it's impossible to know every relevant detail at the beginning. Agile Planning is established around these foundations. Preparing your team for this shift in thinking is going to be critical to their success. The first way to get them used to the new way of planning is to provide them the vocabulary they need to do the planning.

If you're going to paint a room in your home, you're not just going to jump in and start painting. Well, if you're a messy painter like I am,you're not going to. You'll put drop cloths on the floor and tape the edges, so you don't have a lot of clean up later. Sprint Zero is the Agile equivalent to prepping your room before you paint. It's the simple act of insuring that, once development begins, there's nothing to get in the way of delivering working software. Sprint Zero has a few primary goals: finalizing the architectural vision, purchasing needed software, vendor contracting, training, Sprint duration decision, and creating an initial release plan.

There are several key elements to successfully executing an Agile sprint. My top four items for a successful sprint are Daily Planning, Daily Collaboration, Focus on Done, and Measurement. The smallest element of sprint execution is the day, so the team meets every morning to plan their day together. This daily planning meeting is most often referred to as a stand up. Stand up is timeboxed to 15 minutes and is held in front of the task board for the sprint.

Just enough planning, just in time. Agile Planning hinges on these two statements. By limiting the amount of effort spent on planning things far into the future, Agile is able to embrace change. Agilists accept that it's impossible to know every relevant detail at the beginning. Agile Planning is established around these foundations. Preparing your team for this shift in thinking is going to be critical to their success. The first way to get them used to the new way of planning is to provide them the vocabulary they need to do the planning.

Once you have that list, just set out to fix any and all of the organizational impediments that they told you about. Have them tell you what needs to be fixed and rank those items in order, from most important, biggest problem, to least important, smallest problem. Now, I realize this is a lot easier said than done. In many organizations, the biggest impediments to Agile are also key software delivery tools and milestones. After an Agile pilot, most Agile teams report that their old methods of testing software and promoting software to production don't work very well in an Agile methodology.

Before you got your Agile pilot off the ground, you did a lot of work to determine why you wanted to try Agile in the first place. Now that the pilot's over, which of those reasons are motivating you to keep going? It may not be the same reason that you started with. After your pilot, you asked your stakeholders how they felt about it, and its results. You also heard the reasons they wanted to continue with Agile. Maybe they were happy that they received a product that matched their vision and came in under budget.

While we recognize that there are allot of creative, non-repetitive, variable work in agile development projects, many work items, ceremonies, and activities can benefit from systematic, reproducible and standardized tasks test and options that can be captured in customizable checklists prepared and used by empowered agile teams.