One of the biggest challenges for me when developing requirements specifications, is that requirements can and do change and I’ve often struggled with the prescriptive “waterfall life-cycle” approach to software development. This sequential process does not guarantee success of the project nor does it decrease risk, in fact it is often the opposite as this process does not support change or vital feedback from users and the business.
I wrote about the BA life-cycle awhile back when I embarked on a project that was stalled and despite extensive analysis, the project had not yet begun development and we could not get sign-off or agreement on the requirements for this complex system. We had hundreds of Use Cases, lots of Architecture design documents, User scenarios and volumes of analysis and feedback gained over two years of review of the problem to be addressed, in short, the bureaucrats had taken over and we were in analysis paralysis.It was “groundhog day” as neither the business nor the development team had a clear idea of how to move forward. To jump start the process we adopted an agile approach.
The Agile Alliance Manifesto defines four values of encouraging better ways to develop software:
- Individuals and interactions over processes and tools - the most important factors to consider are people and how they work together. User and Stakeholder engagement is vital
- Working software over comprehensive development - we are there to create a system, not documents (although it is noted that documentation is important for our understanding of the system and some documentation is required to understand how and why a system was built). As Jonathan recently asked in his blog does paperwork really add any value?
- Customer collaboration over contract negotiation - customers are unlikely to be able to fully specify the system they want, they will not get it right at first and they are likely to change their minds, therefore communication and collaboration is vital.
- Respond to change over following a plan - I know all the project managers who cling to their Gannt charts will cringe at this but change is a reality and the software development process must reflect this. You need a project plan approach that is flexible
The key trigger to our move to agile was that the Change Manager took over responsibility for Project Lead. Myself and my colleague Matt in the design and analysis team, were charged with the task to think differently, be innovative and just make it happen. Given the User Centred Design focus of me and Matt and our colleagues, its not surprising that we focused on the people orientated issues, the Users understanding of the business processes and followed analysis techniques that readily supported change and flexibility. We used storyboards, iterative prototyping and business process mapping notation (BPMN) to convey and confirm the requirements and before long we had a working prototype that the business had approved and sign-offed.
We have embarked on three new projects since this original foray into agile, and are refining our documents and processes. It’s quite exciting as many of the developers and business teams we are working in, were at first a little nervous about the “agile” approach as they are traditionally quite risk adverse, however they are now seeing real benefits. Matt recently blogged about the tools we are using to specifiy design and requirements. These tools and techniques are easy for the business to understand, flexible enough to meet their changing needs and allowing greater collaboration. To the bottom line - this is saving them time, they understand what they are signing off on and its also giving them a more useable end product.
Recent Comments