I regularly get asked how we handle certain scenarios common to the client – agency model and continue to work in an agile way when faced with scenarios which might disrupt the way we want to work. It’s not that people want agile to fail, just that some people are sceptical or intrigued about how on earth it can work knowing that certain clients can excerpt an overwhelming pressure whilst you’re working for a different customer.
We know for a fact, in order to be most productive, to deliver high quality work and to keep both the team and client happy (EQUALLY important) we absolutely must maximise our hours within a sprint. Meaning that anyone in a sprint must stay in that sprint free from external interference/distraction as much as possible. This would be much easier for say a start-up or a team working with a single product/platform but not so easy when we have to deliver new projects quite rapidly, support old projects and improve existing projects. All these lead to pressure from clients to get things done ‘ASAP!’. And that’s when your sprint team, if you don’t know of a way of handling this becomes disrupted.
The two most common external forces are a) how to deal with critical issues/bugs? and b) how to deal with an urgent ad-hoc request (‘we absolutely must have this done NOW or we are going elsewhere’)? Both whilst maintaining focus on the sprint we are working on that week for a different client.
The Sprint Team
We deliver our work (user stories) in things known as sprints. A sprint is 1 week of dedicated studio time involving the resources required to deliver the work during that sprint. Therefore the sprint team is our gold dust and absolutely must be protected so they can be as focussed, happy and productive as possible. Typically for us a sprint team is made up from 4 resources including 2 backend developers, 1 frontend developer and a further resource made up from design, testing and project management. Generally this amounts to around 120 hours but it isn’t fixed absolutely.
First and foremost (and I’ve learnt this from experience), you need a buffer. That buffer can be a project manager or an account manager or someone else, it doesn’t really matter who but it has to be someone who can be distracted without affecting the sprint team. This person can collect information and do some initial prep work. If a client calls with a bug, they can double check it really is a bug (and you’d be surprised how often it isn’t), if they are calling for technical help it’s likely they will be able to provide it without handing over to anyone else and if the client is calling for a new feature they can ascertain how urgent the feature is.
So far so good, the sprint team is still in tact and trundling along nicely.
But we have only fielded calls/emails so far and not actually fixed or changed anything. How do we do that and still not disrupt the sprint team?
The Gun Slinger
OK, so I made the name up. I used to call this person ‘The Floater’ but that appealed to too many folks toilet humour so I made the name more glamorous and catchy. A label to be proud of!
In essence this person is able to hoover up problems, handle the urgent ‘MUST HAVE’ client request and work closely with ‘The Buffer’ to keep everything ticking over without distracting the sprint team. The Gun Slinger can react quickly or ‘shoot from the hip’. It means we can respond to any support issues well within our SLA and importantly we can keep the conversation going with all our clients even though we are working on other sprints for different clients. And this is essential for maintaining client confidence in our ability to offer a professional and continuous service.
Oh, and the best bit… the Gun Slinger can operate on a sprint too when they have no other issues to manage. Not a single minute of their time need be unproductive. They can pick up well-defined user stories in the Up Next column on our sprint board and away they go.
The person can also be rotated each week too, avoiding the obvious feeling of being ostracised from the team for any prolonged period.
Alternatives? The Fudge
The name isn’t entirely fair as I think it deserves a mention as an alternative approach. I’ve seen this method being used elsewhere and I’ve contemplated it myself before realising that we could probably do things better within our own set-up. Some teams run a ‘support hour’ after their morning stand-up. Our friends in the Green Room, Browser London do this and they inherited the idea from their friends at Clock. This hour involves non-sprint activities the obvious being support issues but also any other stuff that’s impeding the sprint team. The problem with this is that it’s too ridged. The assumption is that the hour can always be filled with productive means but an hour is an arbitrary value. It sounds like enough without sounding like too much. It bakes people into the habit of doing ‘support hour’ at the start of each day (a pretty demotivating start to every single working day), assumes that every issue can be handled acceptably within an hour and if it can’t the client then has to wait another 24 hours. And lets face it, as for the ad-hoc client request an hour is never going to get anywhere.