I have often been asked my opinions on teams that are not performing. Typically this is prompted by an observation of going through the motions on a Scrum ceremony that they have witnessed. I have seen the same situation a few times now so thought it worth sharing.
So consider this team:
They appear listless, little passion or focus. They have the necessary process and artefacts but more from a sense of obligation than because they are actually deriving any value from them. They probably get together as a whole team to discuss stuff right at the beginning of the sprint and then drift off into smaller groups at the start of sprint ending with a minor panic in the last couple of days leaving sprints incomplete. Standups are largely pointless, mumbled status updates to the Scrum Master. They will often respond with excuses of interdependencies or lack of understanding. Their “Definition of Done” is a little hazy and regularly compromised to get things though at the end of a sprint and for the same reason, smaller pieces of low priority work often get put into sprints to enable the team to take some easy wins – to keep THEM happy.
It is easy to point the finger at the team, kick them a little bit, maybe even shout and mention things like performance reviews, objectives and the like, but for a team to have gotten into this mess there must be something systemically wrong and pep talks will have short term benefits at best.
So the Scrum Master is at fault, well maybe. Typically I find the fault is in the system the team is in and either the Scrum Master is part of that system or has given up fighting. Watch the Scrum Master. If they are busy directing the team flow like a policeman at a busy junction, having quiet chats with the Product Owner and separately with Architects and Project Managers then yes, the Scrum Master is part of the system that is killing the team. If however – as I have often mentioned, the Scrum Master appears like the rest of the team, quiet, reluctant, weary and at a loss, then you probably have a respectable Scrum Master that isn’t sufficiently powerful to break the system and therefore is as beaten as the team.
A first starting point is to look at team size, most of the situations I have seen have been compounded by over sized teams. I know many people in the Agile Coaching industry that would argue that you can have teams up to 11 and yes you can get things to work with larger teams, but you need the system to be working well first; and many of the issues that affect smaller teams have a more significant impact on larger ones.
Agile is fundamentally about people, it is light on process by design, and process enables people to be directed forcibly. The Agile approach depends on self direction and self direction thrives on motivation. Fail to motivate the team and they will become despondent and without the structure and direction in a waterfall model, they will split, drift and performance will be a fraction of what is possible.
Motivation in an Agile context typically stems from empowerment and an appreciation of what they are working on, not just realisation of the final product but also a direct understanding of their element of it.
Given this there are some demotivational factors to look out for:
Component teams – delivery teams that are working on technological slices of the application have a much harder time to appreciate the point of their work, and therefore their impact on the value. Because it is harder to see the final solution it is also much harder for the team to drive out an MVP, component teams often gold plate because they struggle to be able to identify which features are the most critical.
Specialists – A team of specialists that are able to completely break up the work will find themselves operating in increased isolation. The handoffs between team members will start to become increasingly formal in an attempt to ensure responsibility. What this means is each team member looks out for themselves to ensure that when something goes wrong they are able to point the finger elsewhere. The team will start working when they act as a team, and that can be helped though cross functional delivery.
Knowledge of the users – have the team, not a management representative of the team, but the team themselves, ever actually met and talked to the actual users of the system? People will probably have spoken to the team about the users, may even have involved the team in creating personas but there is something very powerful about actually meeting them. Seeing the whites of the eyes of the people you are building things for. It is about consequence, about responsibility. It is harder to cut corners and deliver substandard product for someone you have actually met and have a relationship with.
Culture of Management – This is the most subtle and pervasive of the issues, and also the one that typically gets worse as performance issues grow creating a vicious circle. A poor team typically attracts more management attention, who will act to direct and control the flow and definition of work. What the team needs is empowerment, freedom to own their own process. Did they write their own definition of done (and not have it “rephrased” by someone senior)? Have they chosen their own tracking and reporting templates?
A really important piece will be the decision makers. These decision makers need to be in the team and making decisions with the team – in the presence of their team members. This makes their decisions team decisions, as opposed to decisions made on behalf of the team. It is an important but subtle distinction. Project Managers and Architects are the two roles that this usually applies to.
In short if you have a team that appears to be drifting and disinterested then:
- Reduce the team size as much as possible – facilitate the team to split maybe
- Empower the team – stop making decisions outside the team on their behalf
- Connect the team with the users
- Enable the team to own their own process
- Give the team a slice of the system where they can own the definition, delivery and deployment of something of value
philagiledesign 