How should we transform the organization from no-framework to SCRUM framework driven design and development? How would we talk to our clients and to our managers and to our young developers? Luckily for us, we had a very supportive CEO and a very understanding Human Resource Manager. The latter was particularly instrumental in being a source of inspiration and also guidance. She did not understand SCRUM but she did understand that I was committed to it and that it would do good. It might be her experience or it just might be her belief that if someone is willing to bet his life on trying something, it must be good.
Any how, we had introduced bits and pieces of SCRUM in many projects. The bits and pieces revolved around having product backlog, sprint backlog and just in time analysis. Some teams were more receptive to change than others. Surprisingly, Business Analysts, who had the reason to fear SCRUM embraced it the most – taking to user stories and just in time wireframes like duck to water. The developers were intrigued and were not really getting it but were willing to give it a try. QA was the most confused – they simply did not know how to adapt. Rather than go for 100% SCRUM [daily SCRUMs, tracking, estimating etc.] in first phase itself, we preferred to let things take a momentum of its own and see if team was receptive to any inputs. Another group which was skeptical seemed to be Project Managers. Most wanted to know why not XP and Rational and why SCRUM? Others doubted skills of people advocating SCRUM. Still others simply said – SCRUM can not be implemented here. With even partial SCRUM, issues being exposed and highlighted were too much for management to manage. Add to this the fact that leaving the team to figure out how to do its own work had its advantages and disadvantages. The teams had not been trained how to manage work, interact with clients and for some the change was too much and too soon. Hence, a bit of hand holding and directing was required in the first few months.
As SCRUM was being implemented, we were also identifying the generation next of the organization. We were finding it increasingly hard to find senior resources from outside and it made sense to train people in house for more responsibility. Right when the trainings for these people were to be held, my presentaitons on SCRUM were ready. And bingo the first batch of the generation next [the would be middle management] was to be trained in SCRUM. Luckily for us, the word from developers and analysts in existing SCRUM projects was very good and others were already intrigued in learning about SCRUM.
We held the first training in SCRUM a group of 08 developers/ designers on 07th November 2006 and by all counts, it was well received. 07 of these people responded to a feedback on Zohopolls and the results were largely positive.
Another tendency that was noticed was that once teams were left alone to manage their work, they just would not get it and turn to anarchy. Client communication suffered, work never got done and the team was at brink of failure every another week. This just emphasized how important someone who understands SCRUM is to the team and how its important for the team to make a personal committment to deliver on time.