Don’t Fall into the AgileFall Trap
6 July 2017
You are right: Agilefall is not a word. I made it up while working with an organization that was transitioning from Waterfall to Agile but was stuck tightly to its Waterfall principles. We had to translate the product/sprint backlog into a Microsoft project plan and create Gantt charts for development and QA that were completed in the sprints. This is a common problem with teams that are transitioning from Waterfall projects (or even starting “fresh” with Agile). It is hard to imagine any team transitioning from traditional Waterfall to Agile without facing any challenges.
If you have worked in a particular way for a long time, it’s difficult to change course and switch to something new. We all experience these hurdles when we try to change our habits. But sometimes we need to get rid of bad habits, don’t we? So if you really want to move to Agile, you have to come out of your Waterfall comfort zone. I have encountered some common issues when helping teams transition from Waterfall to Agile. You might have encountered similar ones, so let me share my experiences and actions that might help you to tackle similar challenging situations.
Any organization that decides to transition to Agile has to get buy-in from its leadership. I presented the pros and cons for both Waterfall and Agile and got consensus from the Project Management Office to start transitioning projects to Agile in phases. It is a significant investment at the beginning, so you need to make sure that your organization is ready to commit to the training and tools — and to the effort involved.
Also, hire Agile coaches and ScrumMasters with project management experience who know both worlds and can understand the concerns by drawing from their own experiences and challenges.
Once leadership is committed to supporting the Agile transformation, look for pilot teams. Your ideal pilot team includes a few members with Agile experience. We had some team members who were reluctant to move to Agile. They had many concerns that stemmed from beliefs that Scrum is only a mini Waterfall, that the team wastes a lot of time in ceremonies, or that it’s just another way to micromanage people. My advice is to go slow. Let your teams realize the need for Scrum events and come back to you, rather than you setting up all the ceremonies from the beginning. I started with only two-week commitments and daily stand-ups. I let them adjust and understand Agile gradually. After two sprints, the team itself realized that they needed a clear scoping of the stories, and I introduced grooming sessions to define scope and added acceptance criteria. After the fourth sprint, the team realized that they were either overcommitted or undercommitted, and they were looking for ways to judge their capacity. I added a planning session that helped them understand capacity planning. By the fifth sprint, the team was able give demos to leadership and other stakeholders, as well as to improve burn-down charts and velocity.
Buy-in from management and stakeholders
Once you see that the pilot teams are running well — after perhaps five to six sprints — you can include Waterfall project managers from other teams into your team demos. Let them see the benefits of having deliverables in two weeks. When I involved project managers from other teams, they were excited to see the demos. They had never seen anything tangible for other projects until the very end. Demoing and continuous communication made our client collaborative and supportive. This was the trigger point for other managers, who were struggling to get approvals from clients and looking for more feedback. The lack of timely feedback is a deadlock in the traditional Waterfall model, as the team cannot move to development until all the requirements and design are approved. At the same time, the client is unable to provide clear requirements without seeing a working product. Clients provide better suggestions and feedback when they see something tangible, rather than a proof-of-concept out of flow charts and bullet points.
Recruiting experience from both Agile and Waterfall
When you are able to show the benefits of Agile to other managers and convince leadership that Agile really works, you will have started a revolution in the organization that will make all the difference. It sounds simple, and that’s the beauty of Agile. It looks straightforward, but mastering and executing the process is hard. That’s when you need coaches who have implemented projects in both methods. Otherwise, if you have a traditional Waterfall manager just moving to a ScrumMaster role, you will see the stand-ups become status meetings, where the so-called “ScrumMaster” takes notes, defines action items, and follows up with the team throughout the day.
Increase the probability of success
If you decide to move to Agile, you have to believe in and commit to its fundamentals. You have to make sure that your leadership gives you the green light. You should never go full-on Agile from the beginning; instead, allow the team to understand and incorporate the principles gradually in their daily work. The whole process requires time and patience. But if you really understand the benefits and believe in Agile, you will be successful.
Best of luck!
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.7 (11 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.