My colleague Erica Wagner (whom you know from the September 2006 issue of CBR) and I recently wrote a piece for the Communications of the ACM on the perennial challenge of user involvement in systems development projects.¹ We begin with the following sentence:

In the ham and egg breakfast, the chicken is involved, the pig is committed. This old saying may hold the key to understanding the high failure rates of large-scale software development and implementation projects -- there is a fundamental difference between participation and engagement. Our research suggests that workforce commitment and true participation (i.e., engagement in the process) are often difficult to achieve.

While we were indeed trying to be cute and clever, we also thought that the old "ham and egg breakfast" example simply and neatly captured the crux of the problem in large software development projects: stakeholders' involvement. In that paper, we recount a funny but sadly common anecdote I experienced firsthand when serving on the faculty advisory board on information technology here at Cornell. Members of the advisory board, who had been briefed multiple times about the status of a multiyear ERP customization and installation project, balked at the imminent introduction of a new course-numbering scheme. They raised several legitimate issues regarding incompatibility of the new numbering scheme with the many uses of these numbers. But this late-in-the-game feedback left the project lead visibly frustrated.

I am not an expert on the Agile development philosophy and methods, but given my past experiences I immediately latched on to the notion that Agile is not about doing more with less, but it is really about delivering the right system -- as measured by customer satisfaction, of course.

We could debate about where the responsibility lay in my Cornell example. The clients and other stakeholders in this case were as guilty as the project team and developers because they were sleepwalking through earlier meetings. Well, let's short-circuit this discussion right away. Just like professors and researchers bear the responsibility of readers' engagement and understanding when they write their articles, so do you as development professionals bear the responsibility if clients are not satisfied. Maybe you did not engage them or perhaps did not prepare them well enough to contribute to the effort. Either way, those who make a living designing and developing systems should be responsible for ensuring that the development process works. A harsh stance perhaps, but as one of our contributors puts it: "It's the customer, stupid!"

Agile software development has emerged as a viable option for enhancing speed of delivery and customer satisfaction in systems development projects. With the viability of Agile approaches now beyond suspicion, we at CBR thought an issue on how to make the Agile approach stick in your organization would provide the most ROR (return on reading).

Our academic contributor this month is Laurie Williams, an Associate Professor of Computer Science at North Carolina State University (USA), where she leads the Software Engineering Realsearch group. She is also the Director of both the NCSU Laboratory for Collaborative System Development and the Center for Open Software Engineering. Our practitioner view is offered by Sam Bayer, a Senior Consultant with Cutter Consortium's Agile Project Management practice. Sam has been launching software products into the market since 1986 and, in 2001, established MarketAcuity LLC, a management consulting firm dedicated to guiding the effective launch of software products into the commercial market or for internal deployments.

Our contributors stay true to their roles. Laurie plays more of the balanced-skeptic role, while Sam takes on the cheerleading evangelist from the "frontier of the possible" role. It is through this positive tension that this month's issue surfaces many tangible suggestions and tips for those of you seeking to make the transition to Agile stick and for those of you still on the fence.

Specifically, Laurie starts with an amusing story about her earlier life. I think many of you will relate to it. She then cleverly organizes her piece around the six key traits of a message that sticks as presented in Made to Stick, a book by Chip and Dan Heath. These traits are: simplicity, unexpectedness, concreteness, credibility, emotion, and stories. Using these principles, she intersperses useful tips and ideas with definitions that clarify the essence of the Agile movement. Laurie's analysis of the survey results reinforces the arguments throughout her contribution, and she closes with some clear, tangible guidelines.

Sam gets down to business immediately. I like Sam's writing style; his approach firmly rooted in his own experience makes the piece feel very personal and relevant. I also like his constant use of case studies to drive home key points. His anecdote about the bank is reminiscent of my research findings with Erica in our Communications of the ACM article. I particularly value his "Seven Rules to Making Agility Stick." Having been the one to force Sam to provide tangible guidelines and tips, I may be the one responsible for his family after "undermining a lucrative consulting career." But CBR is all about tangible takeaways, and I think you will value his tips -- his sacrifice won't be in vain, I am sure!

Not being an expert on Agile development methods myself, I found this month's installment of CBR particularly illuminating and useful. As Laurie mentions, for a message to stick, it must cater to the recipient's emotions. If you are engaged in a transition to Agile, or if you are thinking about it, I am sure you will find the WIIFM (What's in It for Me?) factor of this issue to be particularly high.

-- Gabriele Piccoli, Editor, Cutter Benchmark Review

ABOUT THE AUTHOR

NOTES

¹ Wagner, Erica, and Piccoli, Gabe. "A Call to Engagement: Moving Beyond User Involvement in Order to Achieve Successful Information Systems Design." Communications of the ACM, forthcoming 2007.