In the video embedded in the article Honey, I Shrunk The Change, I talked about how raising the bar is not the way to motivate the elephant. Lowering the bar and shrinking the change can give your team the confidence to continue the journey to become the agile team they want to be.
Just like the car wash that put two stamps on customers’ loyalty cards or the researchers who informed the hotel maids how much exercise they were already getting, you can inspire your team to take the next step on a journey to agility by showing them how far they’ve already come.
The Journey To Extreme Programming
The first step I take is assessing where my team is already practicing agility or where a bit of the agile mindset has made an appearance. In my own team, I’ve been talking up the benefits of Extreme Programming, including the practices of pair-programming and test-driven development. So I would want to assess where my team is in their development of their skills to execute such practices.
From Infrequent and Discriminate to Promiscuous Pair-Programming
It has been my experience that most of the benefits of pair-programming on a team occur when the team pairs regularly and changes partners frequently. In Arlo Belshee’s research into so-called promiscuous pair-programming, he found that exchanging partners every 90 minutes and exchanging the most experienced partner each time was most effective at enhancing velocity.
I assessed a team I recently joined against this standard. This team practiced some pairing under certain circumstances such as when an expert needed to be consulted or when two people worked on closely-related components. Such pairing was short-lived and far from promiscuous.
But, like the stamps on the loyalty card, it was a place to start. As an individual contributor on the team, I had the opportunity to pair promiscuously with each team member, and demonstrate how effective the practice was, and get them to see how the pairing they were doing occasionally and with the same partner was at least a stepping stone towards an even more effective practice.
From Unit Testing to Test-Driven Development
A second practice where my team already had made some progress was test-driven development. At the time I joined them, some members of my team had recently started to practice the writing of automated unit tests. There is a lot to learn to write unit tests effectively. You need to learn the concept of test doubles, whether it be mocks, stubs, spies, or fakes. More importantly, you need to learn how to listen to your tests as taught by Nat Pryce and Steve Freeman in their book, Growing Object-Oriented Software Guided by Tests.
Much like having a goal of promiscuous pair-programming, I had a goal for my team of full test-driven development where each code change is the minimum necessary to make the latest test pass and a strong focus on refactoring. But that’s not where we started. The unit tests my team wrote came after the code was written. Much of the time, this meant that listening to the tests meant large refactoring changes.
But again, the practice of unit testing meant that my team already had some of the groundwork laid for test-driven development. Through the mechanism of pair-programming, I could help develop their practice on new code to make full use of test-driven development. Because they had experience with unit testing, I could demonstrate to them that they had a shorter route to test-driven development.
Reframe Your Journey
The next time you and your team are at the start of a long, intimidating journey, see if you can reframe that journey to take into account how far your team has already come and see how much that motivates them to go the rest of the way.
I would love to hear what you thought of the article, so feel free to comment below, on The K Guy Twitter, or on The K Guy Facebook fan page.