There are still teams running waterfall. For certain processes – waterfall may work just fine. For software development, however, this is becoming a rare sighting. The paper written by Winston Royce in 1970 described a process for getting software through an organization. The term ‘waterfall’ itself would be coined 6 years later. We often joked that a point of no return would come and the software would often be pushed off the ledge and into the customer’s hands. The customer very often saw it for the first time after several months or more were spent hidden in the depths of the company while it was being created.
“But Agile will make it Worse”
– of course it will silly.
Even Shakespeare said it so long ago. The fear of the unknown causes us to stick comfortably with what we know. Even to fight to hang on to what is comfortable and familiar. Change and the unknown “…puzzles the will And makes us rather bear those ills we have Than fly to others that we know not of? Thus conscience does make cowards of us all, And thus the native hue of resolution Is sicklied o’er with the pale cast of thought, And enterprises of great pith and moment With this regard their currents turn awry, And lose the name of action.” – Hamlet
Fear stalls and halts us. Often adapting scrum after running waterfall causes initial chaos, and will make it worse -> because problems will be uncovered and exposed. We then rely on the teams, THE PEOPLE, to solve those problems. It takes a certain thinking to be agile, to work in teams, and to continuously improve. Fear doesn’t help any bit of it. To be agile denotes an active participation in moving forward through some obstacle laden terrain. A waterfall allows us to sit back relax and simply be swept away by a current until it is too late. So, HECK YA! Get excited about seeing those problems. Unless we get to the truth and start solving them – we won’t be getting any better at this.
There is never a perfect time to adopt a better process, -there is only now.
Ever in the middle of a release, or just having negotiated the large requirements for the next release – a program may have reluctance to change. The risk, may seem too high when all our requirements for the next six months have our customers in lock down and bound. Running with agile teams has a certain side effect that you cannot discount. Besides the numerous ways agile actually REDUCES your risk, your organization is now investing in having some great teams. Over times these teams will change the characteristics of the organization. In his book Scaling Software Agility, Dean Leffingwell spends his entire second chapter explaining why Waterfall doesn’t work. Just after that introduction to agile methods.
Knowing how fearless most quality assurance/testers have been on some of my teams I have come to cherish plain words. The ability to simply tell it like it is. Just the facts, while NOT stopping here. It is another starting point. It always helped to dig into the problem and start moving towards a solution together. The wisdom in the tests wasn’t to say the software was broken and throw it back over the wall. Instead it was in the collaboration of multiple roles seeing it at the same time, making it a better solution for the customer who needed it.
Once you are tired of falling off the waterfall in an anachronistic organization, paddle on over and take a climb up towards the peak of an agile mountain. You may need a Sherpa to guide you, but the advantage is absolutely stunning. Build great teams focused on delivering great software and then build an organization that enables that ecosystem to thrive. All the while, connecting with and earning the trust of your customers. What more might there be to say except…
Red Rover Red Rover.