. . . so they're not out of scope, but are they actually requirements?
A colleague forwarded the following link on to me yesterday which although brief, is a good reminder that the customer will always ask for more than they may really need, and that we may equally be inclined to want to build something beyond their basic requirements.
The author of this post cites a well known statistic about the extent of developed features in applications that are never or rarely used, which can be as high as 65%. If this statistic is not well known to you, then it surely should be, for it is the result of wasted expenditure on unnecessary development effort and misdirected requirements gathering.
This is not to say that it is the fault of any one in particular that non-essential features get developed into the system or application, rather, as can be seen from the diagram in the above link, there are many forces acting on the team which result in these features making their way in. It takes a dedicated effort to thoroughly follow up on every requirement put forward, and a disciplined stance to push back on any unnecessary development, either requested by the business or in the form of gold-plating developers. Under pressure to deliver and meet targets and deadlines however, this often is very hard to achieve. The question then, is what can we do to reduce this statistic, or better yet, not fall victim to it at all?
A method of short development cycles that allows functionality to be delivered quickly to the user, allows the user to start gaining benefit from the functionality, and allows them the ability to feed back on potential and essential improvements to the functionality is one approach. Another is the ability to build functionality on top of functionality in iterations via this process of short development cycles, so that the user can more readily identify when their requirements have been met. Any further development beyond that point will likely not deliver significant business benefit. Another aspect of short development cycles is the ability to continuously evaluate progress and reprioritise requirements, de-scope, re-scope, change-scope, etc, so that the system or app is developed flexibly, and constantly in tune with the business' changing needs.
This method of development is not new, and it is one which Conchango favours for the advantages described above. In fact on our website you can find a more detailed argument of the factors I've been describing in the article The Agile revolution. At the risk of playing Devil's Advocate however, I would like to offer a cautionary note, so as to not allow the pursuit of Agile to become the cause of the very problem it seeks to overcome.
In Agile development, the pressure to be seen to be delivering every month can be very strong, such that there is the potential to take on whatever comes your way first in order to be doing something. Furthermore, prioritising of requirements in some organisations can be accompanied by a degree of internal politics and there is the risk that those that shout loudest or have the most weight will get their features to the top of the list, regardless of their relative worth to the organisation as a whole.
Purists would tell you that this simply does not happen with Agile, but Agile, just like any other theory can differ wildly in practical application. It is our job therefore to ensure as much as possible that this does not happen, in order to maintain the integrity of the requirements gathered and the functionality delivered off the back of these. Agile projects however are tricky beasts and I would welcome any comments about anyone's experiences or advice in this area. For my part, if I think of anything, I promise I'll let you know.
James