In the last couple of posts, Dealing with naysayers and Big projects and Epic tasking, I focused on the team members that seem to love complaining. Unfortunately, this isn't completely fair to those that have bought-in to the process and are just trying to meet their commitments. For them, let's turn the discussion to a type of impediment that can make any process or committed team fail... Managers... or at least some of them. Again, this may not be fair, but let's explore this a little more and I think you'll get my point.
For the sake of discussion, let's just assume everyone is bought into the process. This buy-in assumes that everyone knows that one of the key process tenets in Scrum is that once the Team has made a commitment, they need to be left to meet that commitment. Unfortunately, managers are vulnerable to acute cases of amnesia which often manifests shortly after the Sprint Planning session. Whether or not this is truly a medical condition, it can have detrimental effects on the team's ability to stay focuses and maintain momentum. Treatments for this affliction can require a delicate touch and have mixed results, but before we discuss treatments let's look at some of the symptoms and explain how they can affect the Team.
Multi-Tasking, Context Switching, Task Switching
Some would say the ability to multi-task is a crucial skill for any IT professional. The problem is... us humans just don't do it very well, although many of us think we can. Do a little Googling and read what the productivity experts have to say. Their agreement on the matter is almost unanimous... we often become less productive when we try to multi-task. Managers need to be aware of this more than anyone since they're the first line of defence. Most teams will have some ability to absorb unplanned tasking; which is often represented in the team's productivity rate; but managers need to make sure people don't take advantage of this "potential" capacity.
Here's the main problem... when someone is working on a task and they're interrupted, it takes them considerably more time to regain the same momentum they had before they were interrupted. This includes drive-by questions, phone calls, email, visits from the manager, and meetings, meetings, meetings. Depending on the task, this can be really costly if the developer has to regain complex or nuanced information before they can restart their work. Some interruptions are inevitable, but constant interruptions can put the team at risk of not meeting their "real" commitments. The manager needs to be aware of the amount of context switching occurring in the team; especially when it's their fault; and work with the Scrum Master to deal with excessive interruptions. Some might say the interruptions need to be "managed", but that's just me trying to be cheeky.
One reason this might be the managers fault, is based on the typical manager/employee dynamics surrounding delegation. This is fine to a point, but if the managers aren't careful they can delegate the team right into failure. We can assume this isn't conscious neglect. Maybe they're naively oblivious to the damage left in the wake of them trying to be "good" managers... What?... It could happen!... At some point, managers; and other supporting staff; need to become self-sufficient and carry the load without the Team.
Let's just add this "one" more "little" thing...
If your Sprints are the average three week length, there's a tendency to think that with so much time we can add just "one" more "little" thing. This is another famous manager line, but it's a slippery-slope. If the manager wasn't afflicted with 'the illness', they would realize they're asking for trouble; or at the very least, adding risk. The reality is, there are very few "little" things that can be added without having a larger knock-on effect. New stuff; whatever the size; needs to be designed, coded, integrated, tested, documented, etc... Before you know it, the dev has lost valuable time on something that wasn't originally a commitment. As a rule, there should be no new or altered commitments once the Sprint has started.
Communicate the problem - The best thing to do is have a team meeting with your manager(s) and tell him/her what the concerns are. The Retrospective Meeting is a great place to start this discussion. Depending on your relationship with your manager this may or may work, and you may need a more subtle approach. In this case, try reducing your teams productivity rate and subsequently reduce your commitment at the next Planning session. If you keep doing this, your manager is bound to ask what is going on. This will give you another opportunity to articulate how interruptions are endangering your team's ability to meet their commitments. To be effective in making your point, you'll need to have some evidence. As they happen, try adding unplanned/uncommitted tasks to whatever tracking system you're using. This will give you a valuable point of reference and may also reflect on the burn-down chart which can help reinforce your point.
Learn to say "No" without saying "No" - This can be hard in some shops, but may be necessary to prevent the teams failure. Since "No" can be received negatively, try approaching this from another angle. This is a bit Freudian, but it works.
- Start by suggesting the new task be a "priority" for the next Sprint. This sounds like "Yes" but implies a "No" for the current Sprint without saying it
- Say "Yes" with the Proviso the manager identify what "commitment" should not be done as a result of adding the new task
Batch your interruptions - As valuable resources, it makes sense that some questions can only be answered by the Team. If you're suffering from frequent drive-by questions. Ask your manager to save them up and ask more questions with fewer interruptions. Maybe he/she can agree to meet the team once a day or every couple days to have a time-boxed Q/A session. For this, I recommend following stand-up rules so things don't take too long.
Let it fail - No one likes to fail, and I'm not suggesting sabotage. With that said, there's no sense fighting the inevitable. Everyone has to be made aware of the consequence of not keeping the larger commitment to the team. Some Sprints can require extra-ordinary effort, but they can't be planned with the expectation of Herculean efforts on the part of the development team. That's a recipe for disaster.
This isn't meant to represent a complete list of treatment options, but may give you a few ideas on how to handle this. Whatever you do, try and remember that everyone has their own perspective, and odds are good they're busy as well. In most cases, the problem(s) comes down to communication, or the lack of it. Start with the direct approach, and resort to Freudian manipulation only if you need to.
I picked on managers a little bit, but the truth is, they're a valuable part of any team being successful. With that said, we can all slip into bad habits and sometimes need to do a little Freudian introspection to reflect on our own behavior. For full disclosure... I've done my share of managing, and I've certainly been guilty of doing things mentioned above. Like anything else, the Team and their manager(s) need to find a balance to ensure the larger business objectives can be met without killing your team in the process (pun intended).
Before wrapping things up, there is one more thing... What about the Scrum Master? ... Great question!... Since they facilitate every daily Scrum and should be the first to hear about impediments, they should be well aware of what kind of stress the Team is under. Consequently, they should be the first one to tell the manager when its time to back-away and start helping keep outside interruptions from the Team. So get to work you Scrum Masters...