A major consideration when adopting the Agile Service Delivery methodology is that it is a pull system and not a push system. This simply means that the team is constantly pulling work from the backlog versus it being heaped upon them as with conventional service delivery methods. Utilizing a pull versus push system does not preclude the scheduling of work, it simply means the default is to rely on the team pulling work from the backlog as a default.
Probably the greatest and most noticeable benefit to a pull system is that the techs and engineers are not stacked end to end with work to the point they can’t see an opening to get anything done that they may need to do, like filing a report or mentoring a teammate. With a push system, everything must be scheduled and if everything doesn’t fit, we tend to cram things in and make them fit. Conversely, a pull system allows large and time-bound things to be scheduled while leaving plenty of room for the individual and team to be much more dynamic in how they handle the larger pool of backlog issues.
One of the greatest but least noticeable benefits of a pull system is that once gauged, it allows you to define Service Level Agreement (SLA) Response Times based on what your team can actually deliver, not just on what some outside source indicates they should be. Of course, you do have to consider industry standards, competitors’ response times, customer needs, etc. when building targets for improved team efficiency, but these are two separate numbers. The SLA Response Time is a contractual agreement you are bound to and likely includes monetary considerations if missed, and the targeted team response time is an internal metric used to drive service delivery efficiency and quality.
The takeaway is that, by defining your SLA Response Time of what your team capability is, you’re not likely to find yourself with a heap of new clients who are pissing in your ear about what you promised and are not delivering. It also means your ticketing system shouldn’t be lit up red like a fire truck and spamming everyone because you’ve blown the SLA on every issue in the system.
Yes, this all relies heavily on having a well-laid-out process and a team that works very well together. But that’s for another blog.