Many software development teams, especially those creating or supporting a shared platform or infrastructure, find themselves overwhelmed by ad-hoc work requests. A frequent response to this situation is to move from an iterative, incremental practice to Kanban or some other flow-based model.
In many situations, this is the exact opposite of what should happen. When a team finds itself foundering under the weight of system support or ad-hoc work requests, it may be time to start batching that work instead of letting it flow more easily in and out of the team.
Learn to Say “Not Now”
“But, I could never do that because we have to work on the issues as soon as they come up,” I can hear you saying. “We could never tell our customers they’ll have to wait for a bug fix or system change.”
A wise person once said, “A lack of time is actually a lack of priorities.” Take a moment to ponder that statement and apply it to your context. Does your team feel responsible for closing all the issues that are brought to it? Probably. Do you (or your organization) measure your team’s success in volume of requests processed? If you are a software development team, probably not.
I get it. It is very hard to say no. So, don’t. Instead, learn to say, “Not now,” and put work on your backlog for a future Sprint. Make the backlog extremely transparent. Be prepared to explain (a lot) why a given request is lower in backlog than work that genuinely moves the team forward. The urgency around the issue will often dissipate before your next Sprint Planning meeting.
Making over Maintaining
As per the agile manifesto, the only real measure of success is working software. Success on a development team should never be measured in volume of tickets serviced. That sort of measure is appropriate for an operational support team.
Moving from iterative and incremental delivery models to continuous flow models is often a sign that the team no longer sees its main responsibility as creating software, but in keeping a system up and running. The move from development to operational team is self-fulfilling. In this world, the underlying system is wagging the team instead of the other way around.
If you find yourself in the situation of being expected to create new value through new software features AND being held accountable for servicing a high volume of ad-hoc requests, two things may be true.
- Your underlying system is chock full of technical debt. This is often why the ad-hoc requests are coming in in the first place.
- You are on a path to a death march. Even a patient executive will eventually demand the team focus on delivering new features or functionality instead of firefighting the old system. Unfortunately, the time available to do this will have been cut short by your unwillingness to say, “Not now,” to all the ad-hoc work you believed was unavoidable.
In a high functioning development team, the majority of time is spent looking ahead and adding new capabilities to a given system. If your team is spending less than 75% of its time doing this, you may be on the verge of “going operational” which ultimately means even less time available for new capability development. “Going operational” often represents defeat for a development team. That isn’t to say that you shouldn’t embrace a DevOps mentality and support your system in production. It just means that you should have more time available for adding new capabilities than servicing ad-hoc requests and defect management.