I recently read a post by Joan Westenberg (via Dave Winer) regarding the productivity of software developers (titled “”Collaboration” is bullshit.”). Westenberg refers to several instances of a small percentage of individuals creating the majority of value. This historically has been called “Pareto’s rule” or “the Pareto principle”, although Westenberg does not refer to this concept.
The post then moves to a rant on the “collaboration industry” (use of Agile tools/concepts) and how teams have moved from taking responsibility for their work to looking at communication and collaboration as the main output. From the examples given, I wonder if Westenberg has ended up being on a lot of teams like this and observed this pattern repeatedly. A representative pull-quote:
“Communication matters, and shared context matters. But there’s a huge difference between communication and collaboration as infrastructure to support individual, high-agency ownership, and communication and collaboration as the primary activity of an organisation. Which, if we’re honest, is what most collaboration-first cultures have actually built. They’ve constructed extraordinarily sophisticated machinery for the social management of work, without actually doing the work they’re socialising about. “
I can agree with some of this sentiment. The work is what matters, not the work in the tool. When I was first exposed to Agile practices 10 years ago, it took a while to understand how the tools and concepts worked together to produce results. I found that if the work is organized so the work needed to meet a milestone was clear, Agile tools (like Jira) can make it easier to see if that work is getting done. However, that was only one leg of the stool. The other legs were (2) a schedule, tasks, and milestones that are being tracked, and (3) a person in charge who has agency to manage the effort.
I have worked in the aerospace industry for 40 years, and I can testify that when those three legs are present, teams can be successful, and I have been the person in charge on those types of teams. The problems start when one or more of these legs is missing. When I have joined a new team, the first thing that I ask for is the schedule. This tells me what the plan is for the project. To me, a plan is a schedule, clearly defined tasks, and milestones. If I hear the words “we don’t have a schedule”, that is an immediate signal that the project is in trouble or will be soon. Without a schedule, tasks and milestones, how does the team know what they are doing, or what is the “definition of done”, or when are they supposed to get things done? That is as deadly as the “collaboration culture” that Westenberg describes. It is hard to know if you are “on schedule” if there is no schedule. For the record, most of the teams I have worked on or with did not have this “collaboration culture” problem. We had a schedule, and we knew what needed to get done, and what “done” meant.
On tracking whether the work is getting done, this can be done in many ways. Teams don’t have to use Agile practices to get work done, and they don’t have to use tools like Jira to track work. However, to be a successful team, there has to be A WAY to track the work. Finally, there has to be a single person in charge who monitors the work, makes decisions that affect the team, protects the work of the team, and is the “honest broker” if the team performance is not meeting expectations, or if schedule or cost targets are aggressive or unrealistic (i.e., the person who has overall responsibility). Sometimes the story that the data tells is “we are going to be three weeks late”. With that data, you can have a conversation about how to mitigate issues (reduce scope, add resources, whatever). Without that data, it is much more difficult to have a productive conversation. In my career, I have observed a number of team leaders who had problems in having these types of conversations.
The last area I want to address is the makeup of teams. Yes, team leaders (and their leaders) would always like to have the “best” people on a team (read that “most productive/top performers”). That is usually not the case. In most situations, the team leader has to work with the people assigned. This may require coaching, mentoring, adjusting work assignments to match with skills, or other actions. As mentioned above, if the work is being tracked, the team leader can make adjustments to keep making progress. If problems are still occurring after making adjustments, that data can support a conversation regarding resources/assignments.
To sum up, Westenberg makes some good observations about productivity within groups. I understand the digs on “collaboration”, but I would say that the teams and cultures described in the post have problems beyond “collaboration”, which my “three legs” mention above would address. Perhaps Westenberg should find some better teams to work with….
One more thing – use of Agile tools and concepts are meant to help teams be more productive. If that is not the case, the environment where the tools are being used should be examined. Perhaps there is a lack of will to have a “crucial conversation” about the story that the data is telling….
PS – I found this piece through a link from Dave Winer. I disagree with Dave Winer’s statement as he links to the Westenberg piece . People use different products to do different things. In most situations, standards have nothing to do with the selection of the products. Dave is focused on writing tools and communicating using social networks, and yes, if every social network service used the same standards/formats, there could be easy interoperability between writing tools for those social networks. However, as I have written before, there is not much incentive for companies/developers to cooperate, and users are not demanding that services have interoperability. I think Dave Winer should look to other examples rather that the Westenberg post to support his assertion.
