Agile or Waterfall . . . What Really Matters is Fit
- July 13, 2016
- Leave a comment
Many companies struggle with the debate about whether to follow agile or waterfall project management methodologies. What really matters in any situation is fit.
In one company I worked with, the question of agile versus waterfall became paralyzing. As the company grew in size and complexity, the executives wanted to adopt more formal project management discipline and they were struggling with the choice between the two. It came to a head when the organization started a very large and complex project that required software development, new vendor relationships, regulatory approvals and client integrations. It seemed the perfect time to take a stand across the organization about how the newly grown company would move forward. The software developers were promoting an agile approach while the vendor management team was resisting and advocating for waterfall.
I am a huge fan of agile methodologies. Agile is a highly interactive and collaborative approach to project management where the design and build phases are delivered in an iterative process. For example, I once set up an agile team to update a piece software to calculate foreign exchange. This was a relatively simple piece of code that had minimal points of integration. We were able to co-locate the product manager with the several developers and a scrum master (i.e. PM) and gave them three months to complete the task. Agile methodologies work brilliantly in software development and many product development situations. But, agile does not work everywhere.
Waterfall, or traditional, project management methodology follows a sequential process through well-established phases typically including initiation, design, build and implementation. Waterfall project management was developed in the construction and manufacturing industries. For example, if you are building a house, you need to make sure that the carpenters finish building the walls before you try to install the electrical. In a corporate setting, when you have fixed delivery dates, physical assets to order with fixed timelines, vendor contract negotiations, regulatory approval process or highly complex system across multiple platforms, a waterfall approach will help you manage the risk associated with timelines and complexity.
Both methodologies clearly have strengths and weaknesses, and the debate continued at the company I was working with. The product, marketing and IT teams were already using agile techniques of co-location and collaboration, and the project management team was taking an agile approach using daily stand-up meetings, two-week sprints and tracking weekly accomplishments on a Kanban-style white board. At the same time, the business analysts were using waterfall methods to track changes in the technical design and document requirements, and the vendor management team was using the waterfall approach to document vendor processes and develop a fixed schedule with milestones for the contract negotiations with a new supplier.
Each team involved in the project, from product design, marketing, application development, testing, vendor management, operations and business systems analysis, was doing good work. But the company at large was stuck in an intellectual debate about whether they should adopt agile or waterfall practices consistently across the organization. However, consistently adopting one style may not work. My approach has always been to use what works best in each situation.
To shake up the thinking, I talked with each functional team to find out what they were doing that was working and I established weekly team meetings to share these best practices across the functional teams. Each team lead shared what they were doing with the rest of the project team, and I praised, highlighted and publicly applauded the activities that were most effective, regardless of whether they were agile or waterfall. The result was that the importance of each team’s role was emphasized and recognized by the group, and we all developed an understanding that different approaches work better in different areas. Together, we built a mosaic of agile and waterfall practices.
Finally, the project manager implemented regular check-ins with executive stakeholders to give each functional lead an opportunity to share their successes. Public recognition helped sustain these new shared practices and it got the executives involved as well. But the best motivation for the team to adopt this hybrid approach was providing consistent communication and giving each team the autonomy within their domain to do their best. Of course pizza lunches, team hats and cookies also helped! The project was delivered on time and everyone got more comfortable with the possibility of using both agile and waterfall practices together—focusing more on which was the best fit for the situation.
Nancy Icely, WMC Toronto
See Nancy’s original LinkedIn article here.
The opinions represented here do not necessarily represent WMC’s views as a whole.