I recently went on a course related to Agile Development put on by Berteig Consulting. It was about 3 different Agile methodologies. Scrum (which of course is very popular today), Kanban (Manufacturing Industry readers will know this, but also useful for software development) and OpenAgile, an intriguing methodology with some enlightening ways of handling iterations and team/company dynamics and a central concept called "The Learning Circle". The course was great and it was truly inspiring to see how close teams could get in only 3 short days !
I've becoming more involved in OpenAgile since reviewing the material and taking the course. Consider taking a look.
While I was at the course, I met a manager (I'll call him Fred). Fred was asking me about a problem he had related to team members who did not want to co-operate with the Agile processes.
Specifically, his problem was an employee who always chose the easiest work during the selection of which tasks he would like to perform during the upcoming cycle. In Scrum and OpenAgile the Team members self-organize to best figure out how to complete the work they will perform during an iteration or cycle. What are you to do about this ? After reviewing some of the failures and successes of the teams I have been on, I thought I'd share some thoughts about this and Maybe some ideas of my own.
Firstly, for Fred. Of course, Fred has already tried many other approaches including private discussions to no avail. Fred doesn't want to be forced into a situation where he has has to let one of his senior developers go. It should be noted, that everyone is not prepared to work in a team environment and you should be prepared to deal with this type of situation or at least see it coming. Hopefully reading this while assist you with some ideas to prevent that from happening.
I suggested to Fred that he line up the team members in front of the Task board and blindfold them and therefore allow them to choose their tasks at random. The fact that Fred is going to try this, shows he truly wants the individual to succeed and be part of the team. Of course, as Fred recognized almost immediately, the Entire team will see right through what is happening. Maybe though, that's exactly what is needed. Teams have a way of getting non-participating members to join in and pull their fair share without you needing to get involved in that process. Let the team work it out. Ultimately, no matter how much you push, you will not be as effective as the team at doing this. At a minimum, the team will hopefully see you are trying to salvage the situation in inventive ways.
I have had my share of non-team oriented individuals to work with and have had varied success in helping them join the team dynamic. I would say for me personally, I have noticed that the biggest reason someone does not want to participate with the team is that they fear their team will bring them down and they will suffer for it; whether it be monetarily or through condemnation. The individual is not "prepared to fail or succeed along with the team".
All you can do is create an atmosphere of non-confrontation, a no-blame environment and an environment where failure is just "part of the process" and to be learned from. Getting upset at a team member, or specifically singling one out for a failure is the worst thing that can be done! This will simply solidify the reason they were worried about being on a team in the first place.
As a team leader or manager, you need to be able to take the heat on behalf of the whole team if something goes wrong. Do not ever allow a problem to be directed at a specific developer or person on your team.
For most team members, over time they see the value of the team working together and start to come around. Usually as the team starts to form bonds, the non-participant will desire to be part of the work ethic and passion displayed by the team about doing a great job. They will eventually participate because it simply is more pleasant for them. Once they get their first benefits of team work, they will be a convert forever.
Occasionally, you may have someone who just is not a team player and never will be. They do exist. Unfortunately, no matter how hard you or the team tries, they will never want to participate. This is truly a sad experience as likely that person will not stay. To deny this fact would be a bad idea. Please do not get me wrong; forcing a group of developers who do not want to work as a team to do so just because Management says so, is also just as bad of an idea.
Working on teams requires dedication to the team, an understanding of one's responsibilities and a desire to work together on a common goal. The key here is common goal. A team with no goal will definitely flounder. I have talked with non-team oriented people and often I find it is not specifically the fear of failure but the feeling that the team itself does not share the same ideals as the individual. This is the root cause. "They don't get how important it is to make a nice UI", "No one on the team seems to care about the speed of the database" are typical of the types of responses I've heard from the non-team person. For each of these, there are some easy ways to address this.
Consider having a team meeting with the whole team explaining how you feel that UI is important and database speed is important (from the example above). A few comments here. I would not suggest doing this Immediately. The rest of the team will think it was just the "complainer" again trying to force his way. Explain to the individual that you care about his concerns and want to show that you are serious about his concerns. Explain that you will wait a few days and then bring it up at a random meeting so it does not appear to be specifically from him. Explain that he will see that his team members are receptive to the idea as well. Of course, why would they not be :-> Be honest though and explain that you will show him you will review it but you firmly believe in the Team's decision. If for some reason the team finds something else to be more pressing now, he or she needs to be prepared for the result. This is what true teamwork is about.
I would like to say here, it would be a very bad idea to come out of a meeting with the non-teamer and immediately force everybody into a meeting about changing the entire teams' goals for this person's specific requirements. This would only serve to give the idea that they are no longer a team, but rather pawns of the non-teamer. It's a fine line. Usually, common sense prevails and over time the team will build bonds over common goals which is when the true beauty of a team will show itself. Then one day, something will happen (maybe after some new members join, etc.). Someone from the team will come to you and say, "Hey, I think we could do better with UI and none of the team members seem to care " (which of course will include the original non-team member) :-> It's a great circle of learning and truly enjoyable to watch.
Of course there are many other classic ways to build teamwork skills. Usually group outings or even video afternoons are a great idea. There are many books about that topic so I won't talk about that too much here. The most important thing though is that you need to be prepared to protect a team who is willing to work as a team at all costs. I have been in situations many times where I have had to choose between protecting the team or my job. If you plan on keeping your job as a member of a team (especially if you are in management), you had better be prepared to protect your team. If not, you will find they won't trust you and the game is over. You might as well leave now. Trust is a two way street and if your team feels you aren't there for them, you won't be their team leader for long.
I recently learned some very interesting terms regarding teams and how they build. The terms are "Forming, Storming, Norming, and Performing". For those of you trying to get teams off the ground, I would suggest learning a bit about these. I have already passed the information on to my current team and they have already seen that some of their team "growing" pains are totally natural and part of the normal process of team building. I believe it will be a great help to future team building, especially when bringing on new team members.
The bottom line....There are no magic bullets. Just stand up for your team and the ones that are non-participants will eventually see the light and/or want to be part of the energy of the team. Things will work themselves out. Educating your team members about how teams form will help as well. The education part it a very important part as far as I am concerned.
External references (in alphabetical order):