We recently looked at our task board and it looked something like this:
It was pretty easy to see where the bottleneck was in this process – a number of items had been assigned to the SM/PO (in the UAT column) which were awaiting new requirements and discussions with the client to clear these through. They simply hadn’t yet had time to contact the client in regard to these issues.
So the question we asked ourselves was ‘why was the Scrum Master and PO the bottleneck?’ The dev to PO/SM ratio was small, in any normal situation the PO and SM would have ample time to do everything necessary. Were they taking on too much?
(At this point it might be worth mentioning that I am the Scrum Master on this team!)
We discussed the issues and felt that this was a reflection of some wider issues of how I and the PO were working. The first steps were to record the issue so that we could analyse what in fact we were doing during our working day, so we decided to write our own timesheets for a few days to enable us to review the time we were taking on activities. These were the results of my timesheet:
|8.30||Prioritise UAT issues|
|9.00||Updating Support tasks on board and CRM/burndown|
|9.30||Reviewing invoice figures|
|10.00||Discussion with Directors|
|11.00||Chasing UAT feedback from client|
|12.00||Clearing to-do-list items (impediments/queries)|
|13.30||Clearing to-do-list items (impediments/queries)|
|14.00||UAT queries with client|
|14.30||Live site issue – team and client discussions|
|15.00||Directors around the board/updating stats|
|15.30||A3 thinking – SM and PO discussing how to improve our working efficiency|
|16.30||Filling out timesheet|
|17.00||Call with client|
|17.30||Reviewing CRM (our internal accounts system)|
We analysed this and found a number of steps that could be taken:
- The team could take on more responsibility for talking to the client – reviewing UAT feedback with the client as a team. We actually got the client on site to work along-side the team. This worked a treat.
- Triaging UAT feedback – we identified that I was spending a lot of my time replicating bugs raised by the client. The tester in our team had capacity to do this triaging and the only real reason for me doing it myself was a hark-back to the days before we did scrum. Our tester was happy to take this on.
- Treating email differently – One thing I found whilst doing this task was that I was being constantly interrupted by my email. Although I was aware that multi-tasking isn’t effective, and that we should avoid it, I wasn’t pro-actively doing this. Emails would pop-up on my screen and I would want to tackle it as soon as possible. Instead of moving through from one email to another. So being conscious of this issue means that I can make sure I close down one email at a time and tell myself off if I find a number of open emails on my desktop at one time.
Now I wouldn’t want you to think this timesheet was a completely accurate representation of what I actually participated in. As a Scrum Master it is very hard to time-box tasks, most of the day is filled with conversations and team interactions and there is nothing wrong in this. But what I did find was that the task of having to write down my activities and actually allocating time against this allowed me to really think about how I was working.
I would suggest that this is a very good tool for anybody looking to improve how they are working on a day-to-day basis. It allows you to focus the mind and importantly increases your awareness of the issues. I will certainly be carrying out this exercise again once we have implemented these changes. My aim is to know that I have a decent amount of time each day/week to be able to review our working practices and make improvement.