The Power of the Agile Business Analyst E-Book

IT Governance Publishing

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 223

Veröffentlichungsjahr: 2025

Beschreibung

Agile frameworks have revolutionized the way business analysis is integrated into projects, but the role of the Agile business analyst is still evolving. This book explores how business analysts can thrive within Agile teams, offering insights into both the challenges and opportunities they face. By understanding the power and limitations of Agile, the reader will gain practical tools to not only survive but thrive in an Agile environment. The text outlines why having a dedicated Agile business analyst is crucial and provides actionable advice on how to build the right team and minimize risks. The author goes beyond theory to offer concrete steps that help business analysts add value to Agile projects. The reader will walk away with a deep understanding of the evolving Agile landscape, including the critical role of business analysis and practical tips for improving team dynamics, managing risks, and maximizing value. This book is perfect for professionals looking to integrate Agile business analysis into their teams and projects to achieve better outcomes and continuous improvement.

Leseprobe

The Power of the Agile Business Analyst

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

Second edition

The Power of the Agile Business Analyst

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

Second edition

JAMIE LYNN COOKE

Every possible effort has been made to ensure that the information contained in this book is accurate at the time of going to press, and the publisher and the author cannot accept responsibility for any errors or omissions, however caused. Any opinions expressed in this book are those of the author, not the publisher. Websites identified are for reference only, not endorsement, and any website visits are at the reader’s own risk. No responsibility for loss or damage occasioned to any person acting, or refraining from action, as a result of the material in this publication can be accepted by the publisher or the author.

Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored, or transmitted, in any form, or by any means, with the prior permission in writing of the publisher or, in the case of reprographic reproduction, in accordance with the terms of licenses issued by the Copyright Licensing Agency. Enquiries concerning reproduction outside those terms should be sent to the publisher at the following address:

IT Governance Publishing

Unit 3, Clive Court

Bartholomew’s Walk

Cambridgeshire Business Park

Ely, Cambridgeshire

CB7 4EA

United Kingdom

www.itgovernancepublishing.co.uk

© Jamie Lynn Cooke 2013, 2018

The author has asserted the rights of the author under the Copyright, Designs and Patents Act, 1988, to be identified as the author of this work.

First published in the United Kingdom in 2013 by IT Governance Publishing.

ISBN: 978-1-84928-505-6

Second edition published in the United Kingdom in 2018 by IT Governance Publishing.

ISBN: 978-1-84928-996-2

DEDICATION

To my mother, Sheila, for her unconditional love and her relentless pursuit of seven-letter Scrabble words.

FOREWORD

Agile has been misquoted, misused, and downright abused by commercial interests. And now we hear that Agile has negated the need for documentation, speeds up development by months or even years, and, if only we all used it, would allow world peace to reign.

The challenge (or one of the major challenges) of Agile is to make sure that it is properly understood, that wild claims about ‘no more documentation’ or ‘development cycles reduced to days rather than months’ – or any of the myriad countless and baseless claims made about Agile being some form of magic – are countered by practical, achievable approaches before expectations get out of control. This book does all of that and more. Not only is it one of the best books about Agile that I have read, it is one of the best books about ANY good practices that I have read.

It is more than refreshing to find an author who knows the subject inside out, provides direct, clear guidance, and, probably most importantly, reinforces the fact that good practices still require intelligent and pragmatic application.

If there is any justice, Agile will not be burdened with unfeasible expectations, and books such as this one will reinforce the excellence of its concepts and their practical application, and hopefully establish Jamie Lynn Cooke as a genuine authority in the domain.

I look forward to the next book!

Brian Johnson, CA.

PREFACE

Agile approaches empower development teams to deliver the greatest business-value software solutions that can be achieved within the time, resourcing, and budgeting constraints of each project. These approaches focus the Agile team members on building the highest-priority features, on replacing reams of documentation with face-to-face communication, on identifying (and addressing) risks as early as possible in the project timeline, and on continually reviewing and adapting the developed solution to meet the ongoing needs of the business.

One of the core strategies to achieve these objectives is encouraging the Agile development team to work as closely as possible with business users throughout the project timeline. This ongoing interaction enables the Agile developers to better understand the business users’ requirements and priorities, reduces their mutual dependence on written specifications, focuses the development team on continually delivering the highest-priority capabilities in the software, and confirms the delivered solution genuinely meets the needs of the business.

Although Agile methods, such as Scrum, XP®, Lean, and DSDM, differ in their approaches to delivering high business-value solutions, each equips the Agile developers with practices and tools that are designed to increase the quality, relevance, and extensibility of the software that the team delivers. The Agile community, as a whole, also provides developers with countless supporting resources, including books, websites, forums, and conferences where Agile development issues can be raised, discussed, and jointly addressed by the group.

The interesting thing is that, where Agile approaches go to great lengths to provide the developers with the foundation they need to deliver high-value software solutions, there is relatively little equivalent support provided for the business users. In most Agile methods, the business user is solely responsible for the identification, requirements gathering, clarification, and assignment of priorities for the requested system capabilities. These methods generally work from the assumption that the business users have separately collaborated with all the relevant stakeholders before each joint planning session, and that their collective input is accurately represented. Agile methods also assume the business users have sufficient knowledge, vision, and objectivity to ensure the capabilities they are requesting represent the best possible solution for the organization. Likewise, Agile methods anticipate that the business users will be available throughout the project to provide the Agile developers with accurate and timely ongoing feedback. Although the intention of having Agile development teams working directly with business areas throughout the project is a noble one, without a reasonable level of support for the business users, the execution can fall short.

One of the biggest challenges for Agile projects is when business users have limited (or no) availability to spend significant time working with the Agile development team, due to the commitments of their primary roles. Although these business users may be available at the very beginning of an iteration (for initial requirements discussions and planning) and at the very end of an iteration (for system walkthroughs and retrospectives), what happens when the Agile team needs business input at other points in the development process?

Another less apparent, but equally significant challenge, is when the requested capabilities and priorities provided by the business users are based too heavily on their current work, without having objectively considered the potential efficiencies a new solution (and corresponding business process improvements) could provide.

Similar questions can arise about the value of the business users’ requested capabilities in an Agile solution when they have not consulted with the full range of stakeholders who will be impacted by the solution, or when they have insufficient background information on the policy, regulatory, or technical constraints of the solution to truly understand the overhead costs of implementing these capabilities.

All of these situations can significantly compromise the collaboration between the business users and the Agile development team. This not only has implications for the business value of the delivered solution (and the perception of the Agile team) but also impacts ongoing project funding and, potentially, jeopardizes future support for Agile approaches in the organization altogether. No matter how effective Agile approaches are in delivering production-ready software, the real measures of success are the quality, relevance, and business value of the implemented solution.

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. If Agile projects are designed to deliver the greatest business-value software solution that can be achieved, why would the business users not get an equivalent level of support for their work?

To address this challenge, The Power of the Agile Business Analyst strongly encourages the inclusion of an Agile business analyst on every Agile development team to provide business users with the support they need, as well as a valuable resource to assist Agile developers in their analysis, design, testing, and implementation work throughout the project.

Most importantly, The Power of the Agile Business Analyst details 30 core activities the Agile business analyst can undertake to ensure the business users and Agile developers deliver the highest business-value solution for the organization, and guides you in identifying the most critical subset of Agile business analyst activities for the specific needs of your project.

ABOUT THE AUTHOR

Jamie Lynn Cooke has 27 years of experience as a senior business analyst and solutions consultant, working with more than 130 public and private sector organizations throughout Australia, Canada, and the US.

Her background includes business case development; strategic and operational reviews; business process modeling, mapping, and optimization; product and project management on small to multimillion-dollar initiatives; quality management; risk analysis and mitigation; developing/conducting training courses; workshop delivery; and refining e-business strategies.

She is the author of Agile Productivity Unleashed, a book written specifically to explain Agile in non-technical business terms to managers and executives outside the IT industry; Agile: An Executive Guide: Real results from IT budgets, which gives IT executives the tools and strategies needed for bottom-line business decisions on using Agile methodologies; Everything you want to know about Agile: How to get Agile results in a less-than-Agile organization, which gives readers strategies for aligning Agile work within the reporting, budgeting, staffing, and governance constraints of their organization; and PRINCE2 Agile™ An Implementation Pocket Guide: Step-by-step advice for every project type, a hands-on guide for successfully delivering projects within the PRINCE2 Agile™ framework.

She is a well-regarded speaker on both business and technology topics, most recently presenting topics such as From Unclear and Unrealistic Requirements to Achievable User Stories, Getting Management and Business User Support for Using Agile, and When is Agile Not the Answer? at the Agile Development West conference, the Business Process Modelling world conference, and at AgileCanberra professional forums.

Jamie has been working hands-on with Agile methodologies since 2003, and has researched hundreds of books and articles on Agile topics. She is a signatory to the Agile Manifesto, has attended numerous Agile seminars, and has worked with prominent consultants to promote Agile methodologies to large organizations.

Jamie has a Bachelor of Science in Engineering Psychology (Human Factors Engineering) from Tufts University in Medford, Massachusetts, and a Graduate Certificate in e-Business/Business Informatics from the University of Canberra in Australia.

ACKNOWLEDGEMENTS

