There are many books out there on effecting change in an organization. But what if effecting change is not the most effective strategy?
A Story
Imagine for a moment that you have recently heard about a new recursive development technique called “DDD Driven Development.” The proponents of DDD (a recursive acronym) claim that it speeds up your development cycles by increasing feedback, but only anecdotal data exists so far. Some groups have claimed it led to higher system reliability and development speed, others the opposite.
As team lead, you pick up the premier DDD book and read through it. The arguments, while not airtight, seem to indicate that at least some aspects of the approach would be useful in your organization.
You play around with the techniques in a personal project, and then pitch using DDD on a pilot project. The project goes mostly smoothly, and most of the team members agree that it was useful. A couple dissent, and you can see that it might be difficult to get buy-in from other engineers in the organization who are not as open to change.
At the final project meeting, project data is analyzed. The data can be interpreted both for or against using DDD.
What if the company decides not to go forward with this technique?
What are the alternatives?
If you still want to use DDD for some reason, you can try to effect change in your organization–or you can start or join a group that believes that DDD is the way to go. Maybe there is another company that thinks DDD sounds like the best thing ever, and would love to have someone on their team who has real-world experience with it. Maybe it’s enough of a competitive advantage that it forms the basis of a new company.
It is generally far easier to join or create a new group that has your beliefs than to change an existing group mindset. It is very difficult to change entrenched behavior and cultural norms.
I think that teams can go much faster when they generally agree on the way that software should be built. Whether the practices the team chooses are optimal might not be as relevant as whether the team is in agreement on them. So-called “best practices” are dependent on the team as well. If you have one team member who advocates unit tests and another that thinks unit tests are a waste of time, it won’t be long before those beliefs begin to conflict.
Whether DDD is really faster, if everyone on the team prefers to work that way, they are going to buy into it. It might be that they have a bit of ego wrapped up in it, and use that for more motivation. This in turn creates its own unique culture, which excludes people who don’t prefer to work that way.
Joining another group is the social or business equivalent of a forest fire that makes way for a fertile new forest–harmful in the short run, productive in the long run. There will be less arguing and lot more happiness on the side of the developers who branched out with the new techniques.
There will always be people who dislike certain techniques, for good and bad. But it’s up to you to decide who to associate with.
On the other hand
Clearly there are a lot of good reasons to stay on a project or organization even if everything is not to your specific tastes. For one, you could be wrong about the best way of accomplishing something. For another, maybe there are several valid ways of approaching the same problem, and the value of having the team aligned is high enough not to rock the boat. Or maybe it’s a stylistic thing that you are willing to compromise on.
Your thoughts?
Jay Fields has a couple of great articles that touch upon some of these points, with many real-life examples. See Compatible Opinions on Software and Signs That Your Project Team Might Be Too Large.
What do you think? Is the value in trying to introduce change to teams and organizations worth it?