When I go into organizations that claim they are using agile, I sometimes see mini waterfalls instead.
This is not surprising if you consider that almost 90% of organizations report that their company works on projects in an agile manner. With this being said, some misinterpretations are present. However, agile is a very specific approach to project management and one that mini waterfalls cannot form a part of. Let us look at the differences between the waterfall and the agile approach. And also, the warning signs of mini waterfalls developing to understand what can rectify this problem.
What is Waterfall?
It is termed waterfall because the project management process represents the flow of a waterfall through various activities. At the top of the waterfall is the requirements gathering stage after design, development, integration, testing, training, and rollout. The approach is considered highly structured and managed, and it does work well for certain types of projects. In particular, those that are unlikely to have evolving requirements and where there is certainty about the end goal.
In a waterfall development approach, doing all of the analysis and requirement building is upfront. Afterwards, they will be doing all the design. Then the development is all done in one go. Later on, they will be doing all of the testing stage.
What is Agile?
Agile differs significantly from the waterfall approach to project management. It evolved in the face of continuous business change. It is helpful when there are fewer certainties and when business requirements may adapt over time, or not well known, or both. When projects are run in an agile manner, they are iterative. Each stage is run incrementally, and there is much collaboration between people in different teams.
When project work is operating in an agile manner, all the different workstreams happen simultaneously. They also all conclude at the same time. Analysis, design, coding, and testing all operate concurrently, and they all finish together at the end of the sprint. This is quite distinct from taking a waterfall type of solution to project management. Another important difference is that in agile, teams are self-organizing. This does not occur in the waterfall project management approach.
Mini Waterfall Red Flags
It is a common error that agile teams start operating in the manner of mini waterfalls and continue to call it “agile”. Fortunately, there are warning signs that teams can look out for to avoid this scenario from happening. One trap that teams may often fall into is having the teamwork in silos. This is advantageous from some developers’ perspective as they have much more control over what they are doing). However, it does lead to mini waterfalls. This is because while it may seem efficient, it results in a longer wait for testing results. It is because testing starts happening after development.
Another key warning sign is when small aspects of the project (user stories) start becoming more than just short placeholders. When user stories start having their specification documents, this is not agile. Everything starts getting documented out for the user story, and the development is no longer iterative. Again, the testers then start working one stage behind the developers and not in the same iteration. What happens is, an iterative waterfall approach starts to build up — with each user story becoming a mini waterfall project in its own right. However, this is not what it means to be agile.
Other mini waterfall warning signs included the situation where only certain parts of agile seem to be going on in a project. An example scenario might be that the team is self-organizing and collaborating across disciplines. Still, that design has evolved to start happening at the beginning of the sprint and testing at the end. The fact that the team is self-organizing and collaborative may throw people off. They will realize that this is a mini waterfall in disguise, but that is what it is.
While mini waterfalls may feel comfortable for those working within them, the main problem is that the user will not get what they want. Not only that, but the timeline for project delivery starts to drag out. This will be dissatisfying for the customer.
True Agile Project Management
True agile project management is a way of operating that is embraced throughout the organization. Simply telling teams they will start working in an agile way and not having leadership on board will not lead to agile working. With this, there will be setting aside traditional project management needs and use the scrum instead.
In true agile project management, planning does not occur upfront the way it does in a waterfall system. As soon as planning and design start happening at the outset again, the team is working in a waterfall, albeit often a mini one. For agile to be effective, it requires tight and short feedback loops. This helps the project team to build a product that will meet the user/customer’s wants. This is because users can give their thoughts much earlier during user stories. This process of continuous feedback helps the project more quickly evolve into an end product that will meet the user/customer’s needs.
To move back from mini waterfalls to agile development, stop looking at the development phases of requirement production, design, development, and test. Instead, go back to considering one aspect of what the user wants, developing a small part of this, and checking in to see if it is right or how it could be better. Afterward, continue building iteratively until there is user satisfaction.
Summary
Where agile is not fully embraced through the organization, so-called “agile” teams can revert to the old ways and start developing mini-waterfalls within sprints. This is detrimental to the project because it extends project timelines, but it means that user feedback is gathered later on, leading to more work to produce something they want. True agile occurs when all aspects of the project happen simultaneously, including analysis, design, coding, and testing. Ultimately, the aim is to deliver value to the customer as often as possible.
Until next time, you are up to date.
Originally published at https://www.projecttimes.com.