Agile Business Analysis: Enabling Continuous Improvement of Requirements, Project Scope, and Agile Project Results
336
Agile Business Analysis: Enabling Continuous Improvement of Requirements, Project Scope, and Agile Project Results
336Hardcover(None)
-
SHIP THIS ITEMIn stock. Ships in 6-10 days.PICK UP IN STORE
Your local store may have stock of this item.
Available within 2 business hours
Related collections and offers
Overview
Product Details
| ISBN-13: | 9781604271485 |
|---|---|
| Publisher: | Ross, J. Publishing, Incorporated |
| Publication date: | 11/13/2018 |
| Edition description: | None |
| Pages: | 336 |
| Product dimensions: | 5.90(w) x 9.10(h) x 0.90(d) |
About the Author
Kevin Aguanno, PMP, PMI-ACP, CSM, has over 20 years of experience managing complex systems integration and software development projects. He is well known in the industry for his innovative approaches to solving common project management problems and focuses on two project management specialty areas: agile project management and troubled project recovery.
As a well-known keynote speaker, author, trainer, and coach in agile management methods, Aguanno has taught thousands of people how to better manage high-change projects by using techniques from Scrum, Extreme Programming, Feature-Driven Development, and other agile methods. He is a frequent presenter at conferences and private corporate events where he delights audiences with practical advice peppered with fascinating stories from his own experiences in the trenches practicing agile project management. He is also founding Director and Vice President of the Project Management Association of Canada.
Ori Schibi, PMI-PBA, PMP, PMI-ACP, SMC, is President of PM Konnectors, an international consulting practice based in Toronto. With focus on project management, business analysis, and change management, his company provides a variety of services, including facilitation, workshops, training, and consulting, which deliver value to clients through a wide range of innovative business solutions. Many large to mid-sized organizations in diverse industries and levels of governments have benefited from PM Konnectors innovative services.
Mr. Schibi is a thought-leader and subject matter expert in business analysis and both traditional and agile project management. He is the author of Managing Stakeholder Expectations for Project Success, co-author of Effective PM and BA Role Collaboration, and a speaker and consultant with over 25 years of proven experience in driving operational and process improvements, software implementations, and complex programs to stabilize business, create growth and value, and lead sustainable change.
Read an Excerpt
CHAPTER 1
INTRODUCTION TO AGILE AND AGILE PROCESSES
Agile is not new, but its growth and increasing rate of adoption introduce new challenges (and opportunities) on an ongoing basis. Agile is also not the solution for all problems, but it is an approach, an umbrella, and a state of mind that, if done properly, can yield significant benefits for the performing organization. With that said, if agile is introduced the wrong way — in an unsuitable environment or under the wrong circumstances — it will cause more harm than good and there will always be someone who puts the blame on agile. While Chapter 2 of this book deals with challenges that emerge as part of adopting agile methods, this chapter introduces key agile concepts and examines the role of business analysis in delivering agile project success.
ABOUT AGILE AND WATERFALL
Agile is a pragmatic approach that recognizes that both the project team and the client do not know everything that has to be done up front, and that things will change along the way. Agile is an empirical approach — or, in other words, observation-based. It is open for changing needs and is evolutionary by nature, with multiple iterations (or sprints) — each producing a shippable product increment. The iterations are grouped into releases, where the customer actually receives, accepts, and, if needed, uses the released product increment. Agile addresses many of the challenges that were introduced by practices related to the waterfall approach, also known as a deterministic approach, where the team finalizes the requirements early on and then proceeds to build the agreed-upon product. Agile is made of the combination of two approaches: incremental (where product increments are released along the way) and iterative (where adaptation to change is continuous). Agile is not simply about breaking a large project into many small waterfall phases; there is more to it, thanks to the combination between the incremental and the iterative approaches.
It is not that agile is, plain and simple, better than waterfall. Although it addresses many bad practices that have been enabled by waterfall, there is still a place and time for a more deterministic approach. If a project has a set scope that is not about to change, and if the client does not need to benefit from early releases of the product by using it along the way, a waterfall approach may be suitable. Also, the fact that agile tries to fix some of the problems associated with waterfall does not mean that waterfall is at fault for project problems and is to blame for project failures. Waterfall simply enables some bad behaviors by allowing them to hide for too long before there are checks and balances to realize them. For example, because there are no interim releases and iterations along the way, the customer has the ability to see the product only at the very end — after testing has been completed — and only then can feedback be offered. It is possible that along the way the reports that provided the customer with updates were not portraying the actual picture, but the client had no chance to realize it because the reports were the only thing that the client had as proof of progress. This does not imply that the project team deliberately misled the client, but it is possible that information was communicated in a way that was misunderstood by the client. Good business analysis work and effective communication between the project team and the client can minimize the risk of such problems, but it provides no guarantee against such communication gaps.
Agile is an approach with several methodologies under Its umbrella. Some of these methodologies include Scrum, Feature Driven Development, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), Disciplined Agile Development, and Lean Development. While deterministic approaches focus on the plan and provide less flexibility, they also provide less chance of meeting schedule and cost constraints, which might lead to time and cost pressures that in turn may lead to quality problems. Empirical approaches, on the other hand, are evolutionary, observation based, and focus on delivering value by locking time, cost, and quality goals and focusing on scope flexibility.
In the early days of agile, around 2001, when agile was named agile, there was little to no talk about business analysis, or business analysts (BAs) in agile environments — and it was for good reasons:
• The role of the BA was still undefined — it was prior to when the International Institute of Business Analysis was founded (in 2003) and prior to when the Project Management Institute expanded its focus to include business analysis.
• The main premises of agile — including its focus on handling change, being nimble, reducing waste, improving communication, and building teams that are more cohesive — are all about reducing the need for a BA to bridge and connect different stakeholders, groups, and teams. It was therefore expected that agile role definitions include only three roles: (1) the product owner; (2) the Scrum Master, coach, or a role that is somewhat equivalent to that of a project manager (PM); and (3) a team member (meaning all technical members of the team). While some interpretations call for the inclusion of a BA as part of the team, this was not the original intent. Another interpretation of agile concepts agrees that there is a need for business analysis skills, but this need has to be addressed by team members demonstrating business analysis skills, without calling for a dedicated or distinct role of a BA on the project.
This book covers the growing and increasingly recognized need to have the skills of the BA present on agile projects. At times, we will discuss the need for business analysis skills to be demonstrated by a BA, and at other times, ensure that team members can demonstrate these skills. One way or another, it is clear that these skills are necessary and are important for project success, but there is no one clear and correct way to apply them. This means that for some project environments, it would be sufficient to have team members demonstrating business analysis skills, while other project environments need a BA to champion these skills and ensure they are applied consistently and correctly. In retrospect, as agile is closing in on completing its second decade, it is safe to say that although agile attempts to produce benefits that, if performed properly, lead to a reduction, if not total elimination of the need of BAs, agile growth and the way it is applied bring back those needs and with them — at times — the need for a specific role of a BA within the team.
One of the reasons that has rejuvenated the focus on business analysis skills in agile environments is the rapid growth of agile, its scalability beyond technology projects, and the attempts to introduce agile concepts in organizations and environments that are not a natural fit for agile — including slower moving financial institutions and government agencies. With more projects attempting to apply agile concepts and more team members assigned to those projects, there is a need to refocus the efforts and to add checks and balances that reduce the chance that these projects will fail. When more people within the organization practice agile and when more agile projects are competing for scarce resources, it leads to what we identify as agile dilution, where there is a decline in teams' relevant agile skills and a reduction in the true agile experts in the organization to oversee, support, and lead the agile process.
Before proceeding to discuss the basic concepts of agile, it is important to make the record clear: agile is not about the following things:
• Not about working fast: but rather, building products in such a way that we can produce value earlier.
• Not about no planning: agile planning is critical for success and it is simply done differently and throughout the project, instead of a heavy focus on building a plan early on. Agile focuses on the act of planning, rather than on the creation of a plan.
• Not about no requirements: similar to the planning, an important part of agile is requirements. While they are referred to by a different name — user stories — there is a need to elicit and manage requirements. It is done in a different fashion than what takes place in waterfall environments, but properly managing requirements is a critical part of agile success. It is the level of detail around requirements that changes since the project starts with high-level requirements and then the team elaborates and seeks details on a timely basis — like a rolling wave, only for the requirements that are up next in the cycle. The team and stakeholders need to come to terms with the fact that ambiguity is welcomed until more information is needed. In a way, the requirements are partially trial and error because the requirements that are defined at the start of the project may need to change later on as more information is discovered during the detailed planning. Agile is no different than waterfall when it comes to ambiguity. In both types of approaches, there is ambiguity and there is no full set of detailed information up front — it is just that agile teams recognize the ambiguity and accept it, while in waterfall, there is an attempt to finalize requirements and their details up front. This latter effort costs a lot of time, effort, and money, only to go through the likely need to change these requirements later on — in a process that not only costs a lot, but also one that adds a lot of risk. The reference made here to trial and error does not refer to the project objectives or the project vision, but rather to the process of building stories and refining their details.
• Not about being careless: many organizations attempt to apply agile concepts into projects the wrong way, in the wrong context, and for the wrong reasons — leading to uncertainty, confusion, and wild-west behaviors where team members careen forward irresponsibly, attempting to do things too fast, moving forward without planning, making reckless decisions, and causing more harm than good.
OVERVIEW OF AGILE CONCEPTS
Agile is a pragmatic approach that recognizes that there is a lot that the team and the customer do not know, a lot the team and customer learn along the way, and that things change without warning. Agile is a flexible approach that allows us to adapt and learn in real time as things happen, to respond to change, and to satisfy the customer as much as possible within the project constraints and realities. Agile projects start with a clear vision and product and are then broken into releases and iterations. The iterations should be of a consistent length (commonly, but not necessarily, between two and four weeks) and they are grouped together (any one or more iterations) into a release. Every iteration has a theme and goals and is made up of a slice of the project backlog (which is the total scope of the project — consisting of features, stories, and requirements). By the end of the iteration, the team needs to produce a working, production-quality product increment as if it was going to the customer. However, the product increment that is produced at the end of the iteration is for feedback purposes — the final product is actually delivered to the customer at the end of a release, with one or more iterations grouped together (and integrated through regression testing) — so this chunk of working product is a fully functional slice of the total product.
Known as iterative and incremental development, agile concepts help realize the following benefits:
• Adapt to changing needs, conditions, and environments in real time
• Produce benefits earlier through periodic releases of product increments
• Improve quality by giving the customer the chance to review progress periodically and improve based on actual performance and on the feedback provided — known as progressive requirement elaboration
• Reduce risk of building the wrong product and building the product with defects (the wrong way)
• Reduce scope efficiently through prioritization and reprioritization — agile enables the efficient reduction of scope by removing lower priority scope items in the later stages of the project once the majority of the value has already been delivered to the client
Additional characteristics of agile include accepting ambiguity in earlier stages until detail is needed, and ensuring that feedback is accepted as soon as possible so the team can properly act based on the feedback.
Lean Concepts, Wastes, and Principles
Additional agile concepts include the following:
• Continuous improvement of processes (learning) — improving processes and practices on an ongoing basis: This concept is inspired from the term Kaizen in Japanese (Zen = good; Kai = change). The continuous improvement refers to small, incremental improvements to be learned, realized, and applied on an ongoing basis, unlike concepts such as Kaikaku (from Japanese — radical change) which refer to dramatic and quick improvements. Continuous improvement takes place in small doses over time, which improves the ability to apply them one by one, reduces resistance, and helps isolate the impacts of the individual improvements.
• Customer focus: This is about producing and maximizing value for the customer.
• Lean principles: The lean movement started in Japan in the mid-1950s in manufacturing (the automotive industry) with its main focus on loss reduction and sustainable production. Figure 1.1 lists the original seven wastes identified in the Toyota Production System by Shigeo Shingo. Agile is one of the most significant and successful attempts to translate lean benefits from manufacturing to software development and, subsequently, to other service and non-manufacturing projects. Lean development can be summarized by the following concepts that are very close in concept to lean manufacturing principles:
1. Eliminate waste: Activities that do not directly add value to the finished product are waste. The three biggest sources of waste in software development are the addition of unrequired features, project churn, and crossing organizational boundaries. To reduce waste, the development teams need to self-organize in order to optimize themselves for the work they are trying to complete.
2. Build in quality: There is a need to design quality into the product, instead of relying on later inspection. But when this is not possible, there is a need to break the work into small and more manageable cycles that involve work-validate-fix-iterate. Inspecting after the fact and queuing up defects is reactive and ineffective.
3 Create knowledge and amplify learning: Promote strategies, such as iterative development, that help teams discover what stakeholders really need and act on knowledge as fast as possible. Leaning also involves frequent reflections and improvements.
4. Defer commitment (decide as late as possible): This is not a call for procrastination, but there is no need to start building a product by defining a complete specification. The design and architecture need to be flexible so they can change as needed. Deferring commitment to the last, most responsible moment allows the team and stakeholders to make the most informed decisions.
5. Deliver quickly (deliver as fast as possible): Quickly does not mean reckless; it is possible to deliver high-quality products quickly by identifying team capacity and limiting the work to this level. By becoming aware of its capacity (velocity), the team can establish a reliable and repeatable flow of work.
6. Respect people and empower the team: Sustainable advantage is gained from people who are engaged and thinking, and it is achieved by enabling and motivation, rather than controls and limitations.
7. See and optimize the whole: To achieve an effective solution, we must see the whole and the bigger picture, including understanding the high-level business processes that individual projects support across multiple systems and areas.
See Table 1.1 which illustrates the seven wastes of software development.
Combating Waste
To better understand agile principles and concepts, it is important to review the ways lean attempts to fight waste. For that, we need to check the underlying reasons behind the waste and think about ways to reduce or eliminate that waste. Although this book refers to the benefits of a BA, or the application of business analysis skills in any type of project environment, the wastes we cover here are the translations by the Poppendiecks of the manufacturing wastes that are identified by lean principles to software development wastes. The following are the seven wastes, along with the potential causes and solutions.
(Continues…)
Excerpted from "Agile Business Analysis"
by .
Copyright © 2019 J. Ross Publishing.
Excerpted by permission of J. Ross Publishing, Inc..
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Foreword xiii
Introduction xv
Acknowledgments xxi
About the Authors xxiii
WAV xxv
Chapter 1 Introduction to Agile and Agile Processes 1
About Agile and Waterfall 1
Overview of Agile Concepts 5
Lean Concepts, Wastes, and Principles 6
Combating Waste 8
Back to Agile 19
Agile Principles 20
Tools and Techniques 21
The BA, Efficiencies, and an Eye for Waste 23
Recap: Agile Concepts 26
Endnotes 27
Chapter 2 Agile Challenges 29
Different Views of What Agile Is 31
Why Many Attempts to Go Agile Fail 32
Agile, Culture, and Organizational Change 34
A Review of the Agile Manifesto 35
Dealing with Organizational Change 41
Approach, Readiness, and Governance 43
Choosing the Right Approach 43
Agile Readiness 52
Agile Governance 57
Too Much Focus on the Process 62
Resource Management and the Matrix Organization 62
Cross-Project Coordination and Dependencies 63
Day-to-Day Challenges 66
The Diluting Effect 68
Bias 72
Scrum versus Agile 72
Recap 73
Endnotes 74
Chapter 3 Roles and Responsibilities 75
Agile Philosophy 75
Traditional Business Analysis Activities 76
Agile Business Analysis 77
Agile Challenges Where a BA Can Help 78
Getting the Development Team to Take Control of the Process 78
Waterfall Thinking 79
Micromanagement 80
The BA Role in Agile Projects 80
Being Ubiquitous: Creating Shared Understanding 81
What to Expect of the Agile BA 82
Focus 82
Innovation 83
Proactiveness and Initiative 83
Context 84
Critical thinking 85
A Balanced Approach 86
Storytelling 86
Leadership 86
Adaptability 87
Communication Skills 88
Agile BA Responsibilities and Activities 88
User Stories 88
Be There for the Team 89
Facilitation Skills 90
Help with Agile Ceremonies 90
Decisions/Decisions 91
Questions to Ask 91
Additional Considerations 92
Role Impact 92
Team Differences 93
Team Impact 93
Systems Analyst 94
End-User and Non-functional Requirements 94
The Product Owner 96
Testers 96
Technical Writers 97
Knowledge Management 97
Scrum Master, the PM, and the Team 98
Business Analysis and Project Activities 100
The Agile BA and Facilitated Workshops 100
The Agile BA During the Iteration 102
The Agile BA and Iterative Development 102
Kitchen Sink: More Areas of Value Creation 103
Recap 104
Endnotes 105
Chapter 4 Agile Requirements and User Stories 107
The Importance of Requirements 107
The Requirements Management Plan 110
Product versus Project Requirements 113
Overview of Agile Requirements 114
User Stories and Use Cases 115
Agile Requirements and Agile Principles 116
The Difference Between Agile and Traditional Requirements 118
Changes to Requirements 118
Whose Need Do We Address? 120
Developing User Stories and Requirements 121
We Need the BA 122
The BA and the Product Owner 123
Back to Developing Requirements 124
Writing User Stories 124
User Stories, Epics, and Themes 126
INVEST in a Good Story 128
Personas 130
Use Cases 133
Graphic/Diagram 133
Scenario 133
Actor 134
Business Analysis Skills 136
Transition Requirements 136
Visualizing User Stories and Agile Analysis Work Products 137
Flow Chart 137
Interface Analysis: Storyboarding, Mock-ups, Wireframes, and Prototyping 138
Context Diagrams 138
Data Flow Diagrams 139
Activity Diagrams 139
Class Diagrams 141
Entity/Relationship Diagrams (Data Diagrams) 141
Sequence Diagrams 141
Recap 142
Endnotes 142
Chapter 5 Agile Documentation 145
Documentation in Agile Projects 146
Agile Documents 146
Agile Reporting: Artifacts, Project Reports, and Information Radiators 152
Iteration Burndown 152
Velocity 153
Epic and Release Burndown Charts 153
Cumulative Flow Diagram (CFD) 154
Control Chart 156
Task Board or Kanban Chart 157
More Reporting 158
Back to Velocity 158
Recap 159
Endnotes 160
Chapter 6 The BA Role in Planning and Estimating 161
A New Role for the BA 161
Agile: Not Unleashing New Potential 164
Same BA Skills-Different Application 164
Application of Business Analysis Skills 165
Business Analysis Activities to Enhance the Focus of the Product Owner 167
Traditional Planning 168
Delays Are Nonlinear 170
Multitasking 170
Feature Prioritization 172
Uncertainty 172
Estimates versus Commitments 172
The BA in Traditional Projects 173
Agile Planning 174
Agile Approach to Planning 174
Three Levels of Planning 175
The BA's Role in Planning 180
Release Planning 180
The Prioritization Process 180
Estimating Complexity 183
Ideal Time 183
Story Points 184
Velocity 188
Forecasting Velocity 188
Iteration Planning 191
Recap 193
Chapter 7 Agile Events and Work Products 197
Product Backlog and Prioritization 197
Iteration Planning 199
The Importance of the Backlog 200
Project Backlog(s)? 201
End of Iteration Demos 203
Different Types of Demos 205
Demo Challenges and Issues 207
The Essence of the Demo 208
Feedback 208
Prioritization and Backlog Maintenance 210
Business Value and Prioritization 211
Reprioritization 214
Acceptance and Doneness 215
Handling Change 216
How Is Change Taking Place? 217
Retrospectives: Applying and Fine-Tuning Lessons 218
Recap 220
Chapter 8 Testing and Solution Evaluation 221
Agile Approach to Quality 222
Test-Driven Development (TDD) 222
The Growing and Extended Role of Testing in Agile Environments 223
Proactive Approach 224
Working Together 225
Early Involvement, Planning, and Estimating 226
Increasing Role of the Testers 226
Regression Testing 227
What Is Done? 228
Automated and Exploratory Testing 229
How to Deal with Defects 232
Are These Always Defects? 233
A Reminder: Testers Are Part of the Development Team 234
More about Agile Testing 235
Testing and the BA 236
Challenges with Agile Testing 237
Agile Testing Challenges 239
A Waterfall Contribution to Fixing Agile Testing Issues 242
Agile Testing Best Practices 243
Testers' Roles 244
Keys for Success 247
Back to the BA and the Testers 247
Agile Testing Strategy 248
Recap 249
Endnotes 249
Chapter 9 A Day in the Life of an Agile Business Analyst 251
Daily Patterns 252
Distinct Days 253
Differing Levels of Formality 254
Sample Case Scenario 254
The Last Day Template 255
Timing 257
The First Day Template 259
Timing 261
The Middle Day Template 263
Recap 266
Chapter 10 Moving Forward 269
The Challenges and the Business Analysis Skills 271
Agile-Specific Challenges 271
Other Challenges 272
The Business Analysis Advantage 274
Proxy Product Owner and What It Means 275
Agile and Social Implications 276
Dilution 276
Challengers 277
Forcing Agile 277
Defying the Laws of Physics 278
Decision Making and Generational Gaps 279
The Future 282
Automation 282
Distributed Teams 282
Organizational Agility 284
Interpersonal Skills 285
Social Trends 287
The Future and the BA 290
The Future Is Here 292
Processes and Exceptions 294
Disruptive Forces 295
The Right Way 296
The BA and DevOps 297
The BA and the Retrospective 298
The BA Is Not the Product Owner: The BA Is the BA 299
Endnotes 302
Index 303