My continued thanks to the pioneers and thought leaders of the Agile world, most notably Kent Beck, Martin Fowler, Alistair Cockburn, Jeff Sutherland, Mike Cohn, Ken Schwaber, and Jim Highsmith, for their passionate work in developing and refining Agile methodologies over the past two decades. Particular thanks go to Artem Marchenko for generously making his tracking tools available for everyone in the Agile community to use.

Thanks also to the small and large organizations worldwide that have shared their Agile experiences, including Yahoo!, Google, Microsoft, and BT.

Special thanks to Neil Salkind of the Salkind Literary Agency and Vicki Utting of IT Governance Publishing for their ongoing support and sage advice. Personal thanks to Brian Johnson for his insightful and supportive preface. Thanks also to Chris Evans, ITSM specialist and ir. H.L. (Maarten) Souw RE, enterprise risk and QA manager, UWV, for their helpful comments during the review process.

Also many thanks to the people who taught me the most about the strategies of the business world over the past 27 years, especially Roland Scornavacca, Tony Robey, and Peter Walsh; to Rowan Bunning for being an unending source of Agile knowledge; and to the writers and teachers who inspired me, particularly Richard Leonard1 for his amazing ability to encourage writers with his humor and enthusiasm.

Finally, my eternal gratitude to my parents, my US family, my Australian family, and my friends, most especially Michele, Susan, Linda, Elissa, and Janice, for continuing to be my sanity check in this world. Most of all, thank you to my husband, David, for 26 years of love and laughter.

1 Richard Leonard’s website: richardleonard.net.

CONTENTS

Introduction

Chapter 1: What is Agile?

Chapter 2: The power and perils of Agile

The lopsided process diagram

The slippery slope

Improving continuous improvement

Chapter 3: Why your team needs an Agile business analyst

Is pairing only for developers?

The disappearance of the traditional business analyst

The emergence of the Agile business analyst

Isn’t the Agile developer also the business analyst?

Individual strengths in multidisciplinary teams

Where does the Agile business analyst belong?

Chapter 4: What are the risks of not having an Agile business analyst?

The limitations of requirements review sessions

Software is only part of the solution

The danger of the unquestioned business user

The tyranny of proximity

What to do when the business user is not available

Opportunities that could be missed

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

Building the ideal Agile business analyst

If you are a traditional business analyst…

The bottom line

Chapter 7: Moving your Agile team forward

Chapter 8: More information on Agile

General information on Agile

Specific Agile methodologies and practices

Industry research on Agile

Selected Agile case studies

Author’s note on Agile business analysis resources

Further Reading

INTRODUCTION

Not all Agile development teams – or all business users – are equal.

In an ideal world, the business users who work with the Agile development team would be intimately familiar with the requirements of every business area impacted by the delivered solution (and the relative priority of each requested capability); they would be objective enough to see the solution beyond their current work practices; and they would fully understand the policy, regulatory, and technical constraints of every feature in the solution. In this perfect scenario, the business users would also be continually available to work with the development team throughout the project timeline to investigate their questions, provide real-time feedback on the system capabilities in progress, resolve any conflicting input from stakeholders (and management), and prepare the intended users – and the organization overall – for upcoming software releases.

Conversely, the Agile development team may find themselves working with business users who have extremely limited availability to work with the team, who have just enough knowledge of the business requirements to be dangerous, or who insist on single-handedly making decisions on behalf of the organization, all of which can significantly reduce the accuracy, relevance, and value of the delivered solution.

For most Agile projects, including yours, the business users who work with the Agile developers fall somewhere in the spectrum between these two extremes (hopefully leaning more toward the ideal model!). There will, however, come a time in every Agile project when even the most well-intentioned business users will be unavailable to give the Agile developers real-time answers to their questions, to provide feedback on the software in progress, or to investigate and resolve the outstanding business issues raised during development. Equally, there will be times when the business users need input from other areas of the organization, but do not have the availability (or the resources) to follow through in the timeframes needed by the development team.

So what does the Agile development team do when the business users have limited (or no) availability to provide the input needed to progress project work? Do they escalate the issue to management to find a replacement (or supplemental) business representative, who may not agree with the original business users’ requirements and priorities? Do they put the development work (or the unresolved portion of the work) on hold until the original business users are available? Do they make decisions on behalf of the business users, in the hope that any incorrect assumptions (and the resulting development work) will be addressed in the next iterative review session with minimal rework?

This ‘holding pattern’ situation is one of the many risks of having individual, unsupported business users as the sole point of business information, prioritization, and issue resolution for the Agile solution. It is also one of the strongest arguments for including an Agile business analyst on the project team.

Having an Agile business analyst on the project team not only provides the Agile developers with a more readily available source when business knowledge is needed but also provides business users with ongoing support for their activities throughout the project timeline, making them more available to work with the Agile developers on the most critical review and decision activities at each point. These are only two of the many ways in which an Agile business analyst can add significant value to the Agile team – and the delivered solution.

The Power of the Agile Business Analyst details 30 activities that Agile business analysts can undertake throughout the project timeline to substantially increase the relevance, quality, usability, and overall business value of the delivered solution, including:

•Quantifying the business case for the developed solution, and providing valuation of individual software features

•Encouraging business users to think beyond their ‘business-as-usual’ activities

•Helping business users articulate their requirements

•Identifying the full spectrum of options for addressing business requirements beyond the software solution, including:

Business process improvements

Targeted staff training

Restructuring of roles

More effective corporate communication

•Challenging business users when their requested software features may not deliver the level of business value they anticipate

•Researching the data migration, systems integration, security, and capacity requirements of the solution

•Acting on behalf of the business user during software implementation, including when developing and executing acceptance tests, creating documentation, and providing training

•Providing expertise on aligning user interfaces, supporting documentation, and training materials to the needs of each target audience

This book has been written specifically to provide you with everything you need to leverage the skills, opportunities, and value an Agile business analyst can add to your Agile project team. An overview of the chapters is as follows:

•Chapter 1: What is Agile?

Provides a high-level overview of what Agile approaches are, who uses them, and the most common Agile methods in use

•Chapter 2: The power and perils of Agile

Identifies the limitations in current Agile approaches that can affect the business value of your delivered solution

•Chapter 3: Why your team needs an Agile business analyst

Introduces the discussion on how including a skilled business analyst can add significant value to your Agile team

•Chapter 4: What are the risks of not having an Agile business analyst?

Describes key issues that can arise when business users do not receive the same level of support as developers on an Agile project

•Chapter 5: 30 ways for the Agile business analyst to add value to your project

Details 30 specific activities the Agile business analyst can do to assist the business users and the Agile developers throughout the project

•Chapter 6: Getting the right Agile business analyst for your team

Provides you with guidelines on how to hire the right Agile business analyst for your team. It also offers guidance for those business analysts who have previously worked on waterfall software development projects to transition their skills to Agile projects

•Chapter 7: Moving your Agile team forward

Helps you to identify where an Agile business analyst can provide the most value for your specific project needs

•Chapter 8: More information on Agile

Provides general and practice-specific Agile and business analysis resources that you can refer to for further information

At the end of this book is an ‘Author’s note on Agile business analysis resources’, explaining why there are relatively few resources currently available on this topic, and how you can share your ideas, questions, and concerns with the Agile community.

CHAPTER 1: WHAT IS AGILE?2

‘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 organization by 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 features regularly presented to them as fully 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™), the Rational Unified Process® (RUP®), and the Agile Unified Process (AUP)

•Strategies for optimizing software development work, such as eXtreme Programming (XP™), and Lean Development

•Strategies for managing software development projects, as well as maintenance and support activities, such as Kanban and Scrumban

•Extensions of Agile methods to support large enterprise-wide teams and shared corporate objectives, such as the Scaled Agile Framework® (SAFe®), Scrum of Scrums, Large-Scale Scrum Framework (LeSS), and Nexus

These Agile methodologies have been (and continue to be) successfully used by thousands of organizations worldwide3, most notably in the US and Europe. Some of the more prominent organizations using Agile methodologies include Lockheed Martin4, Yahoo!5, Microsoft6, US Citizenship and Immigration Services7, Spotify8 and Hewlett Packard Enterprise9.

2Everything 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.

3 As evidenced by the number of signatories to the Agile Manifesto by March 2018, agilemanifesto.org.

4 How Lockheed Martin Is Taking On Agile,2015, https://content.pivotal.io/blog/how-lockheed-martin-is-taking-on-agile.

5 Scrum Case Studies Yahoo!, 2014, www.scrumcasestudies.com/yahoo.

6 Meeting the challenges of agile development at enterprise scale (2017): microsoft.com/itshowcase/Article/Content/881/Meeting-the-challenges-of-agile-development-at-enterprise-scale

7 PERSPECTIVE: How USCIS Ensures Section 508 Compliance in Agile Development 2018, www.hstoday.us/federal-pages/dhs/uscis-dhs-federal-pages/perspective-how-uscis-ensures-section-508-compliance-agile-development/

8 Spotify’s Secret For Competing With Apple, Amazon, And Google, 2014, https://labs.openviewpartners.com/spotify-great-agile-example-scrum-done-right/#.WwI9vOq5vIW

9 Case Study: HPE Software (2010 to 2018): scaledagileframework.com/hpe-case-study/

CHAPTER 2: THE POWER AND PERILS OF AGILE

The ability of 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 development team. The Agile development 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’).

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’s, 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 Poker10) 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.