First, to be clear, I am not an expert on Scrum, Agile, Managemnt, or anything like that. I am however passionate about web development, furthering my skills, and developing teams into (pardon the cliché) well oiled machines.
I've been thinking about writing about this for some time now. I've been putting off, as I really wanted to write a post about how to fix it. That seems to be out of reach for the time being, so I decided to write about recognizing dysfunction in a team. I have to believe that we're not the only team that has these issues. I have a few ideas that might help, but to be clear, these has not yet been proven to me.
To some degree, I believe all teams are dysfunctional. Or, at the very least, they are at risk of becoming dysfunctional at any moment. In his book The 5 Dysfunctions of a Team, Patrick Lencioni identifies these dysfunctions as:
- Absence of Trust
- Fear of Conflict
- Lack of Commitment
- Avoidance of Accountability
- Inattention to Results
Currently, I work on a Development team that has spent the last 2 years attempting to introduce Scrum methodologies. The 5 Core Principals of Scrum should be able to help us:
We have a number of challenges relating to each dysfunction, and each dysfunction compounds itself, as well as the effects of the other dysfunctions.
Absence of Trust
A team doesn't need to trust each other the same way friends or family do, at least not on a personal level. No one needs to be friends, although it can help, but there needs to be a certain comfort level between team members. This would allow everyone to admit mistakes and accept or offer criticism. Instead, everyone seems to have their backs up.
I feel that some of this lack of trust also stems from a lack of faith in ability. Different members of the team have different skill levels. We struggle with team members furthering their knowledge and abilities, and as a result, we have team members stuck on very old ways of doing things. In some cases it's not from a lack of trying, but it's incredibly hard to change old habits. Especially if a person is hard to convince that "the new way" is the better way. This makes it very difficult for other team members to advance their skills, and hold the team back in terms of both productivity, and technology.
Fear of Conflict
Due to this lack of trust, the team is unable to engage in healthy, passionate discussions about key issues. Like a said, a number of developers seem to be behind, and a few are constantly trying to advance their skills. But neither group will engage the other in regards to skills or concepts. The group that is comfortable doing things "they way they've always been done" seem afraid to ask about the new concepts, and put little effort into understanding them. Those who are advancing tried for a period of time to bring the others up to speed, but were quickly frustrated with what seemed like reluctance. Instead of open conversation, we have whispered discussions, and backhanded remarks. Nobody openly airs their opinions, and the result is often an inferior decision.
Lack of Commitment
Our lack of conflict means it's often difficult for us to commit to any one idea or decision. This means we have an environment of ambiguity and confusion. We end up with a lack of direction and commitment, which makes many members of the team, especially those trying to really advance, very disgruntled. It's very hard to commit to something personally, if the team isn't all aligned. You have to be careful not to confuse someones lack of commitment, with lack of dedication to their job. Someone can still take a great deal of pride in their work, while being unfocused or uncommitted to the team.
Avoidance of Accountability
This goes hand-in-hand with the the previous dysfunctions. When teams aren't committed to a clear plan, even the most dedicated team members won't call out others on behaviours that are counter productive to the team goals. This is partly because they are unclear on what those goals are, but it's also because they fear the conflict, don't trust that they will be heard or listened to, and really have no commitment to whatever the goals are. They almost want to see someone fail.
This, again, crosses between the divide we have of developers trying to advance, and those who are seemingly unable to do so. In some cases it's accurate, but it seems that if one group has something go wrong, it's the fault of the other group. From the "advanced" guys, "it must be something So-and-so did". From the "less advanced" guys, "So-and-so didn't explain that right". Rarely does anyone say "I made a mistake".
Inattention to Results
When individuals aren't being held accountable, team members naturally put their own needs before ahead of those of the team. It may be their own career, special recognition, or even just their ego. This is, again, compounded by the lack of focus of the team. If any of the 4 previous dysfunctions are present, you will have less than adequate results, and ultimately the business suffers.
Where Scrum Should Help
As I mentioned, I am not an expert, but this is how I see it. Consider the 5 principals of Scrum as they relate to the dysfunctions:
Each principal could fix the corresponding dysfunction. I believe that in order for Scrum, or any other method, to work at all, it starts at the top. Starting with Focus and working backwards, I think we can see pretty clearly where Scrum can play an important role, in principal if nothing else.
The focus really needs to come from "the top", the Management. Recently our small team worked on 2 major projects. Both of these were complete rewrites of 2 important systems. One, was a CMS for a magazine we publish, and the other was actually 2 projects in itself. Initially it was supposed to be a rewrite of our subscriber management system. Managing audited magazine subscriptions is fairly challenging, and we wanted to have one platform to manage all subscriptions across 2 magazines, 6 websites, and about 50 newsletters. This system then also became a rewrite of our newsletter system. So, a lot happening. For these projects, we also moved to a new application framework, and chose to adopt more modern and conventional programming practices.
The first part of this process really involved some R&D. We needed to understand the new technologies we were using. However, pressure from management to produce something they could see, caused us to jump right into coding. Personally, I'm ok with this, I like to learn by doing. The real problem came was when they decided they wanted us to work on all these big things at once. This meant, not only was the team unfocused on projects, but individuals were also unfocused on what they themselves were working on. The result was that the projects all limped out into production around the same time, with a lot of bugs and defects. Throughout the process, the team explained to management that we needed to focus on one project until completion. Then move on to the next. The result would have been far superior. This was not responded to well, we were basically told "get it done".
This type of response makes it very difficult to be open with management. The team members all seemed to feel as though they weren't being heard. It started a cycle of shutdown for us.
No one being open with management, translated to a lack of openness with each other, which means all those things I mentioned above were happening all at once. I can't pinpoint the exact time our team became totally dysfunctional, but we did. We still are. No one has trust in, or respect for, each other. There are no constructive conflicts, which means no resolutions. We are still very much a team divided.
As I said, I don't have proven solutions. I have only ideas and theories. Sorry.
First, managers and stakeholders need expectations changed. At least that's the case in the company I currently work for. The business spent years in a waterfall programming environment, and many people still have the expectation that things work a certain way.
Managers need to allow the team to focus on the projects one at a time. Of course, things come up that need immediate attention, and they need to be dealt with, but generally speaking, one project at a time. The team needs tangible group goals. Individuals also need goals and to be rewarded for achieving them.
Sometimes, you may need to force clarity and closure. At the end of each meeting it could be helpful to review the commitments made by both the team, and individuals, to ensure everyone is aligned. It's important to make sure all team members are committed before moving on. Commitment doesn't mean they have to agree, but they do need to understand.
Conflict and debate needs to be encouraged. Demanded, really. It needs to be realized that conflict is required to have productive meetings. Upfront conflict, rather than underground discussions, would lead to greater success. There can be ground rules for conflict if needed, but you need to find what works for your team. Each team member has their own natural conflict styles, and these should also be openly discussed so that everyone has the same expectations of how discussions might occur.
If you're able to achieve these things, you can start working on the 'first' dysfunction: Absense of Trust. This is actually where each of us as individuals needs to step up and work on things a bit. Try to take some time to identify your own strengths and weaknesses. Learn to accept that another team member might be more skilled in a particular area than you. These strengths and weaknesses should then be openly discussed amongst the team. This is hard. This means being vulnerable. But that vulnerabilty is what allows team members to develope trust and help each other grow as developers.
Finally, difficult issues need to be confronted. Goals and behaviours need to be explicitly communicated. Performance versus goals and standards, should be regularly discussed. As hard as it is to do, sometimes people just don't fit what is needed. It's important to take a hard look at the needs of the business, and which individual fills those needs. Having inadequate skills holds the team back form producing the best possible product. At one point, I looked at all the tasks our team had in a Sprint, and I objectively considered who was best suited for that task, as well as who would be unable to perform the task at all. Interestingly enough, based on that, there was one team memeber who really should not have had any tasks. That leads me to question their value to the company. At some point, weak links need to removed from the chain. However, that weakness may not be ability, but often attitude. A person who is willing to admit mistakes and try to learn from them, can be far more valuable than someone who maybe produces great work, but drags the team down emotionally. As much as I hate seeing people leave a team, sometimes it really is needed in order to make the team more productive.
I sincerly hope that in the near future I can tell you what my team did to resolve our issues. I hope that we are able to build great products, using the best technologies available to us. A man can dream...