Charlton Ogburn, an Officer during World War II wrote this in 1957:
We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganized. Presumably the plans for our employment were being changed. I was to learn later in life that, perhaps because we are so good at organizing, we tend as a nation to meet any new situation by reorganizing; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency and demoralization.
That it takes time for teams to “form up” is hardly a new phenomenon. Tuckman in 1965 proposed his, now popular: Forming–> Storming–> Norming–> Performing model to describe the stages of group development. In Tuckman’s view, each of these distinct stages were necessary and inevitable for a team to deliver results.
Whether these are, in fact, the stages of attaining group coherence and reaching a point where a team is “performing” I don’t know. The part I am more sure about is that it takes time. I know of no teams that have fulfilled their potential (or even the sum of their parts) immediately. I have also observed lots of teams that get significantly better over time as they learn how to work with each other, the technology they are working with and the problem space they are playing in.
How sad then, to observe organisations performing “Teamicide” on the teams they have spent so much time and money developing. These teams are sliced up and discarded, not because the type of work the team is capable of is no longer needed, but because the project has simply come to an end. Sometimes the parts are put through the blender and assigned onto other projects. Other times, the “parts” simply walk out the door. Demoralising, indeed.
Unfortunately, according to the Project view of the world, this is how it is meant to be – it’s a feature, not a bug. Temporary organisations aren’t an aberration, they are a fundamental part of the project paradigm. This is part of why the project paradigm makes little sense when it comes to the work of developing, maintaining and the ongoing improvement of products that are based predominantly on software. It’s like using a ferry to cross a waterway, when what’s really needed is a bridge – and then burning the ferry after the first trip.
Investing in the development of a high performing software development team should be seen as orthogonal to the work that team does. It is a worthwhile investment in and of itself because it provides an organisation with the capacity to deliver change quickly. As industry after industry is disrupted and eaten by software this is increasingly becoming a key competitive advantage.
Build the capacity and then bring the work to the team. Don’t form the team around the flawed project paradigm. That would really be a waste.
You can find more on the problem with projects here, and a summary/history of #NoProjects here.