In a previous blog post we talked about some of the problems we’ve encountered using the Agile software development process – especially when working with agencies on fixed budgets and deadlines.
We talked a little bit about an approach we’ve been using successfully in these situations over the last few months. As previously mentioned, this approach takes elements from both the Agile and V-Model software development processes to make projects run as smoothly as possible for both sides.
I thought it might be good to elaborate a little on this and explain how we’ve made this work on some recent projects.
Firstly, as with any project, we make sure we spend the time required up front to nail down the requirements; we liaise with the various stakeholders to make sure we fully understand what the client needs and what their expectations are from the completed project.
Based on the requirements captured in the above phase we can then work with the client on the various documents required for the project. This will generally consist of a technical design document, wireframes, specifications document, architecture diagrams, non-functional requirements, and UAT scripts. These documents will be used extensively during the build phase of the project. We like to call them “artefacts”, and they are strictly versioned and controlled to avoid confusion over which version is in scope.
The UAT scripts are particularly important as these are used to capture all the requirements of the project. The size of the project determines the number of UAT scripts, but it’s not uncommon to have hundreds of UAT scripts detailing all the functionality of the project.
These scripts can then be used to measure progress during the project and, importantly, will be used to measure completion at the end, checking against each requirement and recording the results.
During the project, the UAT scripts will be run at regular intervals so that all stakeholders understand the common state of the project and what’s outstanding. We keep a close eye on the history of the results; having regular test passes means we can quickly spot any test-regression.
Behind the scenes we’re free to pick and choose the Agile elements that make the most sense for the project without being dogmatic about it; we can use “sprints” and “user stories” as we’re accustomed to doing, but the client doesn’t need to be involved in this process; the client can focus on status reports and UAT-script results to understand how we are getting along.
The key here is flexibility. When the project warrants, it or the client demands it, we can offer the full Agile approach. For smaller projects, with fixed costings and deadlines, we can offer the client an approach that they’re more comfortable with – and, importantly, where they are able to easily measure our progress.
Over time we’ll document more of our processes, in the hope it helps others and drives an appreciation that a great creative idea can’t be implemented in digital without some equally good engineering.