A few years ago, before completely applying this whole Agile thing, I worked in the development of a web application that should manage the client’s worksheets through a series of steps, a wizard that would lead users through the phase they were in.
We made a full analysis, we collected all the client needs, and from there we compiled a list of features to be implemented. All very normal. Correct, coherent features that solved specific problems. With a thick requirements document and their respective designs, we started to implement these features, one after another.
Back then, we tried to be a bit Agile (in a way) and every two weeks in pre-production we showed how things were going. It didn’t look half bad. It was easy to use and we even got congratulated by clients on the work they were seeing.
We were happy like that, so we went on until we developed, with no small effort on our part, all the features that were included in the analysis document that had been approved. And we deployed them into production…
And as soon as the administration staff used the application for a few days, they realized they could have done with some changes: include a table in each screen with the original documents, so they wouldn’t lose sight of them; avoid going out to another menu when creating an entity; adding more controls at the end to avoid mistakes when filling them in, etc… Most of them were minor changes that wouldn’t take more than two or three days of development, but we had already exhausted our budget (and more).
Amongst the features we had developed from the beginning, there were some complex ones that allowed complicated changes between projects and that were difficult to develop (and test, in order to be able to check every possible case). I asked about them months later but nobody knew anything about them or which menu they were in. It wasn’t considered important. When they had needed something like that, they had cancelled the process and started a new one.
When we started the project, neither I, nor the client, nor the users had an exact idea of what would work well. We simply couldn’t know for sure. What could have been done to avoid this? Well, we should have deployed the basic features to production as soon as they were ready. That way we would have easily seen all these little changes that would have made the application much more practical and easy to use.
From that moment on, in new projects, when users see the need for changes like these, they ask me about the possibility of including them. They have no problem giving up other features for which they no longer remembered the reason for including in the initial contract or that no longer made much sense.
The feature list is drafted from the beginning in the Product Backlog. The client is aware of this estimation and simply says: “Take out feature 18, which would take 8 days’ work, and change it for these other two features which would take 6 days. We save those two days in case we need some other change.”
That is another Agile principle:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
In general, it is advantageous for clients because they get a product that works and is not broken until a new contract for corrective maintenance is drafted (which would involve paying extra money). But it is also an advantage for us as providers, because we offer a project that is a good reference, in which we are aware of and can account for every hour we spend, and we avoid delivering a product that depletes our budget but still lacks important features.
You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).
Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.
