Making a full commitment

I ran across a guest post at Smart Football this morning when I was trawling around looking for more takes on UH’s ridiculous last second 46-45 win over Tulsa last night that I think applies to just about any field as well as it applies to football coaching. The piece is a provocative argument about how to implement offensive schemes in football, but it could just as easily apply to adopting agile development practices on a software development team. Here’s the part that really resonated with me:

Before discussing the technical benefits, let me first say that operating exclusively out of a four-wide environment is the first step a coach makes towards acculturating his program to the offense. To run the run and shoot effectively, it is necessary to commit to it entirely. Coaches that retain the ability to use tight ends, h-backs, and multiple-back sets create a crutch upon which they can fall back on when things don’t go as well as they’d like in the early going. Inevitably, what happens then is that the team becomes a multiple-set team that uses some run and shoot packages on passing downs. What never happens, however, is that the team converts to the run and shoot culture. And without that, the coaches and the players never become fully comfortable in the system, and then when the team struggles more, they blame the system.

When you decide to run this offense you need to burn your bridges with the past. You have to declare, “This is what we will sink or swim with. We are a run and shoot team.”

There’s a lot of wisdom in those two paragraphs, in that they describe the difference between a plan on paper and what happens when actual humans try to implement a plan. As a coach (or software development manager), the temptation is always to try to keep your options open so that you can adapt to any situation that arises, but what often happens in those cases is that it can leave the team confused. The more branches you have in your logic, the easier it is for team members to make poor decisions and to second guess the decisions other people are making.

Let’s take test-driven development for example. I don’t believe it can work without a full commitment. Either you demand that tests are written in all cases, in the manner prescribed, or you can watch your TDD regime wither away as competing pressures give people a reason not to write tests. In some cases, applying TDD may not make the most sense, but using it anyway creates a culture that practices TDD. This doesn’t answer the question of whether TDD is the right or wrong practice for a particular team, but once the decision has been made that it is, only a full commitment will lead to its successful application.

You can apply this logic to any practice a team wishes to adopt, whether it’s as small as always writing a descriptive comment when checking in code or as big as using pair programming.

Just as team members must have the discipline to implement the philosophy that the team leader prescribes, so too must the team leader have the discipline to choose a philosophy and make a full commitment to it. Or at least that’s the argument that the poster makes.