Self Managed Team – Practical Experiences

What is a self managed/self organizing team?

What is mentioned here may not be an industry standard description. This is actually the end result of my experiment in setting a self managed team.

• The team members choose and plan the task with minimum support from line manager.
• Tasks were completed without follow up and with good quality
• In case of unplanned absence of one person, the work load is taken automatically by others in the team
• Knowledge sharing whereby increasing the competency of the team as a whole

What it means to be truly Agile

• No component (a software module, set of functions etc)/application boundaries.
• Team owns the function area (group of related functions, for eg: in telecom domain Fault Management is one functional area) completely
• Varying levels of experience for each application possible within the team
• Maintenance tasks shared among all team members
• Good team interpersonal relationships, transparent communication and information sharing for the benefit of the team goals

Experience mix of the team

• Team comprises of software developers
• Majority of the developers have around 2 years experience or less
• One or two technically competent developers with 4-6 years experience

Why Agile

• Business situation demanded this due to reduced budget availability
• But know-how has to be retained.
• Some applications had more work and others no work
• Some applications had more maintenance tasks and some more development tasks

Challenges faced

• Team resistance and insecurity to new style of working
• Knowledge build up
• Accountability
• Matching aspirations and expectations of the team members
• Performance evaluation

Approaches to surmounting the challenges

1. Team resistance and insecurity to new style of working

The first step before implementing this was to get the trust and respect from the team. Building trust is not an easy task. This gets built by your daily personal interactions and also on how you react to mistakes, great job done etc. It took around six months to build this trust and respect. After that the team should feel a sense of belonging and passion to the team/project goals. The manager should be able to inspire and motivate the team members in this direction. This needs proper communication to the team members and should encourage and expect transparent communication and team co-operation. Once trust, respect, passion and good team co-operation is achieved, the team will be raring to go.

2. Knowledge build up

Initially during the start, everybody had individual application/component assigned. Slowly they were involved for other application for small tasks. These tasks were reviewed by experts before delivering. During this time they picked up the know-how on this application as well. Then there were assigned a bigger responsibility in this application. Like this all the team members learnt all the applications within the team. The expectations were set from the beginning. For e.g.: once this task is completed I expect you to know more about this new application and should be ready to take more complex tasks concerning this application.

3. Accountability

When there is no fixed component or application responsibility for each team members, then accountability will be a problem. In order to overcome this some applications were combined into clusters and one senior person from the team was assigned the overall responsibility. This person is ultimately responsible for quality of the deliveries and also coaching and mentoring of his/her other team members. Team members are also accountable to complete their day to day tasks on time and also to seek help from senior members of the team whenever required. There are also expected to handle the senior member’s technical tasks if that person is on leave. I faced complaints from senior members about the mistakes and problems created by junior members. My answer to these complaints was always that it is up to the senior member to mentor and coach their juniors. If they are not doing well, then something is wrong with the coaching/mentoring. After sometime the complaints died down. Manager should have a good insight into what each person is capable of. Manager should also use his/her judgment when listening to these complaints.

4. Matching aspirations and expectations of team members

It is very important at the onset to understand the aspirations and expectations of team members. It would help if the manager has one to one discussion with the team members to understand their expectations. The manager should try to match the tasks with team member’s aspirations as far as possible. If for any reason this is not possible, this has to be explained to the team member with reasons transparently. For e.g.: If he/she is not competent of doing a particular task, this should be explained to him/her and should give clues on how to get this competency.

There was a concern that one team member is always doing maintenance and was not liking this and getting de-motivated. When it was brought to my notice, at next opportunity I assigned the maintenance tasks to another person. After sometime I realized that this is not a good way of working. I informed the team that everybody should take up maintenance tasks along with his/her current tasks on need basis.

5. Performance Evaluation

Another major problem in following the agile way is performance evaluation. If no component/application responsibility is assigned, it is difficult to measure the end result from each team member. Traditional methods of performance evaluation could not be used here. The manager has to rely on team members a lot to get feedback. The best method or evaluation is to get feedback from team members themselves about each one of them. Everybody in the team should be aware that such a feedback is taken. There should be a lot of stress on team work, co-operation etc. Feedback about all team members including managers is taken individually from each team member. It should be clear to the team that soft skills as well as technical skills count for performance evaluation. The amount of feedback I got from the team was amazing. It matched with my notes and evaluations which I made during the course of the project. The feedback from the team is given to the team member, but was never told who gave this feedback and they accepted these gracefully. There were instances in which team likes a team member personally, but has no problems in criticizing his/her work. The team has learnt to keep personal and professional relationships as separate.

Summary

I had to resort to this way of working basically due to budget limitations in the functional area I was handling. The challenges faced were only for first six months. Afterwards everything was very smooth. The team was very cohesive and could be seen as one gang in all places (for coffee, lunch, picnic etc). The team could achieve very high quality results and could also take up emergency tasks which were required by the customer. In the traditional setup this would not have been possible. Since the team was flexible, I just had to give any problem to the team and they found the solution. I believe this is the first step before introducing Agile way of executing projects. At the end of my experiment I as manager became free; I had to do only few administrative tasks. Hence I moved to another project. Well, all good things also have to end. After around 2.5 -3yrs the team will become stale and could be rejuvenated by adding new members and removing some existing members.

Comments

About Author