Home  Home
|
FEATURED BOOK: Outside-in Software Development |
|
|
|
|
Written by Brad Appleton
|
|
Tuesday, 08 April 2008 |
 A Practical Approach to Building Successful Stakeholder-based
Products, by Carl Kessler and John Sweitzer
Reviewed by Brad Appleton
Kessler
and Sweitzer's Outside-in
Software Development should resonate deeply with all those who
genuinely value the principle of customer collaboration in the Agile Manifesto,
and with anyone who has played the role of Product Manager for a software
project. This 2008 Jolt
award Finalist is not a book
about eliciting or prioritizing requirements (or "user stories") for an Agile
project. This book goes beyond mere user-stories and their ranking or velocity
to focus on uncovering the underlying needs and goals of your stakeholders and
understanding what truly adds value for the customer and the business.
The
book's authors are a software director and VP (Kessler) and software architect
(Sweitzer) from IBM Software Group. They evolved the stakeholder-based Outside-in
approach to developing software and have applied it with growing success.
The first
chapter (which
is available online) introduces the overall Outside-in approach. Those
familiar with the Lean ethic of gemba
(and genchi gumbutsu) as a
means of letting the customer define value will have a great appreciation for
the Outside-in approach espoused in this book. (Carl Kessler also has a related
blog entitled "Outside-in thinking".)
Chapter 2, "Understanding
your Stakeholders", describes the four kinds of critical stakeholders for
any software project, in order of their importance:
- Principals: The business-decision
makers who ultimately buy the product, or make the decision to put it into
use. ("Gold Owners" in early XP-speak)
- End-users: The individuals
who actually use and interact with the product in order to accomplish
their tasks, and who ultimately experience how the software works in the
real world.
- Partners: Those
responsible for "making the product work" at the customer such as internal
IT operations, or external partners who provide services like deployment,
installation, upgrade, helpdesk/support, customization, configuration,
administration, systems integration, outsourcing, hosting, or even application
development for the product.
- Insiders: The
people within the product development team and overall
organization/company that shape how the software is developed (this can
include marketing, QA, testing, and more).
All
four of these stakeholder groups are important and unique, and it is vital to obtain
feedback from all stakeholders, even those
that are not the target audience of your software. Once you have identified
these stakeholders you must engage them in active, continuous dialogue in order
to understand their goals and organizational contexts. Then, you determine see
how to align your insiders and your process to address those
goals and deliver a valued user experience.
Chapter 3, "Understanding
Organizational Context", is the one which I found most fascinating. It
describes some recurring patterns of organizational context and structure, and
then introduces the notion of organizational
context variance (e.g., distributed, federated, centralized, etc.) and the
corresponding organizational variance
design patterns to get and use stakeholder feedback.
Chapter 4 introduces another key concept which the authors
term consumability! Consumability is all about getting the
product into the hands of the customer in a way that minimizes the time and
effort required for the user's experience to realize the value of the software.
Little and not so little things like packaging, installation, configuration,
ease of deployment, and use all contribute to how quickly or slowly (and
painfully) the users can be productive with your software in order for your
customers to realize its resulting business value.
I particularly liked the emphasis on and discussion of
consumability because it forces us to think about things like being lean not
only in our development process, but also in all the post-release activities of
the value-stream that happen between releasing the software, and the user
experiencing the software (and the value finally being realized). Lean and
Agile thinking often have us consider things like responsiveness to change,
cost-of-change, eliminating waste, constraints, and maximizing flow for
development. But how often do we Lean/Agile types remember to think about those
same things in the context of the end-user at the customer site who may be:
struggling to:
- receive
the first (or latest) version of what we released;
- take
it out of the box, unwrapping or cutting away the packaging materials and
security/authentication devices;
- understand
how to install/deploy/upgrade the software;
- then
finally begin using the darn thing;
- and
then determine and report (and receive support for) problems we encounter
during its use.
These are the sorts of things that can make or break a
successful product launch, even if you appeared to do everything "right" for
the development portion of the product lifecycle.
Chapters
5 and 6 are about Aligning with
Stakeholder Goals and Defining
Success in Your Stakeholders' terms. Several Agile development practices
are explicitly mentioned, as well as the need to focus on long-term commitment
to the customer and obtaining feedback (and realigning yourselves) in so called
"waves" (which bear more than a passing resemblance to "iterations" of feedback
gathering and analysis). The final chapter, Becoming
an Outside-in Developer, discusses how to lead the transformation to
becoming an Outside-in development organization, including how the approach is
well aligned with lean, agile, and even other initiatives (such as six-sigma)
and how to map it the vocabulary of each for your organization.
I
think Outside-in
Software Development is a profoundly
important book for anyone in the Agile or Lean "camps" because it addresses and
embraces the often neglected pieces of the customer-relationship puzzle that
emerge from the stakeholders' perspective, often after the software is
released. It shows us how many of those same Lean and Agile values of collaboration,
responsiveness, waste-elimination, and respect for people can be successfully
applied to the users' experience with our software, and to the stakeholders'
experience with ourselves in the service of realizing the very business value
we strive to deliver.
About the Reviewer
Brad
Appleton is an enterprise SCM/ALM solution architect for a Fortune 100
technology company. Currently he helps projects and teams adopt and apply agile
development & SCM practices. Brad also author's the Agile CM Environments blog, and is
co-author of Software
Configuration Management Patterns: Effective Teamwork, Practical Integration, the
"Agile SCM" column
in CMCrossroads.com's CM
Journal, and is a former section editor for The C++ Report. Since 1987,
Brad has extensive experience using, developing, and supporting SCM
environments for teams of all shapes and sizes. He holds an M.S. in Software
Engineering and a B.S. in Computer Science and Mathematics.
Comments () |
 |
|
|
|
Tags:
Click to add your tags...,
|
|
