Change Takes Time

One thing I've learned being a lead is that change takes time. And the bigger the change the longer it's going to take. Hence it follows that if your goal is to accomplish a big change in record time you had best break it into many many itty-bitty changes that you can punch out one after the other.

I am a big believer in Agile. It simply makes sense to me, and in my experience it works. But I've calmed down a bit about it. When I joined my current team I was rather an agilista. One of the first things I did was write a paper listing a raft of things that I thought needed to be changed: move to mini-milestones. Put more people working on fewer features at a time. Pair everything. I had five major points and a plethora of minor points.

Full credit to my management: they listened to my arguments and considered everything I had to say. But then came the counterarguments: The teams with whom we were working and/or dependent on were all doing multi-month milestones, and cross-synchronization would be problematic if we were working on a shorter schedule. The features weren't big enough to absorb more people working on them, and coordination of work would be too complicated, and we really needed to be moving forward on each of the features simultaneously. And on and on and on.

In case you hadn't guessed, none of my suggestions were enacted.

I can be pretty dense sometimes, but I got the message. <g/>

Which is not to say that I gave up. Far from it. But I did change my approach from a war cry to a whisper. I continued to argue that these changes would be beneficial, but I did so by talking with people one-on-one rather than talking at them in a great big meeting. I suggested books and articles for them to read. I highlighted other teams that were making similar changes. And lo and behold some quite interesting and useful and learningful discussions came about.

And guess where we are now? We've switched to one-month milestones. We've beefed up our feature teams into feature crews - i.e., more people working on fewer features. Portions of our automation stack have been developed using pair programming and test-driven design. And in what I consider my biggest victory, at a recent milestone retrospective scads of people suggested we do many of the things I have been promoting these past years but didn't credit me at all - they thought it was their own idea!

I certainly don't mean to say this all happened just because of me. Other agile proponents have joined the team. Agile is gaining steam at Microsoft and throughout the industry. Many of our partner teams have moved to mini-milestones. I do believe, however, that I am at least partially responsible. Credit might be useful come review time, but mostly I'm just glad that changes are happning, that they are proving useful, and that our already great team is becoming even better. And if they think it's all their idea, well, that simply means I'll have an easier time persuading them! <g/>

Change is good. Considered change is better. Change undertaken to solve real problems and with realistic expectations is Da Bomb.

*** Want a fun job on a great team? I need a tester! Interested? Let's talk: Michael dot J dot Hunter at microsoft dot com. Great coding skills required.