Download

Page 1 of 3

IT's all about being Agile?

You're working as a Business Analyst in a traditional project environment, specifying the requirements for IT Developers to build. Suddenly everyone around you is talking about Agile. The managers say they need it; developers say they are doing it, but what exactly is it, and how will it affect you in your job?

What is Agile Business Analysis, and how is the life of the Agile Business Analyst likely to be different from the traditional business analyst?

How is an Agile project different?

Typically, traditional projects are a serial production line of work, a waterfall lifecycle. The Project Manager and Project Sponsor set out the terms of reference for the project. The project initiation documentation is completed, perhaps with your business analysis skills used to develop a business case. The project is approved by senior management and you set off to do your requirements elicitation, analysis and validation and to produce the expected Functional Requirements Specification: a weighty, detailed tome. You struggle to get that signed off by the customer and then it's probably off to another project, with only occasional cries for help dragging you back to the first one.

The profile of your work on an Agile project will be very different. Agile projects have several things in common:

• They are incremental, building functionality in small, deliverable chunks and delivering to the customer in frequent diminutive increments, perhaps as often as every few weeks or even days. These deliveries have the benefit of releasing early benefit to the business, which pleases the management. They are also a measure that the project is doing the right thing, which comes much earlier than in traditional, serial projects. However, they are a challenge to you unless you have at least a high-level idea of how the deliverables fit together.
• They are iterative, starting with a high level view of what is required and deliberately leaving the investigation of the fine detail until just before the functionality associated with it is built. This is challenging too. You definitely need a firm foundation at the outset - a high level model of the functions and major data groups, major stakeholders and the like. On the bright side, you always knew that half of the huge Requirements Specification would probably change before the project arrived at implementation - so there's a saving of all that wasted work.
• They embrace change, knowing that world around them will change as the project progresses. Agile projects accommodate this by allowing essential change to requirements, even late in the project, perhaps in exchange for less important functionality. Well, we always had those arguments about the need for late changes; a frozen requirements specification only ever delivered a product which no-one really wanted.
• They are collaborative, bringing together multiple, small, mixed teams with the right skills to produce the products of the project, in increments. These teams include users and customers, developers, architects - whatever skills are needed. This seems useful too. It was always difficult to speak to the right business people. Perhaps if they are officially members of the team, their time will be properly resourced.

If we use a best-practice Agile approach such as DSDM Atern, their time will be properly resourced, because business roles and responsibilities are fully defined. DSDM Atern projects are also business-focused, having business representation throughout and a clear business case from the outset. They are based on firm principles, including their commitment to delivering on time and on budget, every time, by timeboxing the work and prioritising what is done using the MOSCOW rules. They also focus on delivering the right quality which includes both functional and non-functional requirements, with acceptance criteria and testing built in throughout the project.