Ad hoc requests. We don’t like them. You’re in the midst of working on a scheduled task. You’re working hard, trying to get the job done in the allotted time. Then suddenly, it strikes — the ad hoc request.
They come in many forms. Here are a few examples of how they arrive:
- “Oh, I forgot to mention…”
- “By the way, I just realized…”
- “It turns out that…”
- “I said … but what I meant was…”
- “I just remembered something…”
- “The boss wants…”
- “Can you add this…”
Get the idea? Ad hoc requests come out of nowhere. Sometimes they’re trivial items but other times they’re game changers. No one likes them (unless your job is to handle ad hoc requests).
The waterfall crowd often shouts ‘change request’ or ‘change in scope’ as they try to stay in control of their workloads. The agile crowd shouts ‘backlog item’ meaning the request will have to wait until the next sprint. Does either response seem customer-friendly to you? They’re not.
Businesses don’t operate on the “We’ll do it later” philosophy. They need it now. Filling out change requests and seeking approvals sure look like stalling tactics, don’t they? What value do change requests bring to businesses? None. They benefit the development team by enabling them to remain focused. They also benefit development managers by allowing them to maintain control. Thus, they are self-serving.
The same is true of backlog entries. They have no business value either. They enable the development team to stay focused and they allow the team to maintain control of the current sprint. Good for the team but businesses don’t run on backlogs.
I understand that staying focused and maintaining control are important elements of any project. I get that. I’ve written about those topics before. Another equally important element is satisfying the customer. If you don’t do that, you’ve failed — end of story.
Deal With It
So, how do you deal with ad hoc requests in a way that keeps everyone satisfied? Here’s my proposal. (I’m focusing on agile development teams as I doubt the change-in-scope crowd will change the way they operate.)
- Don’t pack the current sprint with as much work output as you can fit. Leave some wiggle room. How much? It depends on the culture of the organization. In some companies, it seems like everything is ad hoc — if so, leave plenty of wiggle room.
- Order the sprint backlog into two simple groupings. A) Items the team will deliver. B) Items the team will try to deliver as time allows.
- If no ad hoc requests arrive during the sprint, all A and B items should get ‘done’. B items are not optional. They’re sacrificial in the event an ad hoc request arrives.
- If the team receives an ad hoc request, assess it immediately. What is the overall impact to the sprint and the release? How much effort is required?
- If the impact is negligible, just do it. If not, go to step 6.
- If the impact is significant enough to impact the plan, negotiate. Is the customer willing to sacrifice one or more of the B items in this sprint to receive the ad hoc request item? If so, enough said. If not, step 7.
- If you make it this far, you have a problem. You’re options are limited. You can cancel the current sprint and start over; extend the sprint deadline to allow enough time for the ad hoc work; or hold the sprint deadline and redefine the sprint backlog on the fly. None of these options is likely to be acceptable to everyone.
Aside from satisfying the ad hoc request, the next best thing you can do is demonstrate flexibility and a willingness to help. The person making the request may not get what she wants but she’ll feel good about the fact that the issue was openly discussed and viable options were evaluated. That’s a big win.