To paraphrase a Zoolander quote, Agile is “so hot right now”. When you ask business areas and IT managers what they are interested in, they respond that they want to be more agile in order to adapt in a changing environment. What is it that everyone wants to be agile? Agile is not new, but it has had a resurgence of late and this is probably due to the fact that in a fast paced world where change is a constant, the word agile seems reassuring and positive, but are we all talking about the same thing?
I asked a BA user group meeting recently what they thought agile meant and they proposed it was about “flexibility”, “adaptability”, “iterations”, “prototyping”,”light weight documentation”, “adapting to change” and “saving time and money”.
XP has its basis from the engineering discipline and focuses on the critical activities required to build the software and requires with developers to be directly involved with project stakeholders who need to actively participate in the process. Scrum tends to come from more a project management focus and it was originally intended for management of software development projects but is now used as a way to run software teams and break the development into sprint cycles to development increments of the software. FDD sits some where between the two and includes explicit modelling activities that is driven from a client valued functionality (feature) perspective. The common themes and threads across all three seem to be user orientation, need for user involvement and the need to resolve uncertainty regarding requirements.
What these AMs have in common is that these agile methods can help streamline your modelling and documentation efforts as they are an enabling technique for evolutionary development. There is a danger that some may use “agile” as an excuse to having no requirements or no documentation and to just go ahead an build whatever they want without thought to the user or system purpose. This is not in the true spirit of agile.
Agile has become more a philosophy rather than a methodology in the strict sense of the word and that may explain why agile means different things to different people. So whilst it is not easy to tell what agile is, agile is now what we all should subscribe to be.
I have been doing agile software development projects for awhile now, so i asked a business analysis colleague, Mark Foley to come and talk to the User group meeting I organize bimonthly for the ABAA in Canberra.
The role of the BA in an agile environment is a hot topic at the moment so we had over 30 Business Analyst attend the User Group Meeting on the 23rd of October. Mark Foley is a principal consultant from Borland, and he shared his insights into the emergence of agile as a methodology over the last ten years from the Chrysler motor car 3Cs beginnings of XP to today’s scrum sprints. Mark’s presentation is below as he kindly has allowed me to put it up on the ABAA site and slideshare.
Everyone it seems wants to be agile but it is not a magic formula and not suited to all projects.
We discussed the key elements of agile and how this can help our projects be more flexible, adaptive as through sprints we can develop and evolve the requirements with the business and users. Mark discussed that agile can be used across large geographically dispersed teams and in the government setting, agile is still relevant as documentation of the sprints as used in scrum, can help stakeholder understand the system and be more involved as the customer representative.
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