The Power of the Agile Business Analyst

30 surprising ways a business analyst can add value to your Agile development team

Jamie Lynn Cooke

• Publisher: IT Governance Ltd
• Year: 2013
• eBook ISBN: 9781849285063
• Topic: Business
• Subtopic: Project Management
• Index: Business

The Power of the Agile Business Analyst: 30 surprising ways a business analyst can add value to your Agile development team challenges whether Agile projects are truly positioned to deliver the highest-value business solutions without offering business users the equivalent level of support, validation, and collaboration that is provided for the Agile development team. To address this challenge, The Power of the Agile Business Analyst proposes including an Agile business analyst on the development team to provide business users with the support they need, as well as a valuable resource to assist the Agile developers in their analysis, design, testing, and implementation work throughout the project.

CHAPTER 1: WHAT IS AGILE?¹

‘Agile’ is a collective term for methodologies (and practices) that have emerged over the past two decades to increase the relevance, quality, flexibility, and business value of software solutions. These adaptive management approaches are specifically intended to address the problems that have historically plagued software development and service delivery activities in the IT industry, including budget overruns, missed deadlines, low-quality outputs, and dissatisfied users.

Although there is a broad range of Agile methodologies in the IT industry – from software development and project delivery approaches to strategies for software maintenance – all Agile methodologies share the same basic objectives:

• To replace upfront planning with incremental planning that adapts to the most current information available (‘Apply, Inspect, Adapt’).
• To minimize the impact of changing requirements by providing a low overhead structure to accommodate variations to the originally identified requirements throughout the project.
• To build in quality upfront and then relentlessly confirm the integrity of the solution throughout the process.
• To address technical risks as early in the process as possible to reduce the potential for cost and time blowouts as the project progresses.
• To entrust and empower staff to continuously deliver high business-value outputs.
• To provide frequent and continuous business value to the organizationby focusing staff on regularly delivering the highest-priority features in the solution as fully functional, fully tested, production-ready capabilities.
• To encourage ongoing communication between the business areas and project team members to increase the relevance, usability, quality, and acceptance of delivered solutions.

Agile methodologies are common-sense approaches for applying the finite resources of an organization to continuously deliver low risk, high business-value software solutions

The last two bullet points in this list cannot be emphasized enough. Where traditional waterfall software development projects focus on using extensive upfront documentation to detail user requirements before development work can even begin, Agile approaches rely on shared communication between the development team and the business users throughout the project, with the business users' highest priority requested featuresregularly presented to them asfully functional software to confirm whether or not the delivered solution meets their requirements.

Some of the most common Agile methodologies (also referred to as ‘Agile Methods’) include:

• iterative strategies for managing software development projects, such as Scrum, Dynamic Systems Development Method (DSDM), Feature-Driven Development (FDD^TM), the Agile Unified Process (AUP), and Lean Development
• strategies for optimizing software development work, such as eXtreme Programming (XP^TM) and the Rational Unified Process (RUP)
• strategies for managing software maintenance and support activities, such as Kanban.

These Agile methodologies have been (and continue to be) successfully used by thousands of organizations worldwide², most notably in the United States and Europe. Some of the more prominent organizations using Agile methodologies include Nokia Siemens Networks³, Yahoo!⁴, Google⁵, Microsoft^®6, BT⁷, Bankwest⁸, SunCorp⁹, and Wells Fargo¹⁰.

1 For those who follow this author’s writing, some of the introductory material from Everything You Want to Know about Agile: How to get Agile results in a less-than-Agile organization, Jamie Lynn Cooke, IT Governance Publishing (2012) has been adapted for use in this book, serving the same purpose as in the original.

2 As evidenced by the number of signatories to the Agile Manifesto (Agilemanifesto.org) as at June 2013.

3 NokiaSiemens and Agile Development, Haapio P, JAOO (2008): http://jaoo.dk/file?path=/jaoo-aarhus-2008/slides//PetriHaapio_CanAGLobalCompany.pdf.

