Team Theory meets Agile/Scrum Practice
Many enterprise developers seem to have a deep curiosity about how psychology impacts behavior in organizations. I have written on this blog before about an Organizational Behavior class I took recently as part of the DePaul University MBA program. In addition to common decision-making biases we also covered team dynamics in that class, which sparked a lot of interest among my colleagues.
It is striking how the empirical research about teams conducted by experts like J. Richard Hackman of Harvard lines up with the Agile practices developed by practitioners like Martin Fowler. It is always refreshing when academic theory and real-world practice converge on a topic. In this post I will share some of the highlights from the research about effective teams and how you can apply those insights to your Agile/Scrum practices.
Managing vs. Leading
Often the terms are used interchangeably but they are actually very different sets of skills that should be performed by separate people. In general, team management is all about reducing inefficiencies on a team while team leadership is about setting the team up for success and giving the team clear objectives. In Agile/Scrum the team members, scrum master and possibly a project manager share the load of managing the team. The product owner or someone from management typically fulfills the leadership role.
For Existing Teams, Reduce Process Losses
If you accept the premise: Actual Productivity = Team Potential – Process Losses + Synergistic Gain then there are three possible ways to improve the performance of a team. Unless you get to handpick the team (rarely an option) then team potential is largely out of your control. And, according to research, the only thing that creates synergistic gain is stability over time; the longer a team works together the better they get.
Thus for an existing team, reducing process losses is the only way to improve productivity immediately. Luckily there are many process gains to be had through a few simple adjustments, many of which flow naturally from recommended Agile/Scrum practices.
Three Quick Hits for Team Managers
- Increase transparency – Comments like, “Stan’s code is terrible, I’m certainly not going to fix his bugs for him.” (sucker effects) or “I don’t feel like I’m doing much on this project.” (reduced sense of self-efficacy) are indications your team suffers from Insufficient Motivation. Research suggests that much of this motivation problem can be alleviated with transparency. Are you holding regular sprint retrospectives? Are they frank and honest discussions?
- Ensure consequences are clear – “You break the build, you fix it” is a common consequence of undesirable behavior on many development teams. Research suggests consequences are key to good team performance. Does your team have clear consequences? If not, a written team contract that lays out clear consequences for undesirable team behavior will help. Bear in mind that extreme consequences like removal from the team should also be on the table.
- Keep members playing to their strengths – A rich history of Social Facilitation research has shown that in front of an audience if you are good at something then performance is enhanced but if you are bad at it performance is degraded. Pair programming, stand up meetings, and end-of-sprint review and retrospective sessions all provide an audience. Thus, members of the team should be reminded to only take on tasks in which they are confident of their abilities.
Four Things Good Team Leaders Must Do
Often the responsibility for leading the team falls on the Product Owner and possibly a project sponsor or other executive. The work mainly consists of putting success-inducing conditions in place and then working to keep those conditions stable. According to Hackman, the leader must do four things:
- Provide a clear, compelling objective for the team – The desired end goal not how to get there. Martin Fowler mentions this in his New Methodology essay in the Business Leadership section. In addition to a clear objective it is important to keep it challenging; there should be no guarantee of success. If it is an easy task, then a group of individuals can do it without having to unleash the creativity of a team.
- Create a structure that facilitates teamwork – A small team (< 10 members) with stable membership is best since process losses grow exponentially with each additional team member. Hackman suggests the ideal team size is six members.
- Span boundaries for the team – Make sure the organization supports team excellence more than individual excellence and provides resources needed by the team. Depending on the resources needed, it is usually a combination of the product owner, scrum master and project manager fulfilling this boundary spanning role.
- Provide expert coaching – Motivate at the beginning of a project, remind the team of the objective in the middle and help the team learn how to do better at the end. Sprint planning, stand-up and review/retrospective meetings all provide great forums for this kind of coaching by all members of the team.
What do you Think?
Whether you are a product owner, scrum master, project manager or developer I hope you have found some useful bits of knowledge in this post. All of us at InRule are always trying to figure out how to make our project teams function better so if you have insights, books or articles you think would help please comment on this post!