Written May 23, 2007 at 10:11 MDT Tagged agile
This is a hot topic for me right now, as I talk with lots of people who are working through trying to make their teams more 'Agile'. That word is a little overloaded and overused lately, so I am going to focus on how you can make your team more Extreme through use of practices and strategies that live in the world of the development team.
I am going to point everyone to James Carrs great post today about A Tale of Two Teams. It is a great post that helps me start of by making a big bold statement (reiterating what James said).
As a consultant, I get the great joy of being 'that guy'. The one who comes in to shake things up and challenge peoples assumptions about the way they build software and the software development process in general. Having a deep love for the practices associated with Extreme programming, I have crafted a set of strategies that I feel have helped infect every team/developer I have interacted with on the benefits of this 'new' style of development. I want to share these strategies in the hope that they will inspire other developers who are in positions of influence (that is all of us) to encourage their development team to strive for something better.
Develop With Passion
This title is not a joke. My companies tagline is 'Develop With Passion'. This is a crucial, but often overlooked element of introducing a team to a set of new practices. Whether people share the same values or not, people respect people who stand up with conviction for their beliefs. If you love what you do, other people will notice and (most) will want to share that passion you have for your work. If I come in completely fired up about the benefits of agile, yet am lukewarm in my delivery, the message will get lost.
Invest In Building Solid Team Relationships
Before you can hope to reach people at a technical level, and try to encourage them to improve their development practices, they have to know you are authentic. This is especially important for consultants, who are often viewed as the ninja paratroopers of the software development world. We swoop in, do a bunch of 'magic', then we leave!! This view has to be dispelled as quickly as possible. If a team that I engage does not believe that I truly care about them on a personal and professional level, they are not going to be able to listen to ideas that I bring to the table. My first couple of weeks on a new contract are spent building a level of trust between myself and the other developers that I am going to be working with. What does this investment look like:
Focus On Small Victories
After that first couple of weeks of building relationships, I should have a great idea of how much work needs to be done to get the developers thinking and practicing in a more agile fashion. For the majority of teams out in the wild, the practices that are second nature to most agile developers are almost completely alien. There is a limit to how much an individual can assimilate at one time. This means that if I come in and throw TDD,BDD, DDD, Interface Based Programming, Automated Builds, Continuous Integration etc.. at them all at once, it will be too much information. Based on the level of the team I have to focus on individuals and practices in a piecemeal fashion. Think of running it like you own mini agile project, with the end result being having your development team completely immersed in an agile environment. My set of small wins is usually introduced incrementally using the following steps:
Once in a place where I can pair with developers that is where I choose to introduce the following concepts:
As you can imagine. It takes a bit of time to have this knowledge flow and be completely understood by each developer on a team. When it happens, amazing things start happening. Other teams start to notice, management starts to notice. Teams will be coming to your team asking you the secret to your success. And then the cycle starts again.
This is a way that teams, independent of management can start to achieve some gains associated with becoming more agile. I might be a little bit cavalier about my approach to team engagement/improvement, but I have always tried to follow this simple principle:
More people need to start taking chances. Every single developer on a team , regardless of years of experience or title, is in a position to initiate change. Do you see room for improvement, introduce it. Be the catalyst for change that inspires other people. Don't hide behind excuses that shield the fact that, more often than not, the problem lies with developers who are content to whine and do nothing, vs doing something and 'maybe' receiving some heat.
Wanna be more extreme? Do what it takes to make it happen. It's that simple.