Not Going it Alone - using the power of groups to implement change

A recent discussion on twitter relating to having the right individuals in the right roles and the power of individuals working within systems prompted me to write:-

"groups & groupthink powerful force in persisting or changing system, right individual can be fulcrum for change"

I thought I'd expand on this with some examples from my own experience to illustrate how harnessing the power of groups and group thinking can be a far more effective mechanism to implement change than what could otherwise be achieved by an individual attempting to implement the same changes alone.

The perils of going it alone

As someone who takes an active interest in ways of improving software development processes, it is easy to look at the organisation that you are working in and see problems everywhere that need addressing. The temptation is to try to address all of these perceived problems head on, and raise the subject of the changes that need to be made at every opportunity to anyone who will listen. In my experience this approach is not the most effective way of implementing change and can actually result in resistance to ideas that could potentially benefit the organisation:-

• The existing process is there for a reason
The way that things are done now are because at some point someone thought they were a good idea. The phenomenon of GroupThink can be a powerful force in resisting change in the current system. This is the name given by psychologist Irving Janis to the situation whereby people fail to assess appropriate alternatives in preference of maintaining group cohesion, validating their own behaviour through reference to the behaviour of the larger group. Attempting to incite change by criticising the way things are done can be perceived as criticising the group as a whole and can result in the team adopting a separate position as an act of self defence to maintain cohesion.
• Reputation as an evangelist can diminish your message
No matter how valid your points, if you develop a reputation for constantly preaching about the ills of your working practices then this can diminish your ability to facilitate change. Former colleagues of mine have suffered from this problem. One, for example, repeatedly raised the same issues relating to code quality in every development meeting that he attended to the extent that developers in the company warned new starters about him. Another who would print off articles on processes and "Best Practices", that the company was not adopting, and leave them on peoples desks to find in the morning. Both had valid points but their methods of tackling these worked to alienate the other members of the team and in both situations resulted in the group adopting a position of sufferance of the individual rather than appreciation of their views.

The Power of Groups

Most of the occasions when I've seen change effectively implemented, it has not been through top-down management initiatives or super-hero inspiration from an individual, but through the shifting of the group mindset to a position of support for the idea. This is not to say that change cannot be initiated by an individual, but this may be best achieved through the injection of an idea at the appropriate time and allowing the group to actually implement the change in a way that they are comfortable with. Some methods that I've used successfully to achieve this have been:-

• Engage a small group
In my earlier days working in an agile process we were using sprint washup meetings to demonstrate features delivered, but not doing regular retrospectives. Working with David Evans and Marta from SQS had shown the value of retrospectives but I didn't feel that adding another sprint end meeting into the team process would be well received. Instead I started running retrospectives for just the testers. Over time we started to show the benefits and built a small enthusiastic core group around the process we started to extend the invitation out to more members. The fact that they were joining an existing group that was positive around the process helped to enthuse people behind the process I think much more than if we'd started with the entire R&D team from the start. Now the whole development team enthusiastically attends a retrospective at the end of the sprint and some of our best improvements have come out of these.
• Time your suggestions to the identification of problems
For a long time at RainStor we worked without a physical scrum board. I felt that it would be a useful thing to have, however the lack of one was not causing us an particular issues and it was difficult to engender enthusiasm to set anything up. Then in one retrospective the team raised up the problems arising through lack of visibility of sprint items as a serious issue for the team. As the team agreed that this was an something that merited attention, I injected the idea of a scrum board. As the suggestion provided a solution to an acknowledged team problem it was taken on with enthusiasm, and the following iteration the whole team worked to set up the board and include it in our daily stand-up meetings.

Anyone who has benefitted from working in a close knit and communicative team will know what a pleasure and privilege this can be. Strongly cohesive teams can, however, be difficult environments in which to implement change as an individual. By working with the team, growing support for changes through smaller groups and in response to specific team problems, the individual can act as the fulcrum for the change, with the team providing the power to shift the balance and achieve results far more quickly and effectively that any individual would have done.

Copyright (c) Adam Knight 2011