Pradeepta Pradhan’s Introduction: Pradeepta has done Bachelors in Engineering from Birla Institute of Technology Mesra and MBA from IESEG, Paris & S P Jain Mumbai. He has 12+ years in IT Project Management. He is PMP Certified, Certified SCRUM Professional – SCRUM Master, with immense experience in leading global, multi-cultural teams for IT delivery. He has worked for organizations like Unilever, Intuit, Credit Suisse, Samsung & Huawei for IT delivery.
When I got trained in SCRUM, very little of it could be applied in the organizations I was working in. By then I had seen “Agile teams” in more than five reputed organizations ranging from the Banking sector to E-Commerce to Automotive Software Development. The only way SCRUM could be implemented in those organizations was by breaking everything. My trainer had warned that people try to implement SCRUM in bits and pieces and in the end say it did not work. The problem with breaking everything is that you may not survive till you start getting benefits of Agile. I read a lot about Agile transformations, Change Management and attended a lot of Agile/SCRUM meetings and tried to gather some ideas on what I could do to make my program team, truly ‘self-organizing’. I got a lot of approaches, however, saw many challenges in taking up those approaches.
I’ll first explain the case. The organization I am speaking about is an automotive supplier. The product is infotainment system for high-end cars and the development team we are working with is a 250 member team spanning over geographies.
The features going against the application of Agile:
1. Geographical Separation – Teams were spread in three continents spread over four time zones.
2. Huge team size – The development team had around 250-members which did not include the customer (Auto manufacturer) product validators. More than half of the team were not Full-time employees.
3. Highly specialized teams and sub-teams – The 250-member team was divided into Development and Validation teams which were further subdivided into various domains and subdomains based on functions of the system. All parts had to have specialized skills in terms of functional knowledge, development platform, and coding language. For example, the module which processed information from the Tuner chip ran on Linux platform written in C/C++ and the platform which ran the final display ran on a proprietary operating system which ran programs written in Java.
4. Command & Control Structure – Teams had Leads, sub leads, Managers and Directors who ran the teams with legacy command and control organizational structure. This power distance also varied with varying geographical location. The power distance was very visible in the Indian and German teams.
5. Lack of control over release cycles (Sprint durations!!!) – The Auto manufacturer had published its own sprint duration which was common to all suppliers. There was no room for flexibility in planning a product release (product increment).
What people in the organization thought about being Agile:
1. Junior developers/testers – Did not have any clue. They had not worked in the waterfall model. They thought they were doing SCRUM as they had sprints, standups, sprint planning.
2. Senior developers – Most of them thought Agile meant one could do anything and call it Agile. They complained that the “Sprints” did not allow them to design properly and that was the reason the code was so buggy. They complained we are being pressured to deliver code in short cycles.
3. Senior Management – They thought the Sprints, standups were another way of enforcing command and control. Some of them thought this was a way discovered by the Auto manufacturer to get the work done faster.
What was there in reality?
1. SCRUM ceremonies – Just for namesake. Standups were long status meetings. Sprint planning was instructions from management to set a target. Sprint retrospections were meetings by managers to find “why we failed”. Yes, we failed to meet the commitments regularly. There were attendances at the meetings, calls, and standups.
2. Self Organizing – Team members had no clue on what that meant. They were trying to do what was being asked of them. They(individuals rather than team) were trying to meet the KPIs that was being published to senior management. Developers trying to prove testers were not doing their jobs properly. Testers trying to prove code is really shitty. Unhappy team because of the pressure as well as the quality of the product they were working on.
3. Product – Product increment was popping up like mushrooms from here and there (functional domains). A team would wait for the whole sprint saying another team had to give some dependent modules for the implementation which was committed for the current sprint. Frequent missing of timelines. The product as a whole already delayed by more than a year. Bugs across the board with a plan to deprioritize bugs as the team will not have the bandwidth to fix those issues. Code check-ins frequently breaking core functionality of the product.
What do you do if you are appointed as the Program Manager of such an Ecosystem, tasked to fix whatever if wrong?
1. You implement true Agile or SCRUM – The model works and would deliver. However, there are a lot of things going against the implementation. The ‘Self Organizing’ did not exist. You do not know management would allow you to break the whole structure. You are sure that the management would not be ready for it.
2. You increase the command and control approach to a level, everyone feels that he or she are army conscripts and magically delivers everything like machines do. The only problem with this approach was we were dealing with PEOPLE and people who had ample opportunities outside the organization.
Coaching is one of the ways to achieve the first. The recommendation is to hire Agile coaches and ask them to coach the teams on how to be Agile. They will educate the team, make the team ready for Kubler-Ross change curve of the five stages of denial-anger-bargaining-depression-acceptance. Coach the leadership also. We could not do this because most of the Agile transformation coaches will break the whole structure and would ask you to be prepared for a period where you would be worse than what you are now. We could not afford the loss of time. We were not doing good, but we could not be worse. The final product was a part of one of the 80,000 parts of a car. Any delay in the delivery to the car manufacturer would result in a huge loss to the organization and the car manufacturer.
The biggest challenge was to make the team ‘Self Organizing’. So we thought of experimenting a different approach.
Some of the features of the experiment were:
1. Incremental – We went Agile in implementing Agile. We thought of doing it in short steps(towards ‘self-organization’) and check the success.
2. Bucket testing – We started experimenting with a large sub-team which had some critical deliveries. We compared the results with other teams in terms of the delivery KPIs and if the process worked, extrapolated it to other teams.
3. Non-disruptive – All prior delivery commitments were not changed. No major change in the resource allocation within the teams. All the deliveries and reports that were coming out of the organizations happened in almost the same way as it was happening earlier. This was true even for the sub-teams. To an outsider, it would look that no process has changed. Of course, we expected them to notice that we are getting better in terms of delivery.
The Pilot Team Experiment
We took a 40-plus sized team. It was completely unorganized. They had standups which were mechanical and lasted for 45 minutes. There was one ‘Team Lead’ and he ran the standup meeting as a status meeting. He thought that he was working as a “SCRUM Master”.The team had developers skilled in handling a particular part of the product. Within the team, there was no hierarchy except however the developers were of various experience levels. The work experience ranged from 0 – 10 years of work experience. We also had developers who were in different time zones. We ran a few classroom training on SCRUM/Agile. Nothing seemed to get into the head of the developers and they were only trying to find points in Agile which they liked. I thought of an idea of helping them move to Agile step by step, without they actually knowing what was the end goal. We started doing some changes.
STEP – 1 – BREAKDOWN THE TEAM
This is obvious and an Agile/SCRUM team is supposed to be small (8 or less). The team was broken down into six sub-teams. The following points were kept in mind while breaking the team.
1. Homogeneity: The teams were broken down into developers of with similar experience, areas of code, the region of India (yes even that), hobbies & interests etc. This was done so that they could gel well. We even took people who used to play pool together and put them in one sub-team.
2. Leadership: The idea of self-organization did not ring a bell in the minds of the developers. They always had been led and asked to do things. I felt if I tried to infuse the idea of Self-Organization directly it would create a chaos. We appointed leaders in each team and yes, initially we called them “SCRUM Masters”. The selection criteria for the leaders was having people who were eager to shoulder responsibilities. Experience level, Skill level was not taken as a criterion for selection of the leaders. We’ll see later how the “Leader” thing dissolved and “Collective Responsibility” came in.
STEP – 2 – HELP THEM DO THE CEREMONIES (The Command & Control way)
Initially, you have to run the ceremonies like status meetings. We had made “SCRUM Masters” for each sub-team. Contrary to what SCRUM says we let the SCRUM Master behave like the manager of the team.
1. Daily standups – For each sub-team, we started it as a status meeting which was time-boxed with the so-called SCRUM Master taking the charge. This all was very similar to what was happening earlier, the only difference was the team was smaller and it was time-boxed.
2. Daily standup Level -2 – There was second standup meeting which was run by the overall team manager and it consisted of SCRUM Masters of all the sub-teams. This was also highly ‘command and control’ driven, however time-boxed.
3. Sprint planning – This was done on two levels (using the sub-team and overall team backlog). Again in line with earlier events, the work was distributed.
4. Backlog Grooming, Sprint Demo and Retrospections – We did them in two levels.
We kept one thing in mind. Though we ran everything in command and control mode, we had sown seeds of individual ownership in the team members. One way which we employed to achieve this is to ask questions and encourage them to say “No”. The organization culture, as well as the Indian culture, was not to say “no” to any request. Sometimes people would take the advice of and say “no” to almost everything. We did make them play the “Aeroplane Game” once or twice.
STEP – 3 – MAKE THEM COLLABORATE
1. Seating Space: All the sub-team members were moved away from the corners of the floor and their barriers were broken. The workspace was made more collaborative. Some whiteboards for all teams. Some articles for the teams to just play with. People could bring in anything they wanted and one person had his collection of toy cars at the team bay. The idea was to make the place comfortable and facilitate communication and collective decision making. Some teams took a decision to make their space a bit different and from this started the way the teams decided to do things which was not ‘forced upon them’.
STEP – 4 – DISSOLVE THE LEADERSHIP & MAKE THEM COLLECTIVELY RESPONSIBLE
After starting as a command and control organization with SCRUM ceremonies being performed only as “Names” the next step was to cultivate “Individual Leadership” and “Collective Responsibility”.
1. We started rotating the roles in the team. Everyone was given a chance to become a SCRUM Master. We had seen that the one who was made the SCRUM Master started feeling responsible for the team’s output as he/she was made accountable. Since we made all go through this role everyone felt an accountability of the team’s output.
2. Encouraged them to question each other. The meetings started to be more participated. They moved from a status call to a discussion on what each was doing or was blocked on.
3. Ask the team members to voluntarily take up tasks. They ask them to volunteer to become the SCRUM Master.
STEP – 5 – HELP THEM DO THE CEREMONIES (The Agile Way)
Once people had started taking up the position of SCRUM Master voluntarily the command and control had automatically vanished.
1. Since people started taking tasks on their own, the Sprint planning meetings started to be somewhat like SCRUM recommends.
2. Then, questioning each other also put control on the individuals.
3. The team was encouraged to learn from its mistakes, rather than being questioned on mistakes.
4. Everything thing that went-in or went-out of the team was a team thing and not directed to any or a group of individuals.
5. Everyone was encouraged to learn from each other. This also made the team members multi-skilled.
STEP- 6 – MAKE THE ‘SELF-ORGANIZING WAY’ SUSTAINABLE
1. Hiring – If anyone was to be hired for a particular sub-team. The interviewee was interviewed by all the team members. Even if anyone rejected a candidate, the candidate would not be hired. This meant that the team had signed up to carry the weight of the individual that was coming in. Good or Bad, the new individual was again a “collective responsibility” for the team. Of course, the hiring process was slow.
2. Appraisals – As an organization, we had a Bell Curve to follow during the appraisal. We thought of making the appraisal on a team basis. Everyone in the team had the same rating after the appraisal. This served two purposes: (i) enforced the collective nature (ii) Promoted healthy competition within the teams. Internally we maintained an appraisal system for each individual which was done by everyone in the team. This was also openly discussed within the team.
3. Communication – We had timezone barriers. Since it was mostly between East Coast of USA and India we virtually had zero overlaps. We devised a new method to overcome this. Emails were replaced by videos from the individuals to the team members in remote locations. This is the closest we could get to Face to Face communication.
What we achieved?
1. Delivery Timelines – At the beginning, we could easily predict what we were going to miss on our commitments. It was better than earlier cases, where only at the end, we would find out what we would miss. It became better with we getting better at reducing the misses. Finally, we were in a position to tell the client at the beginning what we would not be able to achieve. We would mark “User Stories” which seemed to be a “Stretch” or “Impossible” for us. We haven’t become perfect, however, our Group head now gets less to no escalations over a sprint.
2. Quality – A Lesser number of regressions, better product performance.
3. Employee Satisfaction – Team members really gelled well. The attrition was also reduced a lot.
What are the next steps?
1. Extrapolation
2. Multi-disciplined
3. Technical Excellence
Instead of making a Big Bang change we tried to take it the slow way. Individuals may not agree with us, however, given the circumstances, this was the best approach that we take and it has been successful. We would love to hear from you about your experiences making a team Self-Organizing. Especially if it is for a different country. The country-specific cultural angle is one which has not been studied a lot in Agile. We would love to explore this.