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.

What is Agile Business Analysis?

Agile Business Analysis is an evolutionary and collaborative process where analysts, developers, customers and end users work together to understand the business domain, to identify what is needed, to prioritize the functionality and to deliver products of the right quality and value to the business. The Agile Business Analyst is a full member of the cross-functional team, working alongside business and development skills to evolve the right products.

You may be wondering, as a business analyst, if that means that the developers will talk directly to the users. Well, yes it does. The business analyst must not become another “hand-off” or block to the information flow. Does that mean that your job has disappeared? Certainly not! Some early Agile approaches laid much emphasis on the developers in the team becoming “generalising specialists”, who could fathom everything from the business strategic level to the bits and bytes of machine language. Development teams in these approaches had access to a business representative, a “Product Owner”, who proposed, refined and prioritised the requirements, but also needed a broad spectrum of knowledge and authority from project-level budgetary control to in-depth end-user knowledge. These approaches were absolutely correct in one thing – that several small teams work better than one large one, organised as a production-line with multiple hand-offs between the roles. However, a misconception of early approaches was to confuse roles with people. Although it can be shown that it is better to have fewer people involved with a product, to reduce the number of hand offs (business – analyst, analyst – designer, designer – developer, developer – tester and so on) the skills of each of these roles are still needed. Time has shown that missing out the business analysis skills is costly. The business representative may be able to look at the “As Is” and “To Be” situations from their own perspective, but often lacks the modelling skills to look at the “big picture”. The Agile Business Analyst can use soft systems approaches (Checkland 1999, 2006) to appreciate different world views, identifying what processes and activities ought to be present to meet corporate vision and what monitoring and control activities are needed to meet strategic objectives and continually improve processes. The power of value chain analysis (Porter) and value nets can also be useful to recognise viable solutions and to enable effective prioritisation. The Agile Business Analyst will also become a negotiator and facilitator within the Agile team, but these are by no means their only contributions.

The early Agile approaches were fine for projects where small teams were making straight-forward small changes. For the larger scale projects with corporate impact, we need a more robust and well defined, but still Agile, approach, and good business analysis skills are essential. DSDM Atern is the only Agile approach to fully recognise and define the role of the Agile Business Analyst (www.dsdm.org).

How will my job be different, as an Agile Business Analyst?

A primary goal of the Agile Business Analyst is to identify and understand what the customer needs and make this visible to the rest of the team and, where appropriate, to a wider group of stakeholders.

Agile Business Analysts use rich communication techniques to work closely and collaborate with developers, testers and end users. Some examples of such techniques are: storyboards, rich pictures, context diagrams, face-to-face discussion and facilitated workshops. The business analyst’s traditional modelling skills are essential here, but care should also be taken to view the models as a communication medium and, where possible, use models which view the world from the user perspective (user stories, use cases).

Agile Business Analysts work iteratively and incrementally. It is seldom neither necessary nor effective to deliver business change as a single large implementation. Agile work is broken down into small, achievable “chunks” of functionality, each of which can be handled by a small, multi-skilled team. The Agile Business Analyst is, more than ever, the Guardian of the Requirements and remains involved in the project throughout, and beyond implementation to benefits realisation.

The Agile BA also needs all of the skills of a traditional Business Analyst. They must be able to:

• Understand how a business strategy is developed;
• be able to use strategic analysis techniques;
• understand how to work within a project lifecycle;
• use modelling and other techniques to investigate an organization’s business systems;
• apply a qualitative and quantitative approach to improving business systems; Perform stakeholder analysis and management;
• formulate a Business Case, with costs, benefits, impacts and risks and options;
• ensure that requirements are clearly defined, congruent with the business objectives, feasible and not conflict with other requirements;
• perform benefits realisation assessments once changes have been implemented.

What are the Agile Business Analysis Outputs?

The artefacts produced by an Agile Business Analyst are, in fact, pretty much the same as those produced by a traditional business analyst, but the ways in which they are created are different and the full detail evolves throughout the lifecycle. The Functional Requirements Specification still exists! However, it arrives in overview at first, at high-level from Feasibility, possibly including a visible prototype to illustrate the vision of the business for the eventual outcome; then more detail results from Foundations, in the form of a high-level, prioritised requirements list. Further detail emerges in “chapters” throughout the project on a timebox-by-timebox basis, as the detailed chunks of functionality are further explored and engineered. Because of the proximity of the detailed specification to the actual building of the functionality, and because of the close working relationship of the development team, less written documentation is actually required. However, Agile with DSDM Atern is not a documentation free zone! The ISO 9001 quality adage of, “Say what you are going to do, do it, test that you have done it” holds true and the DSDM Atern method is used in many organisations where rigour of CMMI is mandated. And this can be achieved whilst retaining the benefits of Agility.

Conclusion

Business Analysis is a skill set and a role which has become much in demand in the realm of software development and software service provision. Agile projects certainly require an evolution in the way business analysts works. Some Agilists argue that the BA role disappears in favour of developers who are generalizing specialists. However, the DSDM Atern Agile approach sees the role and skills of the BA as being more important than ever. Agile Business Analysis is collaborative, iterative, and incremental, involving developers, users and other stakeholders to embrace change and produce the right product at the right time, with the right value.

Bibliography

Boehm B – Software Engineering Economics -1981 Prentice Hall

Boehm B, Turner – R F Balancing Agility and Discipline – Addison Wesley Pearson Education 2004

Checkland P – Systems Thinking Systems Practice – John Wiley and Sons 1999

Checkland P, Poulter J – Learning For Action – John Wiley and Sons 2006

DSDM Atern Handbook V2.0 – The DSDM Consortium 2008

www.dsdm.org – DSDM Atern – The Full Method 2009

Porter M E – Competitive Advantage – Sustaining and Creating Competitive Performance – The Free Press Simon & Schuster Inc. 1998