The Agile Waterfall Trap

This blog post is written by  Henrik Lehtonen

This blog post is written by Henrik Lehtonen

In contemporary software development being agile is the norm. “Being agile” is a rather floating expression however (as it should be, mind you), which doesn’t add up to much in terms of successful projects unless the daily approach to tasks by developers and the business is still stuck in the waterfall world.

    When starting a new sprint the team normally defines a goal for it and selects a set of user stories to implement. The quality of the stories varies and in most cases they are lacking either in terms of what the developer needs for implementation or what the user actually wants. Herein lies the waterfall trap that so many traditional companies fall into: waterfall-style development inside an agile sprint. Finalising a story and pushing it onto QA without having a short feedback loop between the developer and the user (or more commonly the business representative) falsely seems to move the project forward even though in most cases it will only have a hidden cost of producing sprint defects, additional stories or merely user dissatisfaction and the loss of business value in the long run.

    In order to avoid the trap the business representatives must have sufficient availability within the project and the team, but also the developer must possess the mindset of wanting to produce a solution that best serves the business side. The first feedback conversation should optimally take place even before starting the implementation, in order to have both sides on the same page and to avoid the possibility of misunderstandings. From there on the developer should always discuss about any UI and UX decisions that need to be made during development. Technical implementations are of course up to the developer and his/her expertise, and the feedback conversations are also a good place to bring up improved solutions that the developer might have been pondering. The last check-up should then be done before submitting the story as to make sure that both sides are satisfied.

    Even if this might seem like time consuming, these feedback conversations (when done frequently) are normally very brief. A few minutes in Hangouts, Skype or such will usually be sufficient and leave both sides with an improved view of the current status. The gains of this modus operandi are also evident in the long run: fewer stories circulate back to development through bugs and/or defects, which keeps the project timeline better in check.

    In the modern world of software development the programmers can no longer just hunch back into the corner and work in solitude. Instead we must keep in mind, as my colleague put it, that we are indeed in the service business.