At Appster, we practice Scrum as our software development methodology. The upside of this incremental and iterative philosophy is that we can deliver working software very frequently (every week) and yet be open to change during the course of the project. The downside is that it requires active involvement of the client. Clients who could sit back and relax after the heavy exercise of requirements gathering during Waterfall days find this challenging and, sometime, even revolting.
The team requires client presence (physical or over video conference) during Sprint Planning Meetings. This is the time when the team needs clarity from the client on the high priority user stories that can be picked from the top of the backlog as Sprint Backlog. The team might require client involvement during the course of the Sprint when it is faced with a priority decision (which stories to complete in the remaining time available) or maybe some clarification on an existing story or maybe a decision on the multiple options possible for implementation of a story. And finally the team requires the client to do User Acceptance Testing (UAT) of the build that the team generates at the end of the Sprint. This part is of key importance. UAT actually generates feedback for the team on how did it deliver against the requirements of the client. Even if it was spot on, the client might get “aha” moments during the UAT and might suggest changes (which are welcome in Agile) that would go on to improve the product.
While clients are available during Sprint Planning (actively or passively through a PO), it is hard to get them to do a thorough UAT. Maybe because they also have a day job or maybe because they are busy in other aspects of their business as an entrepreneur. Whatever the reason be, the lack of timely UAT hurts the project and demoralises the team. The team feels sad when it don’t get timely feedback as it feels that it is working on something not important enough for the project sponsor. It feels orphaned. The project suffers because the team might go off-course for lack of a corrective action that the UAT could have spawned.
As a result of delayed / improper feedback, client feedback accumulates towards the end of the project. At this point, two opposing forces come into action – the client who is giving feedback (which might have lost relevance due to lost time) and wants all his points to be considered; and the team which is wanting to wrap up the project and is inclined to ignore those points that the client is suggesting. This force completely dries up the agility that was intended into the project. The client is welcome to add more to the project provided he takes out an equivalent amount of work from the plan or allows more time to the project. The above scenario keeps the deadline but tries to add more work which might be relevant (for example bugs in the application discovered by the client).
For a successful project release and happy stakeholders (development team and the client), it is imperative that the client does timely UAT and provide feedback that can be fed back into the product backlog and the product can be developed with a sharp focus on the market. The team should not have the chance to ask the client, “Are you there?”.