Monthly Archives: March 2010

The Cost of Hidden Work

I’ve been working with one of the teams here recently all of whom have been feeling that the pace at which they deliver features is slower than they would like. I’ve run a number of sessions in order to gather data about the work they’ve been doing and how it flows through their wall. During one of the sessions, we focussed on the types of work that they are asked to do of which support was noted as one flavour.
Image of the Team's wall showing support streamThe team currently structure their board around the ongoing need to service this support need, see an image of their current implementation left. One of the 5 developers within the team will work solely within the Support Stream seen at the bottom of their wall for an undetermined amount of time.
The support items are typically raised through our issue management application and usually carry an expectation with them that they will be worked on immediately irrespective of their size. The team has tried implementing an SLA around response times in respect of support items before but for one reason or another (discussion of which is outside the scope of this article), it has never really taken hold (We have in the sessions discussed Classes of Service details of which will be covered in a subsequent post.).
Back to the team’s opinion that they weren’t delivering as fast as they might like though; in our discussions I stated that I felt that part of the reason was that in undertaking the support items they were undertaking a lot of what was effectively hidden work. It was work that was also implicitly being prioritised above all the other items that had previously been agreed as highest priority in a prioritisation session.
We didn’t manage to reach a conclusion on what to do about the support stream though and so the conversation continued outside of the meeting. One of the Developers in the team noted what he saw to be the pros and cons of the support stream which with his permission, I’ve noted below:


  • less distraction to the rest of the team
  • less confusion who’s looking into what
  • faster responses
  • fixed amount of resources dedicated to support – support cannot slow up feature streams
  • 1 person dealing with each support request = less overhead in understanding the problem


  • support rota not evenly distributed amongst team members
  • faster responses = less pressure on business to ask for automated solutions
  • pre-sale enquiries don’t fit well, so would still cause distraction
  • 1 person dealing with each support request = issues are hidden from rest of the team

I then followed up with a rather lengthy response which is the reason this post has emerged:

My issue with support is this; support items are essentially features that are being requested. In that respect, they should be prioritised among all the other features. The fact that there is a specific stream for support suggests that they are automatically accepted as being higher priority than the other features in progress and that is certainly not the case. Furthermore in prioritising them above the other features those other features are affected.

I think that it is far more prudent to prioritise the work you are doing on a daily basis, as a team and include the support items in that prioritisation. In my opinion, it is not so important that the rest of the team are not distracted as per the first point in the pros section above and that instead what is important is that you are as a team working on the highest priority items. Only then will you ever work together as a team to establish a flow. In that, I recognise that there is absolutely value in disrupting the flow of another item to get a major bug fixed, as there is also value in understanding why you are dealing with a support request and in the case of the why, you will only ever understand that by having a discussion with the other members of the team. I would hope that once you understand why as a team, you can then incorporate any learning in to an improvement cycle on a far more regular basis than waiting for your next retrospective at which time the item may have either been forgotten in the larger context or not voted as the highest priority thing to be attended to.

To the points above though; I’ve already touched on the first point in the pros section and as for the second point, I think that a clear definition of the role of the person acting floating manner will clear this up. On the third and forth points in respect of faster responses; as I’ve touched upon above, this may well be the case in respect of the items that you now classify as support but the net effects are that the other items are slower to deliver, I don’t have any data to substantiate this claim but I will point you at Little’s Law which suggests that the number of items in process is closely related to the overall time taken to process those items. On the fifth point, this is in direct conflict with our ambition to deal with one of the biggest problems we face as a department, that a select few that know more about our software and systems than anyone else; as well as the received opinion that two heads are better than one.

In terms of the cons listed above, the first point I may not understand fully but if I do understand it, surely a weekly system of having a floating role that fulfils a number of duties (which we can define as a group but for example: Monitoring the support queue, leading the stand up in the morning in discussing the blockers, the support requests that have come in and discussion about the work that is in progress.) would give a fair split of the responsibilities. I think I agree with the second point made but I would add this, the “business” (which is a term we should not allow to propagate lest we fall deeper in to a them and us mentality) classifying a support item as a feature and having a conversation about its priority and how to achieve it as a team which is what I am proposing, would I hope lead to other solutions being suggested and indeed the emergence of those automated systems bit by bit. If as a team you recognise that you have a little longer to undertake the item, schedule among the other things that you are doing, deliver it in a timely manner but put the building blocks in place for something that you can extend as time goes by. I’m in agreement with the fourth point about pre-sales enquiries as are we all I think, as we’ve now included it in the activities that we map on the board. Pre-Sales is a first class activity that everybody should have visibility of and also, should be able to undertake.

How Has This Concluded?

Firstly, the support stream hasn’t been removed from the team’s wall (as yet). They do now a rota in place though that clearly shows who is acting in that capacity. Furthermore and most importantly in my opinion, they now do prioritise the work within the context of the other features and don’t necessarily respond immediately but at a time that is convenient. They’ve also stopped tracking support items specifically opting instead to consider them features which are sized thus give us more reliable data about lead and cycle times and again and importantly actual visibility of the capacity the team has to do work.