How to introduce ideas when people just want to get things done?

How to balance pragmatism with improvement?

Beyond persuasion, what can we do to change things?

How do these patterns relate to what happens in the software industry?

I found that several of the patterns identified could be applied when trying to make individual changes as well as organisational ones. The stand out one in this area was 'Time for Reflection' - this spoke of holding a personal retrospective regularly to see what went well, what you could do differently and what was still puzzling. This can certainly be applied whether you are insitigating change or not, and is quite similar to the idea Eric Feng lays out in 'become twice as good in 70 days'. I tried this out for several months last year and while I eventually stopped because daily reflection seemed too frequent, I could certainly see value in this approach if done at the end of each week for example.

An idea which I was really keen on introducing onto my previous project was Phillip Calcado’s idea of Domain Driven Tests. I failed on this occasion from not applying the 'Just Do It' pattern. I had only briefly tried out the ideas Phillip laid out and was therefore unable to come up with good responses to the possible drawbacks colleagues pointed out. I needed to get experience with the idea before trying to champion it.

Closely linked to this was the idea of introducing ideas on a temporary basis - the 'Trial Run' pattern. We introduce an idea with the premise that if it doesn’t work we can just go back to the old way of doing things. This is certainly a useful approach for getting skeptics of an idea to give you a chance to prove its worth. It is also similar to Steve Pavlina’s 30 Day Trial technique for introducing new habits, except the habit in my world might be introducing someone to the world of TDD rather than an exercise program!

A perhaps obvious but nonetheless important idea expressed was the need to have passion for the change that you are trying to instigate. If you don’t care then noone else is going to. I am fortunate enough to have the opportunity to work with some very passionate colleagues who display great enthusiasm to try out new ideas in the desire to find a better way to solve problems. This passion mixed in with some serious technical ability has led to ThoughtWorks generating quite a presence in the Ruby on Rails space.

The authors describe the way that ideas spread as flowing from Innovators => Early Adopters => Early Majority => Late Majority => Laggards. I imagine Ruby on Rails is probably at the 'Early Majority' stage at the moment, having been promoted early on by the likes of David Heinemeier Hansson, Chad Fowler, Dave Thomas, Obie Fernandez, Jay Fields and co. It is interesting to note that these guys probably applied many of the patterns listed in the book along the way to getting Rails more into the mainstream.

One idea which surprised me was that of finding a champion skeptic for your ideas. This person would play the role of devil’s advocate or realist, pointing out the flaws in our ideas. The natural human instinct is to reject the ideas of people who disagree with us but engaging them can lead to usexamining our ideas more thoroughly and allow us to come up with sharper ideas which consider any objections raised.