So you’re in a team, you’re trying to get on with your day to day work and you’re constantly being disturbed.
Disturbed by issues, queries, concerns, ideas – you know just that stuff development teams have to deal with .
Now it’s common that if you’re the most experienced member of the team – you might become known as the ‘Go to guy”. It kinda makes sense, you’ve been around the longest so you’re most familiar with the issue or requests, and since you know where to look and how to resolve things faster than your peers – it’s just makes sense that you deal with it.
Mm-mm,not if you’re a SCRUM team it’s not.
In my humble experience I’ve seen the “Go to guy” mindset in new SCRUM (& some old!) teams & I can tell you, on my many levels it has many draw-backs.
Let’s check those out…..
Reduced SCRUM Capability, Whilst it naturally feels good to be respected & trusted – you know, to feel like the business come to you because you get things sorted fast – how long will it take before your day to day work , the stories you are aiming to complete for the sprint is seriously impacted because of support issues? If one team member is constantly disturbed with support issues then that effects the capability of the SCRUM team. SCRUM capability is all about how much value , as a team you can bring. Now if one team member is overloaded with support issues, that effects the teams capability to deliver.
Key man risk, when that “go to guy” is out of office and an issue surfaces that only “he” deals with – it might take twice as long for other developers to pull together to decipher the code, documentation or what ever means of knowledge available to figure out what needs to be done. SCRUM teams need to actively share knowledge to develop a healthy team ability to deal with requests.
Reduced autonomy, having a “go to guy” for issues in support cases also means that when new stories are reviewed, not all developers can pick up and complete that piece of work. SCRUM is all about creating an autonomous team, so that each team member has the ability to complete stories without any dependencies to complete that work – or as few possible..
Deflated morale, maybe the most significant point. When one individual is loaded, there is an uneven distribution of responsibility among the a SCRUM (or any !) team. The ” Why do I have to do everything around here” syndrome will surface. A deflated morale not only effects an individuals performance but can also impact the entire teams morale. Low morale means reduced team productivity.
So what can we do?
When I join new SCRUM teams & see the “Go to guy” – I usually introduce something called “Exposure”.
You can now wipe that grin off of your face, one does not need to remove any attire. Ahem.
Here’s how ‘Exposure’ works.
Every morning during the stand up, a different developer is ‘Exposed’.
You can use a rota or have team members volunteer but whoever is ‘Exposed’ that is the individual responsible for dealing with all queries & requests from the business for that day.
I know what you’re thinking.
“What happens when a developer picks up an issue that he/she has no idea about?”
That’s the opportunity to learn.
That exposed developer will find the existing ‘expert’ & understand what needs to be done. This is knowledge sharing.
“Yes but what happens to ‘that’ developer’s productivity levels, he’s being pulled away from his work and so we are losing velocity ?”
In the short run, yes. But what happens when an issue arises that only the “go to guy” (who is out of the office) can answer? The team now lose significant productivity trying to figure out what needs to be done & even worse, it cant be figured out & must be resolved when the “go to guy” comes back. Also, when the team knowledge share grows that will increase productivity – increased knowledge allows team members to pick up work which they couldn’t before: for support and sprint work.
” I am a developer & I think it makes senses that I just answer the query quickly to help the business – I can’t say no to a senior business guy”
If the CEO approaches you needing critical information there and then – no problem, grab the person who is exposed and sit down with that individual whilst you explain to the CEO what needs to be done. A certain level of expedience exists but you need to proactively do what you can to adhere to this practice to grow knowledge among the team.
For a well balanced SCRUM team to take form, an investment needs to be made.
An investment in learning from one another & one way of doing that is through the ‘Exposure’ rule.
Try it today & remind one another that the benefits of reduced key man risk, increased autonomy & an even spread of work responsibility can only be a good thing!