Customer and Team Collaboration

When I started developing software, customer involvement and collaboration weren ‚ t problems. In the 1960s, the computers were less powerful, the users were fewer, the applications were simpler, and the idea of milestones was still unknown. I used short iterations of one or two days. I ‚ d meet with the customer, and we ‚ d sketch out on paper what he or she wanted. We ‚ d discuss the problem until I understood it. Then I ‚ d go to my desk, design and code the solution, punch up the cards, and compile the program. Once the compile and link were clean, I ‚ d run some test data against the program. Then I ‚ d return to the customer and ask, ‚“Is this what you wanted? ‚½ We didn ‚ t realize it at the time, but this was heaven.

As the applications and technology became more complex and the number of stakeholders in a project increased, practices were inserted to coordinate the communication among the increased numbers of participants . For instance, because many stakeholders were involved, we began to collect all of their requirements prior to starting development. We felt that the system should implement the sum of their respective requirements. Because documentation was such an inadequate medium of communicating, we started to use pictures to communicate, supporting these pictures with text. And because pictures were imprecise, we developed modeling techniques to formally represent the pictures. Each step drove a wedge between the stakeholders and the developers. We went from face-to-face communication to documentation. We went from quick turnaround to lengthy requirements-gathering phases. We went from simple language to artifacts that were arcane and highly specialized.

In retrospect, the more we improved the practice of software engineering, the further we widened the gap between stakeholders and developers. The last step in the estrangement was the introduction of waterfall methodology , which embodies all the flaws of sequential development. Waterfall methodology gathers all the requirements, then creates the design, then writes the code, then develops and runs tests, and finally implements the system. Between each of these steps, or phases, were review meetings. Stakeholders were invited to these meetings to review the progress to date. At these meetings, developers and managers would ask customers, ‚“Do these requirements that we ‚ ve gathered and the models that demonstrate them constitute a full and accurate representation of what you want? Because once you say yes, it will be increasingly expensive for you to change your mind! ‚½ As you can see, this wording implies a contract between the customers and the developers. By this point, there was little in-person collaboration; in its place were contracts that said, ‚“If you agree that what I showed you is the complete description of your requirements, we will proceed. If you don ‚ t agree, we ‚ ll continue to develop requirements until you give up! ‚½

A favorite ScrumMaster of mine used to say, ‚“What does that have to do with code? ‚½ Anything that didn ‚ t quickly and demonstrably lead to code was a waste of time in her eyes. Her attitude drove the requirements modelers nuts. They felt that it was a wholly unprofessional viewpoint. However, it did cause them to evaluate everything they did in terms of immediate stakeholder value.

One of the ingredients of Scrum is a practice known as sashimi . Sashimi is a Japanese delicacy consisting of thin slices of raw fish. Each slice is complete in itself, a complete taste similar to the way every other slice tastes. Scrum uses the sashimi technique to require that every slice of functionality created by the developers be complete. All of the requirements gathering and analysis, design work, coding, testing, and documentation that constitute a complete product are required to be completed in every Sprint and demonstrated in the Sprint increment of functionality. Sprints are kept short enough that the stakeholders don ‚ t lose interest in the project before the Sprints are completed. And stakeholders can see that they have an opportunity to redirect the project at the start of every Sprint to optimize the value they derive from the project. At the end of every Sprint, stakeholders see new functionality. Models, requirements, and internal artifacts might be of use to the developers, but they are never shown to the stakeholders.

Stakeholders tend to be skeptical when first told about Scrum. Customers have had so many ‚“silver bullets ‚½ imposed on them that they can be forgiven for this, especially since each of the silver bullets involved more work for them but fewer results. A primary tool the ScrumMaster can use to improve customer involvement is the delivery of quick results that customers can potentially use in their organization. The Sprint planning and Sprint review meetings are the bookends to initiate and fulfill this expectation. If the Team is at all capable and the project is technologically feasible , the stakeholders and Product Owner can ‚ t wait to collaborate more with the Team.

Let ‚ s look at some instances in which Scrum provided an opportunity for the Product Owner and development Teams to work closely together to maximize the value of the project. At Service1st, we ‚ ll see how top management recognized the opportunity to get directly involved as Product Owners. At TechCore, we ‚ ll see how a young entrepreneur was able to sell his company for a premium by focusing his efforts on his work as the Product Owner. Finally, at MegaBank, we ‚ ll see how the ScrumMaster got the customers to be the Product Owners while minimizing the work necessary to teach and implement Scrum.