Three Baby-Steps toward Agile Requirements Management
Three Baby-Steps toward Agile Requirements Management Kurt Solarte, Managing Consultant If you are beginning to consider a move to more agile methods, you may be looking for a set of‘best practices’ for agile requirements elicitation and agile requirements management. What you willlikely find is many prescriptive and detailed ‘best practices’ which I personally have found to besituational at best, and often just too much to consume for an organisation new to the concepts. What Ipropose to offer in this post is a few ‘baby steps’ that can help an organisation move toward an agileenvironment and prepare for some of the more prescriptive methods like SCRUM or eXtremeprogramming (XP). When making a move toward agile methods, there are three main recommendations that Ibelieve should be considered to prepare for a more agile requirements practice, and a team as a whole. 1. Collaboration ─ While this is obviously a good idea in all methods of requirements management and all stages of a project lifecycle, it is an essential element to agile methods and agile requirements management. 2. Embrace Change ─ this is almost a counter intuitive step for many business analysts. To be agile in requirements management, we must acknowledge change happens, embrace it, and make it part of our process. 3. Support of upper management ─ Becoming agile is an organisational change as much as a development practice, and without clear support from upper management this change will be difficult; if not impossible. Recommending good collaboration is a bit like recommending good work ethic; it seems as if itshould go without saying. However, for organisations used to a very siloed waterfall method, realcollaboration as a standard operating procedure may have fallen by the wayside. It can become easy in awaterfall method to simply over-document deliverables and blindly send them to the next team. In anagile method, an organisation will begin to keep ‘living documents’ that constantly change and grow ─this requires true collaboration and teaming. In order to properly include all members of the projectteam and stakeholders, an organisation must not only take on more inclusive methods, but musteducate all associated people on the use of the method, including management and stakeholders. Ifone expects individuals to be involved, the individuals must know how, why, and when they areexpected be involved. Simply said, to create an inclusive method, all individuals associated with theproject must feel and be encouraged to be involved. One simple step many larger organisations havefound useful is the adoption of stakeholders’ terminology. Often in agile methods we get very focusedon the new names, terms, and roles ─ all at the detriment to collaboration. Many stakeholders will feelmore comfortable with requirements, time periods, and project roles being expressed in their ownterminology. This should be seen by the project team as a minor secession for the sake of greatercollaboration.
Embrace Change. To many Business Analysts and Project Managers, this will seem counter-intuitive. As professional BAs and PMs we have been taught to identify all requirements and lock downthe scope. However, we all know change does happen, and what often defines the success of a projectis how we deal with that change. While traditionally an organisation would manage this change withsome sort of project or scope change management process; which gives a structure to alteringrequirements which are typically fully elicited. In agile methods, organisations acknowledge that changeis constant in technology projects, and move to embrace that change. To make steps toward agility, anorganisation may need to change their requirements elicitation methods. The elicitation can begin withvery broad requirements that outline a general scope, do some high level requirements modelling,prioritise what has been captured, and prepare the team to change as needed. Once the broadrequirements are documented and ranked, the team can then begin to add further detail torequirements in an ordered fashion. This means the stakeholders will give detail as it is needed, and theteam will change documentation as details emerge. The stakeholders know their priorities andrequirements will change, and the project team knows the project documentation is ‘alive’ and changingas the project moves on, and as the need for detail requires. While the above detailed steps are important ways to ease into agile, arguably the mostnecessary step is getting upper management support. The management lines for both the project teamsand the stakeholders must understand the use of agile methods is an organisational change, and not justa development method. These management lines must fully comprehend the concepts behindembracing change, increasing collaboration, and the notion of practicing constant requirementsprioritisation. As with many successful organisational changes, the use of ‘on the ground’ champions ofthe new process are important, but a clear message of support by company leadership is imperative. Aproject kick-off that includes an executive saying a few words of support for the new methods andmentioning that management is watching for this to be a successful implementation, will go a long wayto drowning out the voices of the detractors. As an organisation strives to become agile, it is important to remember to be agile in theimplementation of agile. Meaning, only take on as much agile process and change as your organisationcan handle in each ‘sprint’, or short change window; and only keep the agile processes needed toimprove implementation of technology projects. Organisations can often lose focus of their underlyingpurpose for adopting agile methods, and begin to focus on ‘becoming agile’. There is not a prize orreward that comes with completely adopting any particular agile method, so look to embrace the partsof agile methods you need to find your success, and question anything else ─ because that is trulybecoming agile.