Managing Client Behavior for Optimal Sprint Performance
[This article was originally published on Mike Cohn's Front Row Agile web site in November, 2016. But the site is no longer available and I have no idea where my article ended up so I'm reprinting it here.]
Early in the history of software development as a profession, somewhere around the late Jurassic Period, project managers would huddle around small green screens for warmth and talk endlessly with clients about what needed to be built. The details would be captured and a delivery date declared before the project managers would disappear into the mist enshrouded cubical forest with a parting promise to "communicate frequent updates." The common occurrence was that delays and confounding factors were never communicated to the client until after all heroic efforts to recover had failed and the unfortunate project manager had to ask the client for more time, money, or both.
As clients grew increasingly suspicious of the "dark art" behind software development, they began to venture into the cubical forest in search of answers. They did not like what they found. Leaping forward, at the speed of Moore's Law, to the product development environment we have today, it is fair to say clients have brought a great deal of light to bear upon the "dark art" of software development. Collaborating with many forward-thinking technical managers and software developers, clients became active participants in the design and development process. This is a very good thing, until it isn't.
I've observed two common scenarios where continued client involvement can result in unstable sprint velocities. The boundary where problems start to appear in these scenarios is somewhere around the time when the bulk of design work has been completed and the team has started to build things that will be found in the final product.
In scenario one, the client is allowed to continue working on the design deep into the development phase of the project. Changes stream into the development process until eventually a significant amount of rework has to be included in the product backlog. In one case I was involved with, the cumulative effect of design ambiguity resulted in the development on a particular component being halted and the sprint canceled after 80% of the known work had been completed. The client eventually dropped the component from the final product and "80% complete" became "100% waste."
Two key elements present themselves as important to focus on in order to prevent this type of client interference. The first falls to the product owner and their ability to determine and communicate clear expectations and commitments with the client. Clearly established change management practices with respect to enhancements and improvements would also go a long way toward limiting the amount of rework and waste. A second element would be to integrate the practice of design sprints into each project. Or, if design sprints are already used, hold a rigorous retrospective into how design sprints can be run more effectively.
In scenario two, success of the project is dependent on deliverables from the client. For example, the final product needs to integrate content related to the client's internal business processes or practices. Select individuals within the client's organization will need to provide this content. It could even be the case that the client provided content needs to be reviewed by one or more individuals within the client organization before it can be released. Perhaps human resources needs to provide the content for a solution related to on-boarding new employees and the legal department needs to review the material for EEOC compliance. If its a health care related solution, almost certainly it will have to "go through legal" before go-live.
Again, solid product ownership is importing to preventing this scenario. Setting and repeatedly communicating clear expectations is essential, as is having an agreed upon plan with the client for adjusting to the consequences of any client caused delays.
Whatever the particular scenario, the effect is usually apparent in the team's inability to establish a stable sprint velocity. Rework, waste and delays cause cards to spill from one sprint to the next as teams try to guess what the client impact may have on their sprint commitments. More deliberate approaches need to be made for solving issues caused by client interference and delays.
The most direct approach is to include the client as a member on the agile delivery team. Create story cards with well defined acceptance criteria that are assigned to the client. Include them on stand-ups, reviews and retrospectives. The resulting transparency to the process will allow the client to see the effects of their changes and delays on project progress and budget. This will generate more work for the product owner on the front end, but will save considerably more difficult work later on if the client has to be convinced that their behavior has had an adverse effect on the project.
If client participation on the agile delivery team isn't an option for some reason, I recommend using spike cards. Strictly speaking, spike cards are used for work efforts that have a significant measure of ambiguity and can't be easily estimated - researching a question or exploring various technical approaches, for example. The resolution of a spike card generally means that the team is able to move forward. Spike cards defined for client delay satisfy the intent of spike cards. The principle difference between a formal spike card and a spike card created to track a client dependency is that with the former someone on the team is actively working on the spike card whereas with the latter the team is waiting for the client.
When it becomes apparent a client dependency is in play, create a spike card that notes the client's promise for delivery. Close the card when the client makes good on their promise. Over time the spike cards can be used to establish the client's pattern for delivery of needed content or review feedback. This can then be factored into sprint planning. If it is known, for example, that the client is consistently several days late, this can be factored into the product backlog prioritization and sprint backlog composition.
When clients have been identified as part of the team's failure to establish a stable sprint velocity, rather than call them out as part of the problem, find ways to make them part of the solution.
Photo by Austin Distel on Unsplash