Agile Adoption – Vital Behaviours and Influence Strategies
One of the books on my reading list this year was “Influencer: The Power to Change Anything” (by Patterson, Grenny, Maxfield, McMillan, Switzler). Influencer argues that change can be made inevitable by identifying the vital behaviours that will bring about change. It then outlines a set of influence strategies that can make those vital behaviours happen. As an agilist, I’m interested in uncovering better ways to deliver successful projects regardless of whether or not those ways are ‘agile’, so I searched for the vital behaviours relevant to this context. Interestingly, I discovered that the three most probable vital behaviours to successful projects are those that are already found at the core of agile. Additionally, as I read about the set of influence strategies, some of the strategies resonated strongly with approaches we already use on agile teams.
Vital Behaviours for Successful Projects
The authors of Influencer argue that any change can be made inevitable if you can find the correct set of vital behaviours. For many common problems, these vital behaviours have already been discovered by various research teams. For example, the vital behaviours for losing weight and keeping it off were identified by a National Weight Control Registry research project: a) weigh yourself every day, b) eat breakfast every day, and c) exercise with home equipment. Scholar Howard Markman found that a strong marriage can be determined by looking for the following vital behaviours during arguments: a) statements that communicate shared respect and purpose, and b) taking timeouts when required to halt emotional escalation. Dr. Ethna Reid discovered that the best teachers a) reward positive actions often and b) alternate frequently between teaching and testing.
So what are the vital behaviours for successful software projects and how does that relate to agile? Has anyone done the research to find the vital behaviours that are part of most successful software projects? Indeed – Alistair Cockburn did significant research into this topic and found three behaviours common to successful teams:
- Communicate more effectively through co-location.
- Frequently talk to your customers.
- Deliver frequently.
Here are the highlights of his research:
- In a 2006 Agile Toolkit podcast he described the results of his research and said: (starting at about 3:25) “Those that were co-locating face to face, (with) short delivery cycles, (and) access to customers were delivering. Those that were following some process very carefully were not delivering.”
- In an article where he describes his research methods and results he writes that a) they improved their communication by co-locating, b) had access to their customer and c) had short delivery cycles.
- He also commented in his article that “I ran the seemingly odd hypothesis that if you simply put four people in a room with whiteboards and computers, give them access to the users, and have them deliver running software every month or two, they would have a high likelihood of success in delivering useful, working software. Surprisingly, this hypothesis has not yet been broken."
When reflecting on my own project history there are a few other behaviours that I identified as possible candidates. The three at the top of the list are self-organizing teams, continuous improvement, and test first approaches like TDD and Specification By Example. However, these are techniques that I’ve adopted only in the latter part of my career and when I look at my career as a whole the three behaviours identified by Cockburn are consistent amongst the successful projects I have been involved in. The authors are clear that the behaviours vital to success will change over time so possibly these additional behaviours are vital for taking successful projects and improving them. For this article I will just deal with the three behaviours identified by Cockburn.
The authors suggest that to confirm that the correct vital behaviours have been found we should look for other behaviours that come bundled with them. Here are some example behaviours that are likely to occur once these three are implemented:
- In order to have short delivery cycles, you will need to deliver small increments of value which could lead your team towards the practice of user stories.
- In order to have short delivery cycles and not spend an inordinate amount of time doing manual regression testing for each delivery, your team will likely move towards automated testing.
- In order to have short delivery cycles and not spend an inordinate amount of time creating and deploying packages, your team will likely move towards a continuous deployment practice.
- In order to have short delivery cycles and achieve quality results, a test first approach seems likely to occur over time in order to build quality in and also enable change tolerant code.
- In order to have easy access to expert users when those users are external, ideas from Lean Startup and Customer Development such as split testing and minimum viable products would have to be used.
- In order to improve communication when individuals are in many locations, they would have to make heavy use of communication media such as IM, video, and desktop sharing.
So if you are a manager, executive or coach wondering how you can make your teams more successful, try influencing these three vital behaviours. If the Influencer book is correct, (and there are many examples in the book to indicate it is) then these three behaviours should make a significant impact on your projects.
Six Influence Strategies for Agile Adoption
The follow up question is, of course, how do we influence these behaviours in our organizations? Verbal persuasion is often our default (and only) strategy and you have likely experienced that in most cases it is not effective. The second half of Influencer is devoted to six types of influence strategies that offer promise for helping bring about the vital behaviours crucial to successful software projects without resorting to verbal persuasion. The strategies are categorized as personal, social and structural motivation and ability. As stated above, some of these influence strategies and the examples I provide will sound familiar to practices already used on many agile projects.
1) Make the Undesirable Desirable (Personal Motivation)
If people find the behaviour undesirable then they are not likely to exhibit that behaviour unless you can convince them it is fun, rewarding, or in their best interests.
A colleague of mine recently experienced some resistance from his team when he asked them to try pair programming. Instead of forcing them to do it, he simply asked” What would it take to get you to try it?” When they joked that they would gladly try it if they had a big screen TV to use for paired programming, he quickly obliged and the rest was history. The new behaviour became fun – it became desirable.
2) Surpass Your Limits (Personal Ability)
People need to be convinced that they have the ability to make the required changes. Send your team to hands-on agile training so that they can experience what it is like to work on a project that exhibits these vital behaviours. Make sure that the training is hands-on rather than lecture based. Once the project has started, help your team gain confidence by starting with short delivery cycles where they are producing working, high quality code - even if only in very small batches. Once the team sees early results they will gain confidence that they can change their approach.
You might also ask them to try the new approach for a week before saying yes or no to a particular technique. This allows them to gain some control over the decision while you have achieved your desired result of letting them know that they can indeed make the change. A colleague reported that their organization used this approach to move the team from siloed development to a self-organizing team approach. After a one week trial period the team agreed that they could indeed follow this approach and continued to practice it enthusiastically.
3) Harness Peer Pressures (Social Motivation)
Use peer pressure to your advantage by finding the opinion leader (the one that has the most respect and influence) on your team. Spend a lot of time with that person addressing their concerns. If they are included in the process they will begin to share your ideas with the team and the vital behaviours will occur.
A team I’ve talked to used this approach successfully. One team member was determined to start trying some of the agile techniques and brought a resistant opinion leader with her to a local agile user group. The event triggered some opinion changes and addressed some of his concerns. That week the two of them were able to start successfully implementing some agile practices with their team.
4) Find Strength in Numbers (Social Ability)
When any team is learning new behaviours and practices they need help to improve their abilities. This influence strategy suggests that the team should be supported by having just-in-time coaching and mentoring in parallel with asking individuals to learn topics and train their own team. This builds the social support needed to help the team change.
While many teams use mentors to help learn new practices, another common approach teams have used in parallel with mentoring is called “hot topics”. The team meets on a weekly basis and selects a topic relevant to the change they are trying to make. Each week a different team member is responsible for preparing the topic and presenting it to the group. The presentation could include watching a video, doing a short hands-on exercise, reviewing some code snippets, or demonstrating how to refactor legacy code. This informal activity becomes a safe way for people to learn the new ideas and gives them authority to try out new ideas relevant to the change. It also builds the social capital (we’re in this together) needed to influence the vital behaviours.
5) Design Rewards and Demand Accountability (Structural Motivation)
Any system of rewards can be dangerous. Influencer carefully maintains that if the other influence strategies are used properly, rewards need only to be small in order to influence change. If you haven’t done your work with the personal and social motives, rewards can backfire or be ridiculed. For successful teams, rewards also need to be geared towards team performance and not individual performance.
Many agile teams use a simple and yet effective rewards system that is tied directly to one of the vital behaviours. Teams visualize their workflow and move post-it notes to the “done” column when a small piece of functionality is ready to be delivered. For teams that are first applying agile techniques, moving those first post-it notes to the “done” column is cause for team celebration. One of our teams has a cow bell that they ring whenever a story is completed – another small way to augment this strategy. This reward system can also be used to help keep the team accountable because it makes their work visible. If stories aren’t moving or the wrong stories are being worked on it gives you a chance to discuss this with the team.
For more information on rewards and their relation to knowledge workers, take a look at this short video of Dan Pink’s work.
6) Change the Environment (Structural Ability)
Make use of the physical environment to influence the desired change. Create your co-located space so that it encourages people to work together by removing the cubicle walls, office doors, etc. Increase the “propinquity” of your teams and your customers by having them work in the same space. “The best predictor of whether two people will work together is the distance between them.”
The authors report that a study at Bell Labs found that the distance between two people was the greatest indicator of whether or not two people would work closely together. People who worked three feet away from one another were ten times more likely to collaborate and communicate than people who worked thirty feet apart. So if you want to influence the behaviour of improved communication, simply put the team members together in one room without cubicle walls.
A team I was working on was asked to sit together in a rather cramped area. Five of us (two developers, one application architect, one tester, one business analyst) were asked to share a very small area about the size of a typical office. The business analyst had desk space equivalent to the size of a typical end table; there were monitors perched precariously above us on small shelves; we shared one phone; and the limited wall space we had was covered with our visible boards and stickies. Fun!
As we reflected on our space at the end of the project, this comment was made from one of the developers: "On the bright side, I don't think I looked at the requirements document once. I just turned to the business analyst beside me and asked her what needed to be done!" Co-location enabled high communication between team members. Co-location for the win.
Influencer: The Power to Change Anything has some great ideas and strategies on how to influence and make change inevitable. If you are wondering how to influence your team to improve its software project results, consider improving communication within the team by co-locating, ensuring frequent access and communication with your customer, and delivering functionality frequently. Strategies that target personal, social, and structural ability and motivation can all be crucial for realizing improvement. For software projects, those behaviours and strategies reflect ideas and practices that already occur in many agile projects.
Finally, if your teams are struggling to exhibit the behaviours, consider changing your influence strategies rather than giving up or targeting other behaviours. For additional ideas regarding strategies (patterns) of change, you can also read Fearless Change: Patterns for Introducing New Ideas (Manns, Rising)
About the author
Steve Rogalsky gets a thrill out of solving problems, working with teams, and helping people learn and improve. I apply this to software development using lean and agile techniques as a process hacker, coach, analyst, tester, developer, speaker, and agile advocate. I blog at winnipegagilist.blogspot.com and work at protegra.com.