Making the switch: Going from Waterfall to Agile

If you're in a company that is making the switch: Going from Waterfall to Agile there are a few things to look out for to make a great and successful transition. One of those things is getting buy-in, and it's not buy-in from anyone, but most importantly getting your C-level suite on board with the change.

Salesforce was a waterfall company

Salesforce back in its heyday, believe it or not, started out as in a waterfall process, actually, to be honest, most of the product managers and project managers that have more than 15 years of experience did, we worked in waterfall methodologies but still had a release planning schedule, often enough these were very long. At least in my experience. Salesforce leaped going from the waterfall into agile, in 2007, they had a small team and found that their releases in waterfall were pretty quick, but once the company started to scale and more people were on board, things just started to become dysfunctional, big to move, and it wasn't a process that would take them into the future.

Scaling up for salesforce hit its limitations in waterfall

Customers were not getting their needs met, nobody knew what to do about it and their product cycles were so long that at any given time, they weren't able to meet the needs of the customers quickly enough and their developers were not able to sync up in time.

The big leap into Agile

Salesforce made the big leap, into agile and decided to do it all in one time across the whole company, they rolled it out across 200 developers over a period of months and they measured that 80% of their team were starting to self-organize.

Salesforce created a cross-functional rollout team, to ensure that interdisciplinary teams were created at agile and their executives were on board with the concept and mindset of Agile. Salesforce found it important, to leave their teams with a certain amount of discretion, where principles over mechanics are important, they also provided radical transparency so they had open meetings for anyone that could come to meetings. In addition to this, they provided and leverage professional learning, so ensuring their people were able to get certified, have training from agile practitioners, in order to train the muscle of thinking with agile.

The Executive Buy-In Challenge (And How to Actually Get It)

Here's what most people get wrong about executive buy-in: they think it's about explaining agile methodology. It's not. Executives don't care about standups and sprint planning - they care about business outcomes.

I've seen countless product managers create PowerPoint presentations about the benefits of agile, complete with diagrams of the development lifecycle. The executives nod politely and then ask, "When will the project be done and how much will it cost?"

Speaking Executive Language

Instead of talking about "iterative development" and "cross-functional teams," talk about risk reduction and faster time to market. Here's what resonates:

Don't say: "Agile allows for more flexible development cycles" Do say: "We can reduce the risk of building the wrong product by validating features with customers every two weeks"

Don't say: "We'll have better collaboration between teams" Do say: "We can respond to competitor moves 3x faster and capture market opportunities before they do"

Don't say: "The team will be more motivated" Do say: "We'll reduce developer turnover costs and ship features customers actually want"

The CFO Conversation

The CFO is usually your biggest skeptic. They've lived through budget overruns and missed deadlines, and agile sounds like "we don't know what we're building or when it'll be done."

Address this head-on. Show them data from similar companies that made the transition. Explain how shorter feedback loops actually reduce costs by catching expensive mistakes early. Most importantly, propose a pilot program with clear success metrics they care about.

Look internally for Allies

The role of a program manager is important for any big enterprise-level organization when big roll-outs happen across multidisciplinary teams, from sales to marketing and then into tech, program managers are the organization's communicators, they are the ones that schedule everyone in, ensure that materials are prepared, people contributed feedback through sessions and iron away any knots that could go awry in rollouts.

Finding Your Change Champions

Every successful agile transformation I've seen had internal champions - people who were already thinking this way before the official rollout. They're usually:

The Frustrated Developer: Someone who's been complaining about long release cycles and wants to ship code more frequently The Customer-Obsessed PM: The person who's always pushing to get customer feedback earlier in the process The Data-Driven Manager: Someone who wants more visibility into project progress and team productivity The Innovation Advocate: The person who's been saying the company needs to move faster to stay competitive

Find these people early. They'll become your unofficial trainers and advocates when the formal rollout begins.

The Resistance You'll Face (And What It Really Means)

"We need detailed specifications before we start" = "I'm afraid of being held accountable for changing requirements" "How will we know if we're on track?" = "I don't trust that we'll deliver what we promised" "This seems chaotic" = "I feel like I'm losing control over the process" "Our clients expect fixed timelines" = "I don't know how to sell uncertainty to customers"

Address the underlying concern, not just the surface objection.

Understanding the Methodological Shift

Managers are pressured to provide deliverables and key dates, we all know that waterfall methodology starts with some heavy documentation and that gathering requirements gathering is the first step to start a project.

