Embracing Agile—For all the Right Reasons

CIDM

June 2016


Embracing Agile—For all the Right Reasons


CIDMIconNewsletter JoAnn Hackos, CIDM

In the May 2016 issue of the Harvard Business Review, Darrell Rigby, Jeff Sutherland, and Hirotaka Takeuchi, document the spread of agile methodologies, which they helped to create, into wide-ranging industries and functions. They point out that National Public Radio is using agile to create new programs. John Deere is using the methods to create new machines. Saab is using it to create fighter jets. Even Mission Bell Winery is using it to improve wine production.

Certainly, information developers have experienced the rise of agile methods in their own work. In response to our request for proposals for the 2016 IDEAS summer online conference on Agile methods, we received an abundance of proposals from teams using agile methods for their work with software development teams and for their own activities.

Most of the information developers who take our Agile workshop or speak about Agile methods at our conferences talk about the dangers of agile, especially when the product development teams they work with are either untrained or have created their own “agile-like” methods. They are dismayed by management expectations that writers can be spread thinly across multiple product development teams, a practice that runs counter to agile principles and practices.

Most information developers we work with admit that the agile practices in their organizations rarely if ever involve customer feedback, although regular customer feedback is one of the prime requirements of the agile manifesto. As a result, agile methods are used to speed development work and get products delivered more quickly, certainly an agile goal. Unfortunately, the missing component is innovation. As the authors insist, “Innovation is what agile is all about.”

My concern is that agile’s place in information development is also too far from a focus on collaborating with the customer. Too often, we use agile methods to produce the same documentation that customers are not using or that does not meet customer information needs. Instead of using agile methods to produce innovative information and innovative ways of delivery information, we produce the “same old stuff.”

How then might we use agile methods to respond to evolving customer information needs? How might we use agile methods to innovate new forms of information delivery?

Long before agile was in vogue or even in our vocabulary, we worked with a team at then Compaq Computer on a customer partnering. A customer partnering is a process in which you involve a disparate group of customers in an effort to better understand their information needs. I described the process in detail in this article <http://www.comtech-serv.com/pdfs/Customer%20Partnering%20IEEE.pdf>.

We invited a group of Compaq customers, in fact a group of network administrators, to take part in a multi-session feedback process. We presented them with various Compaq documents and asked for their feedback. At one point in the partnering, the graphic design team asked if they could present a new idea for a quick reference card to be used to help install the Compaq network servers. They presented their prototype reference card to the customers, who completely rejected the concept and the content.

The quick reference card had been designed as a wall poster, but the network server rooms had no conveniently placed walls. The card provided basic installation instructions, but the administrators explained that they never ask inexperienced technicians to install servers. The information of the cards was of no value to the experienced technicians doing the work.

As a result of the feedback, the graphic design team started over in what might have been called a revised agile sprint. They worked with the administrators to design a quick reference device that might actually be valued and used in the workplace. An innovative idea, designed with close user collaboration, won the day.

Here is what the Harvard authors say about understanding where agile does and does not work:
“Agile is not a panacea. It is most effective and easiest to implement under conditions commonly found in software innovation: The problem to be solved is complex; solutions are initially unknown, and product requirements will most likely change; the work can be modularized; close collaboration with end users (and rapid feedback from them) is feasible; and creative teams will typically outperform command-and-control groups.”

In many organizations that we work with, documentation is stuck in a rut. The same documents have been produced for years, growing larger with new product features and functions. Yet, the organizations indicate that they doubt that customers use the documents or most of the content available in them. Such a situation is a prime candidate for something new, something innovative. We have so many alternatives today to deliver information more effectively. We can create topics rather than chapters, associate procedures with needed conceptual information through reference, or provide precision search systems. Yet, we need customers to tell us if we’re on the right path.

We continue to talk about the challenge of developing solutions-oriented information, something that customers clamor for. They want to understand how various parts of our products work together and how they can work with them to solve their problems and produce better solutions. Yet, this documentation is difficult to write because it requires a team of experts, both internal and from the customers, to do it right.
Customers, as we learned from John Carroll’s work, prefer to use minimalist documentation, but it’s difficult to get minimalism right. We need customer feedback to help hone our minimalist solutions. Agile is the perfect tool. It allows us to develop incrementally, develop quickly, and get immediate feedback, not negative comments long after deployment. We make mistakes, and we learn from our mistakes.

Do consider agile methods for information development, but use agile methods where they are strongest—to develop innovative approaches to meet customer information needs.

The theme for the 2016 Best Practices conference in September is Maximizing Value—Reducing Waste: Moving to Leaner Practices, Processes, and Information Products. Agile methods are part of the agenda. Join us in Santa Fe, New Mexico for a serious discussion on the value of agile innovation methods. CIDMIconNewsletter

JoAnnHackos

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close