Agile Intelligence: Leveraging Scrum for non-IT Services

My previous post on Scrum jotted down some of the key elements and thoughts for using this into the software development projects. While looking back and reflecting the same for non-IT services, the basics remain same at large. The simplicity of Scrum makes it extensible to a different area of work keeping its core same, and making necessary changes to it implementation the way new service would require. Again, I must emphasize that the service team or group considering to adopt Scrum should not be asked to change themselves nor their way of working. The implementation of Scrum needs tailoring instead, if so needed.

The core three questions of Scrum would stay same while implementing it for non-IT services as well:
1. What have you accomplished since the last scrum?
2. What are you going to accomplish till the next scrum?
3. What are the issues are you having on your way?

However, the response to these questions will vary here. As it is evident, that we are talking about the service, not really a project. So the spicy details of what's getting cooked should not be expected here. On a normal day, a team member is expected to respond something like this -
1. I have completed 140 transactions, all that were assigned to me.
2. I will complete all assigned transactions, upto 160 transactions in a given day.
3. Nothing to be mentioned.

In a room of 20, this set may be repeated multiple times, by multiple individuals, in a way that would question the relevance of the questions. However, the participation of all is a necessity here, inclusivity is the key to the excellence. So, the same answers should be allowed to get repeated. While the repeatation is underway, the scrum master should train his/her ears to pickup the relatively proactive responses, something like this one -
1. I have completed 140 transactions, all that were assigned to me. I had some free time, about an hour, and spent that in updating the review checklist.
2. I will complete all assigned transactions, upto 160 transactions in a given day, and will use my free time to complete the checklist updates.
3. The checklist updates are infrequent these days, can it be regularized?

Once such responses come out, the role of the scrum master needs to go beyond the point of asking three questions. The scrum master needs to encourage such activities as stated in #1, needs to push the work target stated in #2, if appropriate, and take cues of innovation ideas as mentioned in #3. A little more risky bet would be to ask for innovation ideas at the end of the scrum. All through, the scrum master should be patient and careful about not doling out any unrealistic plan, specifically, for #2 and #3. In a service oriented structure, the number of transactions per day cannot grow everyday, it would saturate to a level and any further upward push without planning and enablement would impair the overall service delivery structure. Similarly, all innovation ideas should not be converted to an improvement, it would not be feasible either. Each ideas need to be evaluated with a structured review, and upon qualification, should be implemented through a plan.

Finally, how much time should be devoted for scrum? For a mature process, it should not be more than 15 minutes per day. It's important to have it everyday with varying duration. For a stable situation, it should not be more than 15 minutes, but during any change implementation, more time needs to be allocated for sufficient discussion.