FEATURED BOOK: Outside-in Software Development

 PDF Print E-mail
Written by Brad Appleton   
Tuesday, 08 April 2008 12:46
april-08-bookwideA 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 (0)Add Comment


Write comment

feedShow/hide comment form
smaller | bigger

security code
Write the displayed characters


busy
< Prev   Next >
 

Agile Marketplace - Announcements and Special Offers

Complimentary Webinar w Forrester Analysts on Agile and Lean ALM
Complimentary webinar with Forrester Analysts Jeffrey Hammond and Dave West. Learn about Lean ALM Development, optimizing processes, cutting costs and compliance by design.
Read More

Agile CMMI – The Best of Both Worlds
Shares how a leading financial institution gains CMMI level 3 compliance and supports Agile practices.
Register for CollabNet webinar May 21

Requirements-based testing (RBT) can help you increase efficiency, reduce project risk, and improve overall software quality. Learn how MKS Integrity for application lifecycle management enables RBT, delivering full lifecycle traceability to help ensure that project requirements have complete test planning and execution coverage. Download the Requirements-Based Testing whitepaper