So, how do you point out when you feel the team, or part of the team isn’t on the right track? How can you test whether you’re right to point these things out?
If you take a look at the Dirty Dozen, you can quickly identify whether something is affecting the team and, more importantly, whether there’s a clear pathway to resolving it.
The Dirty Dozen
The Dirty Dozen are the most common preconditions of people ahead of a human error, so can be seen as the root cause for many accidents, incidents and errors that make it from the team into the finished product:
- Lack of effective communication
- Lack of resources
- Lack of teamwork
- Lack of awareness
- Lack of knowledge
- Lack of assertiveness (often ownership)
- Accepting the Norms (the “we’ve always done it that way…” effect)
With these ingrained in the mindset of the whole team, it’s possible to objectively highlight performance issues as a group without starting a witch hunt. When you want to highlight that you feel the definition of done has been watered down and the quality of work is dropping “we are becoming complacent” sends a clear message to everyone in the team about what questions need to be asked and what needs to be done much faster than “it isn’t good enough”.
1. Lack of effective communication
Awareness that everything, including no communication, is a form of communication. Find opportunities for applying communication/find means of communicating more effectively
Combat external factors causing distraction/draw focus
3. Lack of resources
Find ways to alleviate stress/reduce complexity
Reconvene/reshuffle/take regular breaks/cycle feedback more frequently
6. Lack of teamwork
Redefine ways of working/identify areas of improvement
Divert pressure/re-establish pull
8. Lack of awareness
9. Lack of knowledge
11. Lack of assertiveness
Establish roles and responsibilities/request direction. “If nobody is responsible for X, we’re all responsible”
12. Accepting the Norms (The “we’ve always done it that way…” effect)
Contrast with other teams/review processes and framework
Note that each of the dirty dozen has more than one positive response that will deliver benefits to everyone (there are many more unlisted, see here.
There’s less room for debate over whether something’s working optimally when the outcome is an improvement or a confidence check, so highlighting a risk in this format allows for matters to be tackled immediately and with buy-in from the whole team.
As mentioned, these techniques come from century-old, battle-hardened industries. It takes time to get to a place where, for example, a junior in a team can walk up to an architect or a more experienced software engineer and say “You look tired, do you want to take a break?” or “You’re doing that wrong, are you aware of….” but I absolutely believe it’s the way things will go, if software engineering even closely follows Mechanical, Biomedical or any other mission-critical engineering trade.
Ideally, this means bringing it into Software Engineering at a college level, if not sooner, but there are things that can be done to bring it into your current teams too.
Agile’s “people over processes” value is the beginning of this. Focus on excellence within your teams, drive out issues as a team and keep in mind how interactions between individuals are the points of failure (and improvement) not the individuals themselves.
“When a flower doesn’t bloom, you fix the environment in which it grows, not the flower…” Alexander Den Heijer.