If you look up dogma on wikipedia today, you’ll see this phrase as part of the definition: “It is not to be questioned.” Software developers are at their core scientists, however, and scientists are defined by the fact that they ask questions. So it should be obvious that there’s no room for dogma in your software group. And yet, go down the hall to a few of your more senior developers and ask them about coding standards, development practices, or even IDE preference. Good luck.
My organization made a recent decision to formalize the technical lead role a little bit within their scrum teams. We did it because we felt there was a gap not being filled, and we felt like our ability to execute and ship a product was being impacted. A colleague of mine forwarded me an article about the agile “team lead” role, and I was more interested in the comments than the actual text — people discussing whether the role was strictly agile or not.
I’m sorry, but I could not care less.
I’m reminded of a recent post by Mike Cottmeyer (who, by the way, gets paid to help companies adapt agile) where he argues that adopting agile isn’t the point. The point is to add value to the business.
The point isn’t to play with new technology, to be open-source, to write tests, to measure coverage, or to adhere to standards. We do these things when the time is right because we believe (based on evidence) that doing those things will lead to specific results. Scientists can’t afford to be religious about their science, and computer science is no exception. Don’t stop asking questions. Don’t stop challenging your leaders, your preachers, your prophets. If you feel like your practices are set by robed oracles atop a mountaintop, something is wrong with your organization. Now’s as good a time as any to push back and find out why.
Because in the end, we’re here to sell software that delights our customers and keeps us in business. Everything else is peripheral.