4 Lessons from a Yahoo Scrum Rollout, Mackie K (2008): http://campustechnology.com/articles/2008/02/lessons-from-a-yahoo-scrum-rollout.aspx.

5 Scaling Scrum & Distributed Teams – Scrum Tuning: Lessons Learned at Google, Sutherland J (2006): youtube.com/watch?v=WUQfuhdOZ8s.

6 Microsoft Lauds Scrum Method for Software Projects, Taft D K (2005): eweek.com/c/a/IT-Management/Microsoft-Lauds-Scrum-Method-for-Software-Projects/.

7 Agile Coaching in British Telecom, Meadows L and Hanly S (2006): Agilejournal.com/articles/columns/column-articles/144-Agile-coaching-in-british-telecom.

8 Bankwest goes Agile: project time slashed, Braue D (2010): zdnet.com/bankwest-goes-Agile-project-time-slashed-1339306091/.

9 Suncorp goes Agile for 19k desktop integration project (2008): itnews.com.au/News/130927,suncorp-goes-Agile-for-19k-desktop-integration-project.aspx.

10 Is Agile Development Only for Nerds?, Matta E (2008): http://radiowalker.wordpress.com/2008/10/07/is-Agile-development-only-for-nerds/.

CHAPTER 2: THE POWER AND THE PERILS OF AGILE

The ability for Agile approaches to deliver real results is both its greatest strength and its greatest exposure. Organizations often get so excited about the effectiveness of Agile approaches that they become complacent to its perils.

For organizations that have been burned by historical failures in their IT projects, the ability to receive working software on a regular basis can be refreshing, almost enchanting. Management and staff tend to see Agile as the 'cure-all' for what has historically plagued the software industry. They are often so excited by the tangible outputs of their Agile software projects that they do not stop to consider where these approaches may be lacking.

The lopsided process diagram

The following diagram shows the process used in a common Agile method (Scrum) to transition the high-level requirements identified by the business users (referred to as Product Owners) into prioritized functions that are implemented by the Agile development team:

The focus of this diagram is on the activities undertaken to translate the high-level business requirements identified by the business users into actionable functions that the development team can work on in the upcoming iteration. In particular, the diagram shows the importance of using a prioritized list of requested features (the Product Backlog) as the basis for interactive discussion and clarification with the Agile team. The Agile team then uses the requirements information (and any supporting materials) provided by the business users to estimate the amount of effort required to deliver each requested feature. The objective is to produce an agreed list of system capabilities that the Agile development team believes can be achieved in the upcoming iteration (the Sprint Backlog).

Figure 1: The lopsided process diagram

The irony is that this one diagram equally shows some of the greatest strengths and the greatest weaknesses in Agile methods.

The right-hand side of this diagram depicts the ScrumMaster, Scrum Team Members and Product Owner's use of interactive discussion, supporting materials, and estimation to establish a shared understanding of what the business users require and what the Agile team can reasonably achieve. These tasks are well understood in the Agile community, including numerous resources, tools, and techniques (e.g. Planning Poker¹) that are available to support these activities.

The left-hand side of this diagram, however, depicts one of the greatest weaknesses in Agile methods: the undefined and unstructured way in which the Product Owner (i.e. the business users) translate their high-level requirements into user stories and how they then assign priorities to these stories.

In many Agile projects, business users are left on their own to make these decisions. Th...

Table of contents

• Cover
• Title
• Copyright
• Contents
• Introduction
• Chapter 1: What is Agile?
• Chapter 2: The Power and the Perils of Agile
• Chapter 3: Why Your Team Needs an Agile Business Analyst
• Chapter 4: What are the Risks of Not Having an Agile Business Analyst?
• Chapter 5: 30 Ways for the Agile Business Analyst to Add Value to Your Project
• Chapter 6: Getting the Right Agile Business Analyst for Your Team
• Chapter 7: Moving Your Agile Team Forward
• Chapter 8: More Information on Agile
• Author's Note on Agile Business Analysis Resources
• ITG Resources