A Tale of Two Teams
As anyone who reads this blog knows, I’m an extreme programming enthusiast. I love pair programming, test driven development, and the constant communication with customers. it’s one of the reasons I took up a job at my current employer, because it is an “Extreme Programming Shop.” However, for awhile now I’ve heard a bit of bickering from some that “we don’t do XP”, or “we don’t do XP by the book,” or perhaps even “XP doesn’t work for us because it’s wrong.” Ouch!
An important thing I have learned is that how well your team does with XP is how much your team buys into it. It doesn’t matter if management jumps on board or not, if your team members don’t hold each other accountable to the practices, if they let each other get away with not pair programming, writing code without any tests, and limit their customer communication, OF COURSE they aren’t doing XP. And that’s the difference.
In my last department, we saw quite a few changes in team structure, and I think I hopped around to 3 or 4 different teams there. There were teams that I almost felt that we weren’t doing XP at all, and was frustrated. But then I switched to a smaller team (from 8 people to 5) that included people who were zealous about XP like me… we made it a general rule that if code isn’t checked in by the end of the day, it must be deleted. This kept us going fast and releasing small changes that could go to production after check in if need be. We kept each other from “cowboy coding,” if one of us were stuck as the odd developer, the solo person would either do some data analysis, pair up with other teams if needed, or go ahead and spend a session talking to the customers and showing them our acceptance tests.
The point I’m trying to drive to here is that it doesn’t matter what your manager tells you, it doesn’t matter if the company has bought into XP or some other agile process. If the team doesn’t truly embrace the principles, you’re right… you aren’t an XP team. Just as much as you’re not a football team if your team members aren’t willing to walk out on the field together and work with each other to win. And don’t make excuses to stop you from being as agile as you want to be…. sometimes I hear people say on (both on and off the XP mailing list) that they’d like to be agile, but their boss and customers pressure them to “just sit down and get it done!” Don’t make that excuse…. being agile is about being adaptable to change, the very definition of agile is “moving quickly and lightly with grace.” If you can’t move quickly, you’re not agile. It’s that simple.
SO, now that the ball is in your court, what do you do? Do you continue to make excuses and shove blame off on the organization, the boss, and your team members? Or do you step up and be a motivator for change, and motivate yourself and your teammates to hold each other accountable?
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
May 23rd, 2007 at 4:08 pm
I’m struggling in this arena, almost exactly as you describe. When I first got into XP, I tried to preach about it to my team and we actually ended up trying it out. The problem, however, was that I didn’t get buy in. I figured they’d use it and love it like I did. I was wrong. I shouldn’t be telling my team exactly what to do.
In my current situation I find myself trying to lead by example. I don’t want to nag at people and preach about things and get into endless debates. I want to show people how these things can be successful. The problem is I haven’t found that good middle ground where I can spread the word, but not be annoying. I want people to ask me to show them.
Hopefully the things that I am passionate about will start to be noticed among my various teammates and that it will be easier to suggest these things. Until then I think I can just declare my belief and interest in the subject and hope that people take notice.
Thoughts?
May 23rd, 2007 at 5:52 pm
Well, I think having buy in on your team is a major effect.. but you have to look at the motivators for buy-in. If you just tell someone they should do XP and it’s good, they may not be very convinced at all at tell you to hush up.
I think it’s a matter of influence, how well you can prove your case, etc. Maybe show a few success stories… perhaps start small by doing some of the “best practices” and leaving them impressed.
Perhaps a good example of doing something like this was in my department in regards to FIT tests. Developers were writing FIT tests, but not with the customers. And although they did prove code worked, they did so poorly. I went crazy and worked at improving readability by experimenting with different ways of approaching our tests, and trying to get collaboration with our customers.
At first it felt like everyone was against me because people don’t like change. But luckily, improvements were made and I even went on to influence others to improve our acceptance testing framework.
Imagine my suprise when I got a lot of recognition for my efforts at work recently.
May 24th, 2007 at 10:54 am
I love to hear success stories like these.
One of my most favorite articles on the internet is the series that James Shore put together in his Change Diary. Although it wasn’t a 100% success story, it was definitely an insightful piece.
If you haven’t read that, I highly recommend it. http://www.jamesshore.com
May 24th, 2007 at 10:26 pm
Hi there, great stuff to read. Just like to know what you think of this?
1) and the constant communication with customers
–> Can you elaborate further on the constant communication? AFAIK, my Software Analysts or Project Leads at my company meet customer on requirements not developers. We only have UAT, training and production to get the users to hands on the system for each phase.
–> You mention you get customers to see the acceptance test, do you do it very frequent? Or only those special days like UAT, training and production? And do the developers present to customers?
2) Certain projects I work on are very short in time. Even it is a multi million project. But each tasks are given in 1 or 2 days of time. How are you able to practice all this in a such a short time frame? Furthermore the management doesn’t care what do you in your code, the amount of code plumbing you have. So to management having these practices or not, isn’t important.
As long you delivered which matters the most.
By the way, I am a motivator to my current team I am working in. But I am researching further on convincing the people here. Like to hear from you.
Thanks again yeah.
July 24th, 2007 at 3:49 am
Extreme enthusiasts are always successful. Good team is also of great importance. Keep up working. Good luck!