We know that the requirements of the project are written up and addressed before the project begins and sign-off for the complete project or thing you are building is needed before you send it over to design or handed over to development.

With waterfall, we also know that each step of the software or product lifecycle, needs to be done before working on the other and there is one big plan from start to finish that details everything. The other great aspect of the waterfall is that it ensures cost estimates, deadlines, emphasis on the scope.

Agile on the other hand, unlike Waterfall, create shorter cycles, fundamentally known as sprints and Agile emphasizes iterative development or releasing software in pieces.

I constantly remind myself of the following:

Before you start huffing and puffing on why Agile is better than waterfall, take a deep breath, remember both methods work, it just depends on the project.

When Waterfall Actually Makes Sense

Let's be honest about this: some projects genuinely work better with waterfall. If you're building a bridge, you can't iterate on the foundation after cars are driving over it. If you're integrating with a legacy system that has one deployment window per year, agile might not help you.

Waterfall works well when:

• Requirements are genuinely stable and well-understood

• The technology is mature and predictable

• Regulatory compliance requires extensive documentation

• The cost of iteration is prohibitively high

• External dependencies operate on fixed schedules
  

The Hybrid Reality

Most organizations don't go pure agile - they create hybrid approaches that combine waterfall planning with agile execution. This isn't "doing it wrong" - it's adapting methodology to organizational reality.

You might have waterfall budgeting and contracts with agile development cycles. Or waterfall architecture decisions with agile feature development. The key is being intentional about where you apply each approach.

Going from Waterfall to Agile (Cost, Time & Budget)

Agile doesn't usually commit to a time, budget, or scope, and to understand this breakdown a bit more, I like using the Iron Triangle.

Understanding the relationship dynamics of the Iron Triangle and the Agile inverted triangle

Simply put we know that quality is a dependency of both, but here is the key difference:

The Iron Triangle: Fixed the Scope, let's allow time and cost to vary Agile Inverted Triangle: Time & Cost are fixed, but the scope if the one that varies

Quality, putting this in the center of the triangle, simply means, that there are constraints limiting quality output by the project's budget, its deadline, and the scope (features). Changes in one constraint, necessitate changes in others to compensate or quality will suffer.

The Triangle Conversation with Stakeholders

Here's a script I use when explaining this to stakeholders:

"In our old process, we promised to deliver 50 features in 6 months for $500K. When requirements changed or we discovered complexity we didn't anticipate, we either shipped late, went over budget, or cut quality corners.

In our new process, we're committing to spend 6 months and $500K building the most valuable features we can. We'll deliver working software every two weeks, and you'll have full visibility into what we're building and why.

The difference? Instead of hoping we guessed right about what you need, we'll learn what you actually need as we build it."

Managing Scope Creep in Agile

Just because scope varies doesn't mean it should grow infinitely. Agile requires different scope management, not no scope management.

Establish Feature Prioritization: Use frameworks like MoSCoW (Must have, Should have, Could have, Won't have) or value vs. effort matrices Create Definition of Done: Clear criteria for when features are complete Regular Scope Reviews: Every sprint review is an opportunity to reassess priorities Stakeholder Education: Help business partners understand that saying yes to everything means saying no to shipping on time

What works for me is to find compromises

When we think about the relationship between Waterfall and Agile, we need to compromise on context, the common view of agile deliverables, we know how long we want to spend on a project and typically how many resources we have to go into it but we're not sure how much work they can deliver.

Start with something Small

Start with something small first and incrementally add to it, by iterating, and delivering frequently, when we hit the 'date' we just accept whatever scope we've delivered up until that point and call it 'done. In other words, the scope is gradually building itself and accumulating over the time provided.

The Pilot Project Strategy

Don't transform your entire organization at once. Start with one team, one product, or one project that's well-suited for agile.

Choose Your Pilot Carefully:

• Pick a project that's not mission-critical (room for learning)

• But not so unimportant that nobody cares about the results

• Select a team that's open to change and has good internal dynamics

• Ensure stakeholders are willing to participate in the process

Measure Everything:

• Time to market for features

• Customer satisfaction scores

• Team satisfaction and engagement

• Defect rates and technical debt

• Stakeholder satisfaction with visibility and communication

Use these results to build the case for broader adoption.

Understand that Scope may vary but expectations won't

Scope often varies, but be careful because expectations won't, this is the honest truth about agile, we cannot know everything about the whole project upfront and it's a futile attempt to try, so we must allow the scope to change as we discover and learn or when the product progresses.

Managing Expectations in an Agile World

The hardest part of agile transformation isn't teaching teams to work differently - it's helping stakeholders understand what they should expect and when.

Set Communication Rhythms: Regular demo sessions, progress reports, and stakeholder check-ins Provide Transparency: Show the product backlog, velocity charts, and burndown data Explain Trade-offs: When you say no to a feature, explain what you're saying yes to instead Celebrate Learning: Frame discovered complexity as valuable learning, not failure

The Contract Problem

Many organizations struggle with agile because their contracts and vendor relationships are built for waterfall. You can't have agile development with waterfall contracts.

Internal Contracts: Change how you write project charters and business cases to focus on outcomes rather than features Vendor Contracts: Move toward outcome-based contracts or retainer models rather than fixed-scope agreements Customer Contracts: Educate clients on the benefits of collaborative development and flexible scope

Leverage T&T 'Tools and Training'

I made up an acronym called T&T and really it's just Tools & Training, but the way I look at this in any type of subject matter is 'Arm yourself with an arsenal of resources, worksheets, and workshops', even appointing guest speakers will help kick off change.

Be open to try different tools and find educational courses that you can use as an incentive to train your team, ensure that there is openness in the team, be patient, and don't rush into it, people need time to get accustomed to agile and if there is not enough guidance it is likely to result in failure. Conduct a 1-day workshop on the methods of Agile, to inspire the 4 values and 12 key principles to your people and finish off with a prize and pop quiz, even a company certificate of participation.

The Training That Actually Matters

Most agile training focuses on ceremonies and artifacts - standups, retrospectives, user stories. That's important, but it's not what makes transformations successful.

Mindset Training: Help people understand the principles behind the practices Customer Empathy: Train teams to think from the user's perspective Collaboration Skills: Many people have never worked in truly cross-functional teams Facilitation Skills: Agile requires different meeting and communication skills Technical Practices: Code reviews, continuous integration, automated testing

Tools That Support (Not Drive) the Process

Start Simple: Sticky notes and whiteboards before Jira and Azure DevOps Focus on Communication: Tools should make collaboration easier, not create overhead Measure What Matters: Velocity and burndown charts are useful, but customer satisfaction is better Evolve Gradually: Add tool complexity as teams mature in their agile practices

Essential Tool Categories:

• Collaboration: Slack, Microsoft Teams, or similar for daily communication

• Project Management: Jira, Azure DevOps, or Trello for backlog management

• Documentation: Confluence, Notion, or similar for shared knowledge

• Code Management: Git-based systems with good branching strategies

• CI/CD: Automated testing and deployment pipelines
  

Building Learning Culture

Agile transformation is fundamentally about creating a learning organization. This requires:

Psychological Safety: People need to feel safe admitting mistakes and asking questions Experimentation: Regular opportunities to try new approaches and techniques Reflection: Built-in time for retrospectives and process improvement Knowledge Sharing: Communities of practice, lunch-and-learns, and internal conferences

Build Empathy with your Stakeholders & don't fall into a hubris mode

Discussions with stakeholders and customers are tricky and getting them onside and agile is not typically a magic bullet type of solution for unrealistic expectations, the Iron triangle will destroy that and still applies its truth.

The Stakeholder Journey

Remember that stakeholders are going through their own transformation. They're learning to:

• Give feedback on working software instead of specifications

• Make decisions with incomplete information

• Trust teams to make good technical decisions

• Accept uncertainty in exchange for flexibility

Support Their Learning:

• Provide context for why things work differently now

• Show them how to be effective product owners and stakeholders

• Help them understand their new roles and responsibilities

• Be patient with their questions and concerns
  

Common Stakeholder Fears (And How to Address Them)

"How will I know we're building the right thing?" Response: "You'll see working software every two weeks and can change direction based on what you learn"

"What if the team builds something I don't want?" Response: "You're part of the process now - you'll review progress regularly and help guide decisions"

"How do I plan budgets and resources?" Response: "We'll work together to forecast based on team velocity and priority changes"

"What if we never finish?" Response: "We'll always have working software that delivers value, even if we continue adding features"

Negotiate

It's not uncommon to be in an organization, where compromise is made, so don't be afraid to ask questions to get to a compromise. In our role as Product Owners, we have to adapt to the organization, the people, culture, and the ways of working, if your initiative requires us to adopt from Waterfall to Agile and the transition is a lot slower than you had anticipated the first thing to do, is as questions and practice mindfulness at the same time, for some organizations, it's a rapid installation that scales throughout organizations and teams, for others it's a slow process, remember it's up to you to succeed changing mindsets, so ask questions to get to a compromise and learn to give as well as take.

The Art of Agile Compromise

Real agile transformation requires constant negotiation and adaptation. Here are the most common compromise areas:

Reporting and Governance: You might need to provide waterfall-style status reports while building agile practices Release Planning: You might plan releases in waterfall style but execute development in sprints Contract Terms: You might need fixed-price phases with agile execution within each phase Approval Processes: You might need formal sign-offs at major milestones while iterating between them

Gradual Transformation Strategies

The Stealth Approach: Start using agile practices within existing waterfall processes The Parallel Approach: Run agile pilots alongside existing waterfall projects The Incremental Approach: Transform one process or team at a time The Big Bang Approach: Company-wide transformation (high risk, high reward)

Most successful transformations use incremental approaches with elements of stealth practice.

When to Push and When to Yield

Push on: Principles that are core to delivering value (customer feedback, working software, collaboration) Yield on: Terminology, specific practices, and meeting formats Negotiate on: Reporting structures, approval processes, and planning horizons

Remember: the goal is better outcomes, not perfect agile compliance.

Measuring Success Beyond Velocity

Traditional agile metrics focus on team performance, but transformation success requires broader measures:

Business Metrics

• Time to market for new features

• Customer satisfaction and retention

• Revenue impact of released features

• Market responsiveness and competitive advantage

Organizational Metrics

• Employee satisfaction and retention

• Cross-team collaboration effectiveness

• Decision-making speed

• Learning and adaptation rate

Quality Metrics

• Defect rates in production

• Technical debt accumulation

• System reliability and performance

• Security and compliance adherence

Leading Indicators

• Stakeholder engagement in reviews

• Frequency of scope adjustments

• Time from idea to validation

• Customer feedback incorporation rate
  

Common Transformation Pitfalls (And How to Avoid Them)

The Tool-First Trap

Don't start with selecting agile tools. Start with understanding problems and desired outcomes, then choose tools that support your approach.

The Training-Only Trap

Sending people to Scrum Master certification won't transform your organization. Training must be combined with coaching, practice, and cultural change.

The Purist Trap

Don't let perfect be the enemy of good. Most organizations need hybrid approaches, and that's okay.

The Impatience Trap

Agile transformation takes 18-24 months minimum for lasting change. Don't expect immediate results or give up after the first few months.

The Leadership Disengagement Trap

If leaders aren't actively participating in the transformation, it will fail. This isn't something you can delegate to middle management.

Building Long-term Success

Creating Agile Leaders

Develop people who can:

• Coach teams through difficult decisions

• Facilitate productive conflict and discussions

• Balance competing priorities and stakeholder needs

• Adapt processes based on what they learn

Sustaining Momentum

• Regular transformation retrospectives

• Continuous learning and skill development

• Recognition and celebration of improvements

• Connection to broader business success
  

Evolving Your Approach

Agile transformation isn't a destination - it's an ongoing evolution. Stay curious about new practices, tools, and approaches that might serve your organization better.

Going from Waterfall to Agile (Cost, Time & Budget)

Key Takeaways

Agile for the right project/product can lead to superior customer satisfaction

The process of agile if applied to the right project and product can ultimately lead teams to produce superior customer satisfaction, keep iterations small, establish the willingness to embrace and respond to change, and encourage learning as well as unlearning and for you to remain curious about your customer and your competitors.

The Real Success Factors

Executive Commitment: Not just approval, but active participation and support Cultural Alignment: Agile values must align with organizational culture or both must evolve together Customer Focus: Keep user value at the center of all decisions and processes Continuous Learning: Build systems for ongoing improvement and adaptation Patience and Persistence: Transformation takes time and requires sustained effort

What Success Actually Looks Like

Successful agile transformation isn't perfect adherence to Scrum or Kanban practices. It's:

• Teams that regularly deliver value to customers

• Organizations that can respond quickly to market changes

• People who feel empowered to make decisions and solve problems

• Stakeholders who trust the development process

• Products that customers actually want to use and pay for

The goal isn't to become agile - it's to become more effective at delivering value. Agile practices are just one way to get there.

Remember: every organization's transformation will look different. Focus on the principles that matter for your context, adapt the practices to your reality, and measure success based on the outcomes that matter to your business and customers.