Implementing Agile Values and Principles: Chapter 4 (1st post)

A few years ago I wrote Understanding Agile Values and Principles (https://www.infoq.com/minibooks/agile-values-principles/). I’m working on a follow-up book about implementing them entitled Implementing Agile Values and Principles. I will post draft parts of the book on Medium.com as I finish them. I would certainly be interested in hearing people’s opinions about the draft material which I will certainly consider in making revisions as I work toward the final version.

This post is the draft of the 4th chapter on Customer Collaboration.

Chapter 4: Customer Collaboration

In UAVP, I said we could look upon this value as just a form of individuals interacting. However, people involved with developing a product for a customer will interact differently from working with their customer(s), focusing more on “how” functionality will be provided. Collaboration with customers will focus more on “what” that functionality will be and what is needed to confirm that the result meets expectations.

Of course, as the “what” gets defined, aspects of “how” will certainly be raised, but there should be room in such discussion for the development team to consider options for an optimal way to satisfy the “what.” Too much implementation detail too soon risks missing an optimal decision later as more has been learned about what will best satisfy a customer’s needs. It also means rework may be necessary to undo work done when the “how” is anticipated too soon and work is done to implement an expected future state that ends up not occurring or occurring with desired changes.

Effective, regular collaboration with the customer can avoid such problems and reach a result the customer finds most satisfactory. In this way, the customer will see the value to them of what is being produced early in the work and regularly throughout that work. This increases trust between the development team(s) and the customer(s) while avoiding the risk that the work does not meet expectations.

Part of the early conversation with customers involves helping them understand the benefit of the incremental approach to delivering what they need. In UAVP, I noted a conversation I have had with business people regarding the value of prioritization and scope management from an Agile perspective. Their normal expectation was “I need all of this done by the deadline and don’t care how you go about that as long as I get all of it.” They also would not be prepared for frequent reviews of the work as their interactions might only occur every quarter on an substantial project.

I would ask them, “Do you always get everything you want by the project deadlines?” They would look at me as if I were a bit dense and say, “Quite often, no.”

I’d follow that up with, “But you do always get the most important things by the deadline, right?” Again, I’d get a look as if I am truly dense as they say, “No. Frequently I don’t.”

I use this conversation to emphasize how prioritization and frequent feedback can help avoid problems getting at least all the highest-valued work done by the deadline and that the work done will meet their expectations. I also point out that tis approach can help them get necessary changes included if they accept that those changes, if of importance, may mean low priority work might not get done by their deadline. I explain that this is the Agile concept of “scope flexibility.”

I have found such a discussion, before planning and implementation begins, is important in avoiding misunderstandings and more difficult conversations later.

Customer Collaboration Practices

Just over 20 years ago at the earliest Agile conference (ADC 2003), there was a workshop to discuss customer collaboration experiences conducted by Helen Sharp (h.c.sharp@open.ac.uk) and Hugh Robinson (h.m.robinson@open.ac.uk). Among the ideas presented were:

· The “pre-requisite” of establishing trust between development teams and customers for any successful collaboration. Participants spoke of “building a language of exchange [that] you have to keep working on.” One participant did say “that even when you don’t have trust, if everyone is pulling together, with a shared vision, then the project can be successful.” I do believe that can occur, but I would expect it to be much harder if trust really doesn’t exist. I think “pulling together” and “a shared vision” would contribute to developing trust.

· Viewing customer collaboration as “a bridge between two worlds” and viewing it as “a role/person” with some participants noting how important testers in establishing that “bridge.” Success for that bridge role involves knowing “how the different groups work, and what is important to them.” This includes knowing“ and “keeping ambiguity…away from developers. Testers can be effective in the bridge role because they relate well, for example, to “customer support people [from whom] they learn a lot. Testers also “have a tolerance for ambiguity.”

· “Models and modelling” were “suggested as a form of bridge” because they encourage “questions to be asked that promote shared understanding and meaning.” Using them also can “help you identify ambiguities.” In the last chapter, various forms of visual diagramming were mentioned and are examples of such modeling.

Another topic covered in the workshop was what it meant to be called a “customer.” I’ll explore that with comments from the workshop as well as perspectives from other sources.

Customer Roles

In the workshop, there was “wide consensus that customer was a catch-all phrase that needed to be pulled apart so that various sub-roles were made explicit.” Such roles included people with expertise in product usage “shortcuts” and those with domain expertise. There were also business-facing roles such as

· An executive sponsor who had “the power to cancel a project.”

· A product owner (or an alternative role called the product champion) who “understands the business but can also talk technical” and “avoids the problem of the ’disappearing’ customer” and “useful particularly in situations where there were multiple customers or no customer.”

If roles such as these can function effectively collaborating with the development team, many potential problems can be avoided.

Sometimes an end customer can have difficulty explaining the true vision for the product and even the requirements because of limited domain and scope prioritization experience. They may also have limited understanding of their actual role related to the development effort nor the time to be available to devote to what the team needs (e.g., “writing stories, acceptance criteria)., giving feedback on finished features”). They may not even have been given the necessary “authority and decision-making ability” to be helpful to the team.

What then is the role of the “customer” whomever takes on that role?

The most important responsibility is to ensure, to the fullest extent possible, and with the help of others committed to do so, that the correct product is developed and delivered. This is accomplished, first, by providing a clear vision for what is to be done, then conveying clear requirements just in time to allow effective incremental development of value. This includes directing the priority of work and ensuring requirements (e.g., user stories) and associated acceptance criteria are understood by the team and being an effective member of the Agile team. Finally, the “customer” should be prepared to and contribute in providing feedback to the team as to the success of their work to satisfy expectations or what needs to be done to achieve that satisfaction.

However, the customer should not be expected to carry this burden alone. Everyone should remember that “customer” is a role, not a person, though a single person may, as a member of the team, be the focal point for the rest of the team regarding communication of what needs to be done. Behind that person can be many people helping to clarify those expectations. From the development team’s perspective, the customer should be the one voice they listen to for guidance regarding product functionality.

But what kind of help should the customer receive to do the needed work? Certainly, the rest of the Agile team should expect to help the customer help them.

This can involve help in the writing of user stories. Early clarification of any technical concerns can avoid more serious issues later. A team asking clarifying questions not only helps them better understand what is needed but can help the customer achieve such understanding as well. The old waterfall approach was to expect that serious due diligence devoted to requirements specification before work starts is intended to achieve at such understanding. Is it really fair, however, to expect people, especially the customer, to do this so completely that changes and discoveries will not happen?

If we accept that, even with concerted, collaborative effort, changes will happen, regular contact and effective communication between the customer and team will be needed to identify those changes before the risk and cost of doing so grows in difficulty and discourages such change from happening. Doing this includes the regular review at the end of each iteration of work of what the team has accomplished for the customer.

This regular access to customer feedback can be harder than the initial focus on the creation of requirements. But if customers truly care about what the team is producing, that access should be easier to achieve. In the spirit of customer collaboration, this access should involve customers devoting the time to meaningful aspects of panning, including story writing workshops where different perspectives can be provided, bringing together different customers who might not otherwise communicate with one another. (Chapter 10 will include aspects of how this “Working Together” can occur.)

Ideally, having the customer on the Agile team would be the best way to receive feedback on requirements and how best to meet those expectations. Any distance between any people involved in reaching a successful result reduces communication, limits trust, and increases risk. More effort must be expended to overcome these problems and they can increase if that effort is not expended. Smooth collaboration will be replaced by more “contractual” formality and low-bandwidth forms of communication such as more, and more detailed, written documents.

In Chapter 2 when communication was discussed, the subject of Powerful Questions was part of that discussion. Interaction with the customer can be helped with use of some powerful questions such as:

· How do you feel about <some interaction> between us?

· What do you feel we need to discuss that hasn’t been mentioned yet?

· Are there enhancements or changes to the work that could be done now rather than later?

· Has the work done to this point addressed (important) issues you face?

· Are there things we need to start doing? Stop doing? Do more of?

· What could we do that would delight you in seeing it accomplished?

Of course, you may look at some of these as encouraging too much “scope creep.” Asking some of these early could head off more difficult situations when they come up later in the work and it will be difficult to address them satisfactorily. Perhaps a follow-up question if there is concern for scope creep might be:

· What priority would you give this compared to other work already defined?

On the topic of delighting the customer Steve Denning, back at Agile 2011 suggested that a focus on doing so should be a part of a team’s Definition of Done. Even if the work is technically correct and has met acceptance criteria, Denning feels customers need to be “excited” and made to feel the development team “understands and [will] help you solve your problems.”

On the other hand, Matthew Dixon, Karen Freeman, and Nick Toman, in 2010 (https://hbr.org/2010/07/stop-trying-to-delight-your-customers) said:

“The idea that companies must ‘delight’ their customers has become so entrenched that managers rarely examine it. But ask yourself this: How often does someone patronize a company specifically because of its over-the-top service? You can probably think of a few examples, such as the traveler who makes a point of returning to a hotel that has a particularly attentive staff. But you probably can’t come up with many.”

Perhaps I would be the odd person in their view, but I can think of quite a few in my personal experience. I would not be surprised if you could as well. Now I do think that moments of delight don’t make up for any lapse in basic satisfaction in dealing with a business and the predictability of basic service.

However, the Kano Analysis model, developed in 1984 by Dr. Noriaki Kano, shows delight in comparison to meeting absolutely required expectations and expectations not as mandatory but which should increasingly be provided. This diagram shows this relationship.

If you are familiar with the MoSCoW prioritization model,

· The “Basic” line would be the “Must Haves” and all of them would have to exist to meet the minimum acceptable level of value delivery.

· The “Satisfiers” line would be the “Should Haves” and the more of them you deliver, the more satisfied the customer will be, though there is probably some amount of these needed to reach a minimal level of satisfaction. Beyond that, satisfaction increases.

· The “Delighters” line would be the “Could Haves” and every one of these increases satisfaction because it is beyond what was expected.

The thin, horizontal line indicates where the basic satisfaction “threshold” starts. Below that line, minimal satisfaction has not been reached. Above it, satisfaction grows as more is delivered.

Returning to Denning’s comments, he also suggested some other things to consider that could contribute to customer delight:

· A product or service that very simply solves a problem rather than “trying to solve too many problems at once.” He noted the original iPod’s “simple controls vs a DVD controller with 107 buttons that no-one in the family can use properly.”

· Delivering a useful, “slimmer solution” sooner instead of waiting for everything to be completed — a basic Agile incremental delivery idea.

· Somewhat harder to achieve was to “Read customers minds, anticipate their needs rather than relying on focus groups and surveys.“ This was famously Steve Jobs’ philosophy at Apple and Denning said “No one asked Apple for an iPod, iPhone or iPad.”

· Rely on what people “DO not what they SAY” which connects with Jobs’ view. Denning mentioned “New Coke” which focus groups liked but failed in the marketplace which “clamour[ed] to bring back the old taste.”

· “Let your customers become co-creators.” Create delight by focusing “on the market of one.”

· “Stop doing things that don’t add value — eliminate the waste.” A very lean principle.

Contract negotiation

On the right side of this value is the concept of “Contract Negotiation.” In UAVP I said contracts may not be a way to create collaboration between customers and development organization. As typically specified, contracts suggest the need to have everything “defined up front” and to define rigorous obligations for each party to the contract.

If there is a collaborative spirit already between the parties, rigor in the contract can be managed constructively. If that spirit does not exist, contract rigor can keep the parties separated as each seeks to optimize their ability to meet their obligations without concern for how this impacts the other(s). There can be a “you can’t sue me because I did what I was obligated to do” attitude where debates will occur on whether someone did or did not do that.

Ideally, a contract should speak how the parties will work together to bring about a satisfactory result for each one rather than just how each party can justify having met their obligation(s). If either party is unwilling to share decision-making and responsibility for the work there will likely be distrust and possible failure.

In UAVP I listed several things that identify how customers should try to implement to work effectively with development organizations and those organizations should help customers do. These were:

● an iterative process of requirements (e.g., user story) definition and refinement,

● prompt response to questions during the release/project to clarify functionality expectations,

● defining acceptance criteria (conditions of satisfaction) for each requirement,

● regular review of the functionality developed during that iteration,

● offering feedback to confirm their acceptance of what the team has done or their desire for any changes,

● ongoing elaboration of functionality as the team moves from highest to lowest priority in requirements, and

● prioritizing requirements from highest to lowest value so the development team always works on the highest-valued remaining functionality.

I then suggested that if “customers are not prepared to do these things or enough of them…perhaps a more ‘protective’ contract is smart.”

Having an “agreement” with your customer is what the things listed above include. Having a “contract” with your customers can be a way to clarify what each party needs to do. Neither of these should be expected to replace meaningful communication and partnering (collaborating) with one another to achieve a satisfactory result.

Try as we might, the attempt to convey all necessary information about both a product and how people will interact to create that product has never successfully been accomplished through static, textual documentation like requirements specifications or the contracts to which such specifications are usually attached. This has led to dissatisfaction and failure and most people know this, but this has not ended the practice of believing such means of communication will work “better next time.”

Both parties must understand and accept that project goals may change over time and any agreement/contract should allow for this to happen. It is recommended that detailed requirements specifications not be part of the contract itself because of the possibility of change. This is in the interest of both customer and development team to allow both the flexibility to seek and effectively deal with change. The contract can say how both will work together to deal with change.

Finally, in UAVP, I noted places to look for ideas on structuring agile contracts — a few being:

● https://en.wikipedia.org/wiki/Agile_contracts (which speaks mostly of “agile fixed-price” contracts),

● https://www.mountaingoatsoftware.com/articles/writing-contracts-for-agile-development (which takes a user story and conditions of satisfaction approach to documenting contractual expectations),

● https://www.scaledagileframework.com/agile-contracts/ (addresses this framework’s managed-investment contract), and

● http://www.agilecontracts.org/ (a 44-page extract from the book Practices for Scaling Lean & Agile Development by Craig Larman and Bas Vodde on contracts in an agile setting).