Situation
David had been recruited to the company to manage its Software Group of 50 engineers, programmers and user experience specialists. The Software Group had just had an unsuccessful attempt to introduce ‘agile’ techniques for software application development and this further reinforced the already skeptical mindset that has existed in the Software Group. David had been recruited because of his successful track-record of introducing agile techniques into other similar groups. One of his key performance objectives was to have substantially introduced agile techniques within 24 months.
David knew that introducing agile techniques requires a fundamental change to a range of key factors including: the relationship with clients, project planning, collaboration across the Group, and tolerance for continual software changes. He also was aware that all these changes need to be introduced more or less concurrently. They would require significant trust and goodwill both within the Software Group and between the Software Group and its clients in the organization. David quickly recognized that such trust and goodwill did not exist at a level necessary to support the changes he wanted and needed to make. He would need to be patient.
David set about building credibility and creating trust between the Group and himself. First, he spoke with the Group and outlined his intention to introduce agile techniques within 24 months and his reservations about making any significant tangible changes until he had the trust and confidence of the large majority of the Group. He took questions and addressed them as frankly and openly as possible without speaking negatively about the previous Manager and his initiatives.
David then put in place a range of ‘priming’ activities:
- He took every opportunity to interact informally with all staff in the Group. He took a genuine interest in their capabilities and their projects. He listened to any issues and concerns and where they were within his control he committed to address them and followed them through.
- He sought out client representatives and discussed their strategic and long term directions and resultant software needs. He included senior engineers and programmers in these discussions and, where possible, he communicated this information to the Group.
- He held monthly ‘town hall’ sessions open to all staff where he informed staff about current activities and achievements and took questions. He also presented summary performance information for the Group, including the number and status of all open projects and the results of client feedback. He also used past and current information to show the key performance trends.
- He began to use elements of agile type techniques in the way he managed the Group – visual display of information, early and progressive engagement with stakeholders, especially staff, dynamic reprioritisation, and team-based responsibility for outcomes and performance.
- He made a particular effort to seek out and engage with the key opinion leaders in the Group. He listened to and valued their perspectives and experiences.
- He encouraged staff to visit other software groups that were using agile techniques successfully and to talk to their engineers and programmers.
After about four months, a small, relatively self-contained team of engineers and programmers sought his permission to start to experiment with agile techniques. David organized an external facilitator to advise and guide this low key initiative. He positioned this experiment as a way of learning how agile techniques might apply in the context of the Software Group.
After about six months, the mood of the Group appeared to change quite rapidly. The small group of opinion leaders formed the view that David was genuinely capable and committed to the success of the Group – that ‘he knew his stuff’ and wasn’t just a company ‘ladder climber’. This view was consistent with the observations and experience of most in the Group and the majority started to give David the benefit of any doubt in most matters, including the value of agile techniques.
After eight months, the self-contained experiment was sufficiently advanced to provide a real demonstration of how agile techniques could work in the Software Group and of the nature and level of benefits that could be expected. David encouraged the staff in the experiment to be more open and visible about what they were doing (there was already a good deal of curiosity) and to explain their experiment to anybody in the Software Group that showed interest. David then made sure that consistent training, guidance and facilitation was available to any sub-group that wanted to start an ‘experiment’ of their own. Agile techniques took-off from there.
Follow Us!