RMC Learning

TM

Solutions

of a Reluctant Agilist

Why Agile Works

A Business Analyst
perspective on Agile from
RMC Learning Solutions
www.rmcls.com

www.rmcls.com v.5 Share this perspectives paper:

Confessions of a Reluctant Agilist

Learning
RMC
TM

Solutions

10953 Bren Road East, Minnetonka, Minnesota 55343, USA

Main +1 952.846.4484
Fax +1 952.846.4844
E-mail info@rmcls.com

Copyright © 2013 RMC Publications, Inc. All rights reserved. Except as permitted under the United States Copyright Act of 1976,
no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database retrieval system,
without prior written permission of the publisher.

www.rmcls.com v.5 Share this perspectives paper: 2

 Confessions of a Reluctant Agilist

Table of Contents

Meet the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Reluctant Agilist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Myths and Truths About Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Why Agile Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

About RMC Learning Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

www.rmcls.com v.5 Share this perspectives paper: 3

Confessions of a Reluctant Agilist

Meet The Author

Barbara A. Carkenord, CBAP®, PMP®, PMI-ACP®
Practice Director and Trainer—Business Analysis

Barbara A. Carkenord, Director of the Business Analysis Practice

at RMC, has over 25 years of experience in business analysis, and
is one of the original founders of the Business Analysis training
industry. Barbara has an MBA from University of Michigan, is
a Certified Business Analysis Professional (CBAP®)a certified
Project Management Professional (PMP®), and an Agile Certified
Practitioner (PMI-ACP®). She is also the author of the worldwide
best-seller Seven Steps to Mastering Business Analysis, and is a
frequent speaker at industry conferences and chapter events.
Actively involved in the IIBA, she was a core team member of
the IIBA BABOK® creation committee and contributed to its
Barbara A. Carkenord,
book, Managing Business Analysis. In 2010, Barbara was named CBAP®, PMP®, PMI-ACP®
Small Business Woman of the Year by the Georgia Women in
Technology Association. Connect with Barb

twitter.com/bcarkenord

Barbara possesses detailed knowledge and experience in linkedin.com/pub/barbara-carkenord

many analysis tools and techniques. She develops and delivers facebook.com/barbara-carkenord

business analysis training using proven techniques and real-world

experience. Barbara’s areas of expertise include business analysis,
software design, quality assurance, and project management. Her
experience covers many industries including insurance, banking,
and manufacturing. Her most current publications include the
CBAP®/CCBA® Exam Prep textbook, PM FASTrack® CBAP®/
CCBA® Exam Simulation Software, and Hot Topics Flashcards—all
released by RMC Publications in 2012.

www.rmcls.com v.5 Share this perspectives paper: 4

 Confessions of a Reluctant Agilist

Executive Summary
Like many Project Managers and Business Analysts, I was
reluctant to embrace the agile approach to product development. Do you remember the
first time you heard
In this and subsequent articles, I’ll share the reasons for my about agile? What was
reluctance and the reasons for my change of heart. I have learned
your first impression?
that agile includes excellent techniques and concepts, built on
well-established principles, proven to increase project success. I
hope to convince other reluctant professionals to take a closer
look at agile, getting past some of the myths and hype. I also
hope to reinforce to “agilists” that skills and techniques from both
the business analysis and project management professions are
still needed on agile projects.

www.rmcls.com v.5 Share this perspectives paper: 5

Confessions of a Reluctant Agilist

Reluctant Agilist
My first exposure to agile was at a business analysis conference
when a speaker displayed a NOT sign (red strikethrough) over Business analysis work
the letters BA on the huge conference screen and stated that if is critical on every
you use an agile approach you don’t need business analysts! I was project. It doesn’t
shocked and wanted to yell “Are you crazy?!!” As a passionate
matter who does it
business analyst, this statement left me fired up with righteous
indignation. Critical thinking and careful analysis are keys to
– but it needs to be
success in any type of project. The agile manifesto sounded like a done. If the members
bunch of developers who didn’t want to read requirements or be on an agile team are
held accountable for following them. It is no wonder I started out strong analysts, the
with a bad attitude about agile!
result will be a useful
After this introduction, I didn’t actively seek out information on
product.
agile, but a co-worker of mine kept saying “you should take a
look at this” and “there are some good ideas here.” I try to stay
aware of industry trends; articles and comments about agile
kept popping up in my reading. I heard the agile claims of faster
delivery by the use of co-located teams and no requirements
documents. As I have come to learn, these characteristics of agile
are over-simplified, inaccurate, and definitely not the best reasons
to adopt an agile approach.

www.rmcls.com v.5 Share this perspectives paper: 6

 Confessions of a Reluctant Agilist

Myths and Truths about Agile

Initially, the idea of two week iterations or sprints sounded
Myths about Agile:
ridiculous to me! I’ve worked in companies where we couldn’t
• No requirements
agree on one simple requirement in two weeks. I envisioned
• No business analysis
developers locked in a room, working around the clock, • Chaotic work environment
surrounded by old pizza boxes, developing sloppy code with lots
of bugs. As I later learned, agile practices get stakeholders to
agree on smaller deliverables, allowing completion in a shorter Truths about Agile:
amount of time. Agile developers don’t develop faster; rather agile • Lots of great techniques
involves a better process for prioritizing and selecting product • Focus on business value
• It is all about collaboration
features and delivering them in smaller increments.

I also didn’t believe in the idea of co-located teams. A whole

bunch of people working in the same room, talking whenever
they need to and having a status meeting every day (the
daily standup) sounded chaotic to me. It seemed like micro-
management. When I was a developer, I liked quiet, uninterrupted
time to concentrate on the complex activity of coding. As a BA,
I do my most complex analysis in isolation, away from e-mail and
other interruptions. Working in a big room with lots of noise and
distraction doesn’t facilitate critical thinking. In addition to my
concerns about concentration and distractions, I don’t know of
many organizations that have their entire teams in one city, let
alone in one room! A more accurate description of agile is the
focus on collaboration. A co-located team is easy to visualize,
but the important characteristic is teamwork and constant
communication. Business stakeholders, like the product owner, are
collaborating with the developers to design the product, rather
than developers designing in isolation. The concept of “I’ll know it
when I see it” is encouraged in agile. Business people watch how
the product is made and can suggest adjustments along the way.

www.rmcls.com v.5 Share this perspectives paper: 7

Confessions of a Reluctant Agilist

Why Agile Works

Being a strong advocate of thorough analysis and knowing
Satisfying business needs involves:
the importance of accurately documenting requirements, I
• Conversations with business
responded very negatively to the idea that a team doesn’t need
stakeholders
requirements. I have overheard business people talking directly • Critical thinking
with developers and there is often a big disconnect. Business • Agreement on the basic
people are not knowledgeable about design or technical features of the product
constraints and developers rarely understand the business
problem to be solved at the level of detail needed. Thinking We call these Requirements.
that a simple user story is going to take care of all of the details
of a complex business problem is not realistic. Talking about
a feature or function is one thing; seeing it in writing is very
different. If we don’t write it down, different people have different
understandings of the product design.

As I learned more, I recognized that the agile approach values

requirements, but just doesn’t require the level of formality I
was used to. This approach speaks to the reality that on many
waterfall projects, the requirements development process is a
bottleneck.

Business analysis professionals consistently report they are

pushed to speed up requirements development and have a
hard time getting business stakeholders to read and sign off on
the requirements documents. I’ve always been a big advocate
of modeling and diagramming requirements rather than
documenting everything in text. Agile supports modeling and
visual requirements and uses whiteboards, post-its, and flipcharts
to communicate. These are tools many analysts and project
managers have been using for years. A requirement sketched on
a whiteboard is just as useful as one drawn in MS Visio®.

www.rmcls.com v.5 Share this perspectives paper: 8

 Confessions of a Reluctant Agilist

Why Agile Works (continued)

I was still somewhat reluctant about agile when I took my first
formal agile class. As techniques were introduced, I looked for Concepts like Servant
flaws and weaknesses. But I found more similarities to the way I Leadership come from
work than I expected. I began to understand the reasons for the
a long history of suc-
popularity of agile. I discovered that many of the techniques and
principles supported work I had done on many “non-agile” teams.
cessful management
I decided to immerse myself into agile and give the approach a strategies and are
fair chance. embraced by agile.
I emerged from this deep dive study with a positive, yet realistic,
attitude about agile. It is not a silver bullet, it won’t solve all of our
backlog and timing problems, and it won’t work for every project.
But there are some very solid foundations and lots of great
techniques that are useful in many situations.

Conclusion
I’d love to say that one day I suddenly became agile, or one
project experience completely changed my attitude, but the Is Agile All or Nothing?
reality is my conversion was a slow, evolving process. I allowed
myself to learn about various aspects of agile and found I had
already been practicing much of what agile recommends. Many of
the techniques and tools included in agile are the same techniques
we use in other software development methodologies, including
RAD (Rapid Application Development), RUP (Rational Unified
Process), JAD (Joint Application Development) and even waterfall.
Agile renamed some of these techniques, but the fundamentals
are consistent with practices that have always improved project
delivery, product quality, and stakeholder satisfaction.
Pure agilists and scrum masters advocate an all or nothing
approach: either adopt all of agile or don’t bother with any
of it. But I disagree. Most projects will benefit from a hybrid
implementation of agile techniques and philosophies, even if the
organization doesn’t want to embrace every recommendation of
agile. Smart, experienced, knowledgeable professionals (including
program managers, project managers, and business analysts) will
be able to leverage these techniques in the right place and at the
right time to increase their teams’ effectiveness.

Look for my article “Ten Agile Techniques Every Team Should

Know” to learn about the agile techniques I find most useful on
many types of projects. Techniques like fast failure, timeboxing,
and product vision are excellent practices which can bring value
to any team.

www.rmcls.com v.5 Share this perspectives paper: 9

Confessions of a Reluctant Agilist

About RMC Learning Solutions™

RMC Learning Solutions develops and trains project managers,
business analysts and agile practitioners by helping them learn
the skills necessary to succeed in their careers. We deliver a wide
range of training in multiple learning formats across the globe.
Founded in 1991 by Rita Mulcahy, the company continues to
develop and provide innovative, real-world tools and instruction,
delivered by professionals with extensive experience and a
working knowledge of industry best practices.

For more information visit www.rmcls.com/professionaldevelopment

Accelerate Your Skills and Job Performance

RMC Learning Solutions

Click here for

MORE INFORMATION

*RMC Project Management is now RMC Learning Solutions™

10953 Bren Road East • Minnetonka, Minnesota 55343 USA

RMC Learning
TM

Solutions Main 952.846.4484 • Fax 952.846.4844 • E-mail info@rmcls.com

www.rmcls.com v.5 Share this perspectives paper: 10