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.

Comments (3)

  1. You won’t believe this, but I was just writing a blog about exactly this – how difficult it is sometimes to get people to change and look with an open mind towards a different approach. I was screaming down the rooftops about how SCRUM is the greatest process on earth and how all small teams should do SCRUM. It was hard for me to understand why folks were resisting something that would certainly and surely improve productivity.

    Same story here – It was later that I realised that the problem is with me trying to shove Agile down everyone’s throat. A different approach to evangelize "agile" would work but also work much slowly than I would wish! Mgmt is very supportive and a bit more realistic than I am. 🙂 I hope my team turns out the same way as yours did! 🙂

  2. Phil Kirkham says:

    I also wrote a big paper with everything that I thought had to change so that we could do proper testing and have some form of QA and I too have now calmed down a bit – though it’s hard to find the balance between being enthusiastic and being a pain in the *ss

    Small regular pushes, nudges and hints seem to have worked better than one huge shove.

    The one problem I have is that some of my younger allies are more impatient and want to know when when WHEN all this is going to happen and cant see that things are changing, but gradually

    What sort of timescale did your changes happen in – months ? years ?

  3. Anutthara, Phil: If only I had written this post years ago and we all could have read it, it might have saved us all some pain! <g/> These particular changes took a couple years before they took hold. Improving my team’s development process went a lot faster, about six months. Other changes I’m still working on. <g/>

Skip to main content