Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

Handling Reminisces of a Glorious Waterfall Past

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

As a coach, I’ve had several opportunities to be involved in the process of big organizations moving from waterfall to agile. You usually start with frowning faces, people coming to meetings reluctantly, armed with a load of cynicism and skepticism. Then after some time, something magical happens – things change to the better. Spring has arrived!

During those first months, at the beginning of the implementation, times are hard. People are struggling. And very soon you start to hear complaints and people telling you how great it was before all this. Before all this agile. When design documents were design documents. When they had time to work. Suddenly the past becomes a lost haven. In training, in coaching sessions, you hear people reminiscing about some glorious past.

The key to addressing these issues is to find out how exactly was it at those times.

“In the past, we had time to write thorough and in-depth designs!”: One of the first issues is how to move from big design documents (many times part of the contracting process with the client) to a more agile process. A good question to ask is whether those designs were actually implemented as is or were any changes made during development. Initial designs should still be made, of course, to see the big picture and set the path ahead, yet the focus is more on the conversation and less on a detailed document.

“What do you mean you did not meet your commitment? In the past, people would die to make it on time!”: Very fast, managers see that teams do not meet the sprint’s commitment, and questions about meeting the overall timeline start to surface. At first, you might get the (false) impression that when the waterfall was used, everything ended on time. This is usually not the case. Start asking how things really happened. Was everything working when they finished? Were any defects detected by the client? In addition, it should be noted that it takes time for a team to find out it how much it is that they can do in iteration. For that you need patience.

“How come everything breaks down on the first week of development? In the past at least the first few months were calm”: Agile brings up issues very early in the process, unlike the waterfall process, in which things surface late in the game. This early flood of issues raises a concern in management. This should be anticipated.

”Since we started this agile thing we are under constant pressure! In the past, we could bide our time”: As stated in the previous point, while in a waterfall there’s a long quiet time (before the chaos starts) in agile there should be (but that isn’t always the case) constant healthy pressure. If the pressure is not healthy, it is a good time to find out why. In addition, never forget that people need time to adapt to the change, and to think of the little tweaks they need to do to make it work. Being under heavy pressure is key to failure.

“Suddenly people are coming up with ideas about how we should do things, questioning decisions about what we do. In the past, we didn’t waste so much time on that!”: when the implementation goes well, you see oppressed people transforming into thinking people who care, people with ideas, which is good but changes the dynamics of the organization, specifically at lower ranks. This is something to discuss when starting the implementation.

”Product Owners? We don’t have the budget for that. We used to do just fine without it.”: Product owners were always there, hidden under the disguise of team leaders and experts (and sometimes, others). Someone always needs to make the requirements clearer – it is good to ask who did it and then uses it to explain why no new budget is required – it was part of what they did. If nobody did it, it was probably manifested in quality issues and someone should probably start doing it.

Making a change is always hard. Moving from waterfall to agile is a big change. Always remind people why they are doing this change and always help them to remember how it really was back in the good old days.

Subscribe for Email Updates:

Categories:

Tags:

Jira admin
Agile Delivery
Program Increment
Continuous Delivery
Scrum Guide
QA
Software Development
Quality Assurance
Implementing SAFe
Limiting Work in Progress
Agile
AI
SPC
Engineering Practices
Professional Scrum with Kanban
Agile Program
Continuous Planning
Risk Management on Agile Projects
Releases Using Lean
Lean and Agile Techniques
System Integration Environments
System Archetypes
Agile Release Planning
Lean Agile
Certification
SAFe DevOps
Hybrid Work
Agile Project
Nexus
User stories
Lean and Agile Principles and Practices
Agile Exercises
Scrum Primer
SAFe Release Planning
Principles of Lean-Agile Leadership
AI Artificial Intelligence
Continuous Integration
Risk Management in Kanban
Jira Plans
Agile Games and Exercises
Professional Scrum Master
ScrumMaster Tales
Agile Community
Nexus and SAFe
Scrum.org
Jira Cloud
Lean-Agile Software Development
Portfolio for Jira
The Agile Coach
Agile Project Management
Agile Mindset
Kaizen Workshop
speed @ scale
ATDD
Lean-Agile Budgeting
Team Flow
Kaizen
Elastic Leadership
Risk-aware Product Development
RTE Role
Development Value Streams
BDD
Tools
ART Success
SA
Agile for Embedded Systems
Agile Contracts Best Practices
Enterprise DevOps
Process Improvement
Kanban Game
Scrum Master
Systems Thinking
Sprint Retrospectives
Scrum
Daily Scrum
Keith Sawyer
Scrum and XP
ARTs
Product Management
Planning
Lean Agile Basics
Agile Product Ownership
Agile and DevOps Journey
Lean Agile Organization
GanttBan
Business Agility
Managing Risk on Agile Projects
Artificial Intelligence
Agility
Jira
Covid19
Implementation of Lean and Agile
Certified SAFe
Agile Israel Events
Kanban Kickstart Example
WIP
RSA
Release Train Engineer
Presentation
Lean Budgeting
ROI
Video
Lean Risk Management
NIT
Lean Agile Leadership
Agile Outsourcing
TDD
Nexus and Kanban
Atlaassian
POPM
An Appreciative Retrospective
Test Driven Development
Scaled Agile Framework
Spotify
RTE
IT Operations
Agile Development
LAB
Agile in the Enterprise
Lean Agile Management
Self-organization
Sprint Iteration
Amdocs
Introduction to Test Driven Development
Accelerate Value Delivery At Scale
Nexus Integration Team
Perfection Game
Agile Release Management
Introduction to ATDD
Legacy Enterprise
ALM Tools
Agile India
agileisrael
Frameworks
DevOps
Agile Risk Management
Product Ownership
Scrum Master Role
Kanban Basics
Applying Agile Methodology
Continuous Deployment
Agile Product Development
Acceptance Test-Driven Development
Rapid RTC
Built-In Quality
LPM
speed at scale
Pomodoro Technique
Code
Reading List
Agile Assembly Architecture
Legacy Code
Scrum With Kanban
Kanban
Games and Exercises
Coaching Agile Teams
Story Slicing
lean agile change management
The Kanban Method
SAFe
Change Management
System Team
Tips
Sprint Planning
Large Scale Scrum
Agile Games
Effective Agile Retrospectives
Webinar
Continuous Improvement
Atlassian
Slides
EOS®
AgileSparks
Entrepreneurial Operating System®
Lean Software Development
LeSS
Lean Startup
Agile Testing Practices
Nexus vs SAFe
ATDD vs. BDD
Achieve Business Agility
PI Planning
Agile Techniques
Professional Scrum Product Owner
Software Development Estimation
Agile Israel
Manage Budget Creation
PI Objectives
chatgpt
What Is Kanban
Agile Basics
Value Streams
predictability
Scrum Values
Kanban 101
Agile Marketing
A Kanban System for Software Engineering
Operational Value Stream
Advanced Roadmaps
Iterative Incremental Development
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart