Blog @ andreaprovaglio.com

In his recent blog post, Pierluigi Pugliese asks the question "what is emerging today?", referred to software production teams. That's something I've been observing and working on, so I'd like to share a few thoughts about that here.

A musical anecdote

During a live TV interview, Daniel Barenboim (a world-known classical pianist and orchestra conductor) had the full orchestra with him in the studio. At some point during the interview, he went to the orchestra, told the instrumentalists to play the first chord of a certain piece, gave them the hand signal and immediately the room was full of a perfectly harmonious sound. He then instructed the instrumentalists not to play, gave them the hand signal and... of course, no sound.

He continued the interview explaining that a conductor should always remember that he's the only musician not to be directly connected with the production of sound and that, if the instrumentalists are incapacitated or unwilling to play, he could wave his hands as long as he wanted, but nothing would happen.

He concluded this part reminding the instrumentalists that, for the very same reason, they should not expect to be animated by the conductor, but should instead take responsibility of their role.

This is a beautiful metaphor of some of the dynamics at work in many teams, inside and outside the IT industry.

The part that I find more interesting is the use of the words "incapacitated" and "unwilling", because here we are not talking about the physical gestures for producing a sound, but about the intellectual and emotional activities that make the difference between striking a key and playing music.

These emotional and intellectual activities are completely outside the control of the conductor and require, to the instrumentalists themselves, a great amount of competence and self-awareness to be dealt with professionally (meaning that, sometimes, even an instrumentalist may not be aware of being partially incapacitated or unwilling to play).

On software industrialism

I think that there has been a serious misunderstanding in the last few decades about how to develop software: someone thought that creating software is similar to a production chain (the Waterfall Model being a manifestation of this mindset).

Someone thought that, in order to generate revenues by selling a software product, what they had to do was to replicate the model for creating tangible products (a chair, for instance): start with inception, then design, then build, then test, then sell. This model works very well in a production chain because, in that context, people are employed as mechanisms of a production process - an approach that may yield some result, as long as those people are employed for their arms and hands only.

But software is not the product of someone's hands, it's a product of the human intellect, and not just the intellect of a single person, but a team's collective intellect, which includes all the subtle dynamics and interactions among people.

And no, it's not possible to instruct someone to be creative, communicative, cooperative if they are unwilling or incapacitated to do so. The attitude for being creative, communicative and cooperative can only originate from the individuals.

Pushing the limits

There is another reason why producing software is different from producing tangible products; it's the fact that, with software, we are constantly pushing the limits of what we are building.

With a tangible product such as a car, for instance, there are physical constraints to what we can build. Also, a car is relatively stable kind of product: although different models may have quite different features, all cars have an engine, four wheels, a steering wheel and so on, which means that the process of making a car can be, for a large part, industrialized and automated.

That's not the case with software: software is an intangible product of the human intellect and its production is not limited by many of the physical constraints that we have with tangible products.

For example, when building cars we would think vary carefully about doing something radically different and innovative, because of the considerable costs, risks and efforts that it would take to re-industrialize the production process; with software, not only that is easier (not easy) to do, but it's also desirable and it accounts for a large part of the competition strategies on the market.

It's no surprise, then, that software development can't be really industrialized and automated. What's surprising is that, although software production depends so critically on the people's intellects and on social dynamics, a large part of the IT industry pays so little attention to those and, instead, keeps considering development teams as if they were a production chain.

Indications of change

There are indications that something is changing. The most evident one is the increasing diffusion and adoption of Agile methods which, in one of their founding principles, state very clearly: "we value individuals and interactions over processes and tools".

Also, virtually every day there are comments and insights from well-respected IT professionals that, in one way or another, point to people dynamics.

For example Aslam Khan wrote in a recent post about processes vs. discipline, a remark that is somehow connected to the Agile principle stated above.

Rickard Öberg recently wrote about system thinking and an holistic approach to software development, a position that I largely agree with, although I find the concepts that come from organizational systemic and other humanistic schools to be more useful.

Finally, there are a few experienced Agile practitioners and coaches who mix the Agile processes with practices and techniques coming from different branches of human psychology.

Criticism to current change trends

Although I welcome this trend in all its many manifestations, I feel that in many cases the results fall short of addressing the core of the matter.

For example, the principles of the Agile Manifesto (which I value), just scratch the surface of the complexities of human interactions, although they definitely provide an authoritative and fundamental hint about the relevance of individuals and people dynamics in software production teams.

The Agile practices, such as daily stand-up meetings or pair programming, and the Agile processes such as XP, Scrum and so on, are frameworks in which change may happen, but cannot per se generate change in unwilling or incapacitated individuals.

I also find that many of the current approaches that mix the Agile practices with psychology originate from a flawed motive. The motive is that production is suffering and we need to fix that. The solution is to find the bottlenecks or defective parts in the production process. Since we are starting to realize that people are of the utmost importance in software development, to improve a suffering production we apply some psychology to fix the "defective" part: the people.

Unfortunately, individuals cannot be fixed. Individuals can only improve if they are willing to, if they possess that capacity and if they are properly supported along the way - just like in our initial anecdote.

What is emerging

What I think is emerging today is a (sometimes undefined) awareness that the only real improvements lie with the individuals and with their own capacity to relate to others; and that processes, practices and techniques can only support those improvements and provide a framework for them, not generate them.

Team members, as the instrumentalists in the anecdote, should take responsibility that they are the ones who "produce the sound"; that they are also elements of a larger team; and that they are also, all together, guided by someone who has an overall view.

Leaders, as the conductor, should realize that their primary role (in addition to planning, strategy and so on) is to create an environment in which the individuals can develop their technical and relational skills; and possibly inspire and guide that growth, keeping in mind that production is in the hands of the team, not theirs.

In both cases, the possibility for change, the development of the skills required for both roles, lies with each person's willingness and capacity to improve, first of all as an individual; it cannot be imposed neither infused.

I think that this change is already happening and that it will manifest itself at first in organizations where social dynamics and personal improvement are a fundamental value; and that the role of us who coach is to support this change for those who ask us, at any organizational level, to the best of our competence, skills and humanity.