Agilaterfall: When Agile becomes Waterfall

Agile when it's adhered to correctly can be very satisfying to a developer due to its productive nature. Constantly delivering working software in small iterations, what's there not to like? However when agile isn't understood and enforced by both the product owner and stakeholders, it can also mean going back to the days of waterfall. To help demonstrate my point lets take a look at the Agile Manifesto (in steps wiki):

• Individuals and interactions – in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
• Working software – working software will be more useful and welcome than just presenting documents to clients in meetings.
• Customer collaboration – requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
• Responding to change – agile development is focused on quick responses to change and continuous development.

The first two points, "Individuals and Interactions" and "Working Software" can be controlled and implemented by the product owner and development team. The final two points, "Customer collaboration" and "Responding to change", if not done correctly is where waterfall can creep in. I fully agree that not all requirements can be fully collected at the beginning of a project and not always at the start of the sprint during sprint planning. The acceptance criteria on user stories is not always going to be the complete picture and that's where the responding to changes will cater for this.

However in order to respond to changes you firstly need to know what the changes are, and requires the stakeholder to raise these changes after a sprint. These can then be built into the next sprint and burn down charts recalculated. Giving a more accurate reflection on where the project is in its development life-cycle.

A stakeholder without the understanding of agile and the purpose of using such a software development methodology can be potentially damaging to the project. If these changes are not raised in the first instant and left to the end of the project, then you are essentially adhering to waterfall. You are then in the situation of adding unplanned time to the end of the project due to the stakeholders new requirements.

Conclusion

The two main points to take away from this:

1. Have good user experience (UX) and business analysts to ensure acceptance criteria is as complete as possible.
2. Ensuring the stakeholder fully embraces the nature of agile and reports changes or issues during sprints. Not at the end of the project and therefore reverting to a waterfall approach.