CHANGING FAST FROM A CHAOTIC TO A PRODUCTIVE TEAM

This is an article from a friend, it is really amazing how he used the open mind to change the way of doing things. It's innovation that matters!!! The author of this article is Andre Paulo Pinto Khury.

Enjoy

A personal experience of André Khury

I was not working for IBM yet in February 2003, when I was assigned to help the development team of the biggest IT project of the largest Brazilian federal bank. The development team included Java developers, COBOL/CICS developers and integrators. At the time there were 23 developers working together at the same room and for the same project and with the same goals, but yet they were very much divided among them due to some personal quarrels, differences and prejudice. One of the major problems cause was the fact that there were four different vendor companies allocating professionals in the project and wrangling for a bigger 'piece of the pie'. This dispute affected their employees and created a sort of a politics of deniability of information. There were old and experienced professionals as well as rookies that were desperately in need of support in their tasks but refused to cry for help, or help was denied when asked for. Synergy was a word that people did not know. Also, since the development was far behind schedule, the team was somehow leadless, because the team leader was much more involved with technical labor, like coding, than with the organization and support of the group. Many programs were already being coded without final requirement documentations and specific designs approved by the client - just based on scratches and informal papers. The rate of rework was huge then. In short, I've found a chaos that I've never seen before in my life as IT professional.

After making a lot of personal notes of the whole picture I was able to identify most of the issues as well as those problems that should be stricken down as fast as possible. However, I knew that in such a scenario, I should understand not only the project needs but those of the team members as well. I wanted to see the project from their point of view, and collect their opinion on how to make the work better and faster for them. So I decided to talk in private with each one and make an accurate list of all individual needs, opinions and difficulties. I was surprised many times during the interviews.

That is a short list of the main issues found with the team members and how I dealt with them:

• It was a young team composed by people coming from all over the country, with very different ages, formations and professional experiences. Their differences were starting to be too visible.

• In despite of the size and importance of the project they were working on, the team was not motivated at all. That seemed the only reason they were there yet, away from home, was the high pay.

• Many team members were avoiding to share information with others, or even to give any help to those belonging to a different vendor company. They didn't want to ease the work of their 'competitors'. There was not a feeling of partnership among the team members.

• Some were loosing focus, working without commitment with the project schedule and goals.

• Some were stuck and just waiting for other team members to finish their parts to continue.

• Some were working very slow, full of doubts about the requirements and the design documentation but did not ask for help. Instead, they were expending many precious hours trying to figure out alone what they were expected to do.

After speaking up clearly about all the problems over a team meeting, I encouraged each one to be more tolerant and flexible with the teammates and make an extra effort to put apart the differences and develop or accept friendship, exchange experiences and speak about themselves. Also, we organized a weekly team meeting where everybody would have the opportunity to speak a little about his task and his difficulties as well as make direct questions and anyone in the team was allowed to reply. They started to talk, discuss the questions and enjoy the company of the teammates.

That project was too important to be just 'one more job' to do. Working on this project should not be justified only by the good pay. It was a great experience for the curriculum of any developer. It had a nationwide visibility and was about to be used by thousands of clients. This system was even to be exported to foreign governments too. Doors could be opened and new great opportunities could appear for those involved in it. We would be making use of high technology in our area and it would make the project both challenging and interesting and we all should stop to thing about it and realize the privilege we had to be there. I spoke this way to the team in our meetings and individually also. Soon I could observe a very nice reaction of the team members.

It was unacceptable for me to watch people from a vendor company denying or hiding data from teammates of another vendor company. As the Project Leader, I had direct access to the managers and, after reporting this issue to them, we decided to make some major changes in the way the data should flow. From that moment on, all members of the team would have access to all requirements and design documents, database models, test results, schedules and any other related documentation that could be relevant for the team knowledge of the project and their individual tasks. Also, some developers were severely warned about avoiding this kind of behavior. When a new requirement or design document was sent for development, before forwarding it to the developer, I read it and show it to the team. A printed copy was delivered to the assigned developer and the files were stored in the team repository for free access. Also, to incite the development of a team feeling, whenever possible or necessary I designated people of different vendor companies to work in the same program or task. Since they had to finish the job on schedule, they normally assisted each other when a problem appeared.

To improve commitment, focus and productivity:
• Every morning, before start working, we used to have a 10 to 15 minutes meeting to speak about the day target for the team, and to clear up any doubts about the project.
• I requested a big flip chart and placed it by my desk, so that the team could see it easily. Every morning, after our short daily meeting, I put there the scheduled targets for the day and the desired individual accomplishments of each one.
• During the day, I went to each workstation and had a brief chat with the developers about their difficulties and pendencies. If some developer was stuck by any reason, I searched for an immediate solution or, if not possible to continue with the task he was doing, he was redirected either to start a new task or to help another developer with his tasks, until the problem could be resolved.
• The chronogram was updated daily and, even though it was already set as available for consult in the team repository, I insisted sending it for the team by email.
• When the team was depending on another team to continue working, like waiting for the mainframe programmers that were not part of our project to send us test files, simulators were generated accordingly to the pre-approved protocols and the developers could use them to emulate the communication to another layers, programs and platforms.
• The test team was also requested many times to improve the quality of our unit tests and to speed up the creation of the unit test scripts.

In a short time, everyone involved in the project clearly noted a great improvement in the productivity of the development team and in the quality of the delivered services. When I left the project, the performance of every team member was very satisfactory, the development was back on schedule and the team was highly motivated.