How to Implement Agile Concepts in a Waterfall World

 So, you’ve become Agile-curious. Perhaps you attended a training or embarked on a journey of professional development that has you wondering how you can start incorporating Agile or scrum concepts into your more traditional waterfall organization. You create a backlog to manage your huge load of work, and you start to organize your workload into sprints. You’re cruising along, and getting things done, when management says, “Can you give me a project plan, with scope, resource, and time estimates for the service management initiative”?

You’re frozen, an Agile deer, in the headlights of a waterfall world. Do you try and win management over to the world of Agile? Or do you consider writing out a project plan in a traditional waterfall template you have sitting around? How exactly do you implement Agile in a waterfall world?

Acknowledge the Waterfall

It may be easy to dismiss your organization’s adherence to traditional waterfall project management affinity as a product of old-style management, but waterfall project management does have some aspects that mesh well with the way things work in the real world.

First and foremost, budgets are a huge factor into why your organization is still using waterfall. Almost every organization uses a yearly budgeting cycle, and waterfall allows for planning on how long things will take and how much they will cost. It packages a project up with a neat bow and lets us plan for how it fits into our vision for the upcoming year.

Another reason organizations like waterfall management is from the aspect of project portfolio management. Similar to budgeting, we can know when projects are set to begin, when they end, and how many we have going on at once.

With both of these in mind we can empathize with our leadership in order to better understand why they may be hesitant to move to Agile methodologies.

Win Over Management

Management may not be directly averse to Agile; they just may need information in a manner that makes sense. Proponents of Agile will note that the removal of sunk-costs and the ability for a project to iterate and evolve are huge plusses of Agile methods. Shortening the testing and feedback loops allow us to get our hands, and our users/stakeholders’ hands, onto something sooner, and can prevent failure and disappointment down the line. How many times do we embark on a new project to implement the next big system in our industry, only to get it into the hands of our users a year into the project and have them notice bugs or errors or give very negative feedback?

Beyond touting the benefits of this approach, you also gain the benefit of letting management have more insight into how things work. By involving leadership in prioritization meetings for your backlog, you get a chance to involve them more in important decision-making, and allow them to feel more ownership over the project than if they were receiving progress reports on the triple-constraint-related items of waterfall. Beyond a Gannt chart, we can now have an opportunity to work with leadership in a kind of stakeholder relationship, so they can help understand why choices are made.

With this in mind, using software to manage Agile processes and giving management a dashboard or insight into the backlog and planned sprints or releases can provide them a resource to see when things will be done and to track progress in real time. While not exclusive to Agile, it does make things much easier to track. This same tracking also can help us gain much better insight into how long things take. In a waterfall world, we usually frontload resource estimates and throw in ballpark figures for timing. In Agile, we can constantly refine our task-sizing and effort estimates to better inform leadership of how much effort something will take and how we can work toward its completion.

Translate What You Can

Suppose your leadership line still isn’t won over, or you’re making slower progress than you want in convincing them. One option you can try is to figure out ways to translate your information into a format they may like. You don’t want to end up spending all of your time writing reports out in both Agile and waterfall formats and duplicating efforts, but there are perhaps some happy mediums you can find between the two.

A typical backlog is not exactly like a task list or work breakdown structure in the world of waterfall, but you can try and translate the two by upfronting a backlog that you think you’ll have during your planning and design sessions. You can present this as tasks, and anytime new work comes into the backlog, write it in as a “change order” to add as a new risk or item for management to reprioritize. This can be even easier if you are already using tagging or applying other metadata to your backlog in order to help figure things out.

So how do you translate effort and timing, if you’re working in 2 week sprints, but your project proposal needs to be discussed in the scale of a year? This one can be tricky, but if you start to think of things in terms of how many sprints you can potentially have, and how many releases you are aiming for, you can start to think on bigger-picture scales.

Start Somewhere First

So maybe you don’t have the opportunity to go full-Agile in your waterfall organization. Your best option may be to embrace the waterfall for those bigger projects that need consistent reporting and oversight, and to use Agile somewhere small first. If you have projects that are internally managed, or smaller scale, it may be your best option to start using your newfound techniques there.

Generally, results speak for themselves. If you and your team find success using the tools and techniques on a few small projects, those results may allow you to gain a foot in the door to start applying aspects of Agile in other bigger projects.

It is tempting to see the benefits of Agile methodologies and want to go all-in right away, but sometimes starting somewhere small can bring about the biggest benefit to you and your team. Not only does it allow you to practice your new skills, it keeps everyone happy, and helps you hone those same skills and learn things you might change next time around.

Chris Chagnon is an ITSM application and web developer who designs, develops, and maintains award-winning experiences for managing and carrying out the ITSM process. Chris has a Master of Science in Information Technology, and a bachelor’s degree in Visual Communications. In addition, Chris is a PhD Candidate studying Information Systems with a focus on user and service experience. As one of HDI’s Top 25 Thought Leaders, Chris speaks nationally about the future of ITSM, practical applications of artificial intelligence and machine learning, gamification, continual service improvement, and customer service/experience. Follow Chris on Twitter @Chagn0n.