Bob's Blog
Bob is a prolific blogger who simply enjoys sharing his experiences with colleagues in the Agile Community. Topics revolve around Scrum, XP, Kanban, Project Management, Business Analysis, Testing, Leadership and General Musings.
Check back often as we've always got something to say...
Viewing entries tagged
high-performance teams
I read this article from Roman Pichler that took the perspective of a Product Owner working with an underperforming development team and trying to turn things around. While it’s a good article, it inspired me to look at other reasons that a team might not be performing well. Things outside of the team.
So, instead of the Product Owner looking at and trying to improve the team, what if they changed their focus to underperforming influences that surround the team?
About 10 years ago I was an agile coach at a client organization and I was also acting as a Scrum Master for two teams.
I remember a director coming up to me and asking me, as the Scrum Master of a team with folks who reported to him, how was a specific engineer performing. He explained that he had concerns that the engineer wasn’t pulling his weight and he wanted some specifics to confront him with.
I remember my reaction viscerally to this day…
I got a sick feeling in the pit of my stomach;
I even felt a little weakness in my knees;
I struggled with what to say, knowing that the engineer he was talking about was indeed struggling;
I didn’t know if this was part of my role as a Scrum Master or not;
I wondered how he would take it if I declined to give him feedback;
I worried about the impact my feedback would have on the engineer…
It was a horrible experience because I wasn’t sure what to do. If I gave him the feedback, it would certainly compromise my role within the team. I guessed that it would get out and that I’d never really be trusted again.
AND, I was a part of the Scrum Team, wasn’t I? It would be like becoming a “snitch”. And nobody likes a snitch.
But if I didn’t give him the feedback, would it put me at risk?
In the end, I respectfully declined. I said that he’d have to observe the team in our sprint to sort out how everyone was performing. To my surprise, he accepted that reply. But I left feeling incredibly vulnerable and physically shaking.
My first piece of advice is this:
DON’T DO IT!!!
Probably the worst possible setup for “team” is spreading them around the country or the world or the universe and expecting them to behave and deliver like a close, cohesive team.
My second bit of advice for those of you that blame it on “Management” and say you don’t have any say in the matter…is:
WRONG, YOU HAVE LOTS TO SAY IN SUSTAINING DISTRIBUTED TEAMS OR CREATING ANOTHER STRATEGY!!!
I hear this situation (excuse) all of the time. An organization has inherited distributed teams yet also wants to move to more agile approaches. They understand that these teams can be less than optimal, but are reluctant to do anything about it. That is but complain about it.
I recently read an article entitled Engineering Culture and Distributed Agile Teams that was published in InfoQ. In it, the editor called out the following strong themes or takeaways:
While the article is titled and implies a focus on culture, it really focuses more on technical tactics or tooling as the key to distributed teams.
