Many of the practices I’ve introduced to my team have largely stayed within my team. There’s no moat around our section of cubicle land, and all the other teams knew about the majority of our practices, but we didn’t see any uptake. I hoped about a year ago when I ran a TDD seminar with JUnit for the bulk of java developers outside my team that we’d see a change there. About a year later I think the only evidence that they’d been through a seminar on TDD was a few tests scattered across one project.
Osmosis wasn’t going to be enough to convince people. It went the same way with my team. A few of them have really run with everything from code reviews to TDD, but many of them take a great deal of convincing.
The next push was to talk to my peer manager about how we spread the adoption across our groups. I’ve put that discussion off for at least 4 months now largely due to fear. I heavily lean towards consensus building and I don’t like show up preaching like a convert. We’ve had a pretty good relationship though and for some reason I finally stopped mulling over my notes and approaches and just dropped in on him in his office.
Turns out he’s pretty open to the ideas, and it really didn’t take a whole lot of convincing. We’re going to start out introducing some of the easiest stuff like automated builds and continuous integration and then progress to TDD, code reviews, static analyzers and the like. Just one practice at a time so we don’t overwhelm anyone with change. At the end of the process our entire development organization should be performing all the same practices to a lesser or greater extent. By this time next year our basic practices should be shared throughout the development organization.
Definitely should have broached the subject much sooner.