May 8, 2017 // By Paul Grizzaffi
When I was taking courses for my computer science degree, I recall many classes in which some of our assignments were team assignments. In some cases, the instructor assigned the teams; in others, students could form their own teams. To my recollection, the instructors never said things like “Paul, you build the admin component; Amy, you build the payment component”. The teams were told what the assignment was, something to the effect of, “each team is responsible for creating an account management program”. At that point is was up to the team to decide how they would build the system and who would be responsible for which activities. We were responsible for our team and its output; we had to self-organize.
I had similar experiences in high school as well. In fact, most people that I know had some kind of group project somewhere during their education. In most cases, these group projects required the teams to self-organize, to decide how they would work to complete an assignment.
When did we lose the capacity to that? Or perhaps the question really is “when did our leadership forget that we are capable of self-organization?”
It seems that somewhere along the way, many of us have decided that we needed to be told what to work on next or that we need someone to assign tasks to us, even in a Scrum setting. I frequently see Product Owners and ScrumMasters assigning work to Scrum team members. Often, neither the team members nor the team as a whole pushes back on that. Why not? Is it because most of us crave a traditional, command and control management structure where we are told what to do and when to do it? Or is it that the leadership structure in place reinforces that behavior in us?
Scrum teams in particular are expected to self-organize around the work in the current sprint. That doesn’t mean they can be negligent or irresponsible with this expectation, but generally the team knows for a particular task who is a good candidate to work on which piece, etc.
When leaders assigning work in a Scrum environment, it reminds me of a conversation that I had many years ago:
Me: Mike, I really want Chris to work directly on my team. He has more Java knowledge the most of us.
Mike: What you mean is that you want someone with Java expertise to work on your team.
Me: What?
I knew that Chris was the only person on Mike’s team with “Java expertise”. Mike knew that Chris was the only person on his team with “Java expertise”. Why was he putting me through this pointless conversation?
Because it wasn’t pointless. Perhaps it was overkill for that particular situation, but it was a good lesson to me. I learned that sometimes you don’t need a specific person to perform a task; you need someone with particular skills or talents.
Getting back to Scrum and self-organization, I think its fine for a Product Owner to request a certain person; I think it’s better if the Product Owner says, “it needs to be finished by Sprint X”. I also think its fine for a ScrumMaster to ask, “will you finish it by the end of the Sprint X?” People in these roles should not assign work to individual team members nor should they require that certain individuals perform certain tasks; that’s the team’s responsibility. The team needs to be able to maneuver through the work to be most effective. Over time, this helps them gel as a team and helps increase their effectiveness.
Perhaps, sometimes, it’s OK to act like a “college kid”.
Paul Grizzaffi is a Principal Consultant at Magenic. This post was republished from his personal blog and can be found here.