Systemic Software Development
Printed from http://andreaprovaglio.com. All rights reserved.
An approach to functional IT teams
Industrial software development is a complex activity which, in addition to dealing with technical issues, has to face a number of other challenges, including: economical factors (budgets and efficient use of resources); commercial factors (providing valuable products at the right time to the people who need them); strategical factors (foreseeing what’s going to be needed); and dealing with people dynamics.
Also, the widespread diffusion of software, plus the fact that it has a direct or indirect influence on the everyday life of millions of people – not just those who work in this industry, but most of all the end users – has made software development a social responsibility in addition to being a business.
Partly to address its own challenges, partly because of spontaneous interactions, in the last two decades software development has come out of engineering departments and it’s been influenced by other disciplines and practices, including cognitive sciences (design of OO Languages), architecture (Design Patterns) and car manufacturing (Lean methods).
Software has also first provided the infrastructure for the Internet and later allowed for the growth of Social Networks, which are the mechanics for a form of collective intelligence; and many of the teams that produce software today are cross-functional teams, where individuals from different domains and with different skills work together and complement each other.
However, the success of an industrial software development project (being delivered on time, on budget, providing the most valuable features to the users and without major defects) plus the short-term and long-term quality of the technical artifacts, are hardly just a technical matter. Instead, they are largely dependent on the way in which all the people involved in the project are able to communicate and cooperate.
So I think that a part of our industry is now ready to integrate and balance its current practices and processes with some humanistic concepts, which take into account people dynamics and the fact that the society, companies, organizations, teams and individuals are all part of the same system.
The Model
This model for functional teams is built on four basic elements: Communication, Collaboration, Agility and Technical Proficiency.
Communication
In this model I define Communication as a person’s capacity to share his/her knowledge, ideas, intuitions, emotions and needs.
As such, communication primarily implies the development of Personal Awareness which means, in the first place, possessing clarity of whatever we want to communicate, and then possessing the practical skills to communicate it.
Sharing knowledge and sharing needs are, of course, substantially different: in the first case we usually pass on to others something we learned from someone else – and therefore it's not really "ours"; in the second case, when we express our needs, we are letting people know about something that’s very personal to us, occasionally almost intimate. To complete the picture, the other three subjects (ideas, intuitions and emotions) fall in-between those two extremes, creating an ordered sequence that ranges from impersonal to personal.
Another difference between communicating knowledge and communicating needs is that, in our industry, communicating knowledge usually means to share technical information, an act frequently done by means of tools and/or artifacts (source code, sketches, etc.); on the other hand, communicating needs is related to the social dynamics of the team (for example: "please, I need more silence to be able to focus, to fix this bug on time for our imminent release").
Despite the differences mentioned above, communication is still an individual’s capacity, a capacity that’s highly required for someone who wants to interact effectively within a team, both from the technical and the from the social point of view.
To improve technical communication, I coach my partners on using consolidated practices, such as Design Patterns and Refactoring, which I integrate with the group’s specific semantic constructs.
To improve social communication, I apply some elements of Neuro-linguistic Programming (for clarity) and Nonviolent Communication (for identifying and expressing needs).
I’d like to stress that I think at technical and social communication as a continuum, not as distinct areas, where each side may positively influence the other.
Collaboration
I define Collaboration as the capacity of a group of people to work effectively together towards a common goal.
Since the interactions within the group – and between the group and its hosting environment – can be complex and their effects can be far-reaching, collaboration implies the development of Collective Awareness, which means transcending the individual and being able to perceive the effects of one’s actions, words and thoughts in a larger spatial and temporal context.
To support Collective Awareness I rely on two other elements: Systemic Thinking and Social Behaviors.
Systemic Thinking, in this model, is based on the notion that everyone in the team (from ownership to management to production) and everyone outside the team (from customers to suppliers to the society at large) is part of the same system; and that every single action, word and thought resonates throughout the system and generates a productive or counterproductive effect, sometimes unnoticeably, sometimes dramatically; also, the model takes into account that each system has its own history and rules, and that the present state of the system is influenced also by its past. Learning to explore and understand these relationships is an integral element of this approach.
A natural consequence of what’s stated above is that it's better to encourage those behaviors that are productive for the system, and avoid those that are unproductive. I call this practice Social Behaviors, which means learning to identify and support those behaviors that help the group, in the short and in the long term, towards its common goal and to avoid those that don’t. In essence, it’s a process of learning which behaviors – at the individual, organizational and social level – create cohesion and which ones create separation (separation happens when an element of the system becomes “detached” and stops participating).
From a more practical point of view, two other factors come into play. The first one is guidance, which the group will require to be able to collaborate effectively. This may come either from self-organization or from leadership – but more frequently from a combination of the two. The second factor applies to large, geographically dispersed organizations, where direct person-to-person Communication may be impossible on a daily basis; in this case I recommend and coach my partners in the use of Enterprise Social Software to provide guidance, coordination and sharing, keeping in mind that such tools yield better results when used according to the principles described here.
Agility
Agility is a team’s capacity to respond and adapt effectively to change along the duration of a project. To do this, we rely on specific Processes and practices.
There is a substantial body of work on this subject in our industry, whose excellent principles are stated in the Agile Manifesto, so I won’t spend many words on the practical implementation of Agile methods (and Lean methods as well) here.
What is more interesting to me, in this context, is what we can do to support, extend and enrich the people-oriented characteristics of the Agile methods.
One part of that is how to choose a specific Agile or Lean method for a specific partner with a specific project, which in my opinion depends largely on the people involved. How do these people usually communicate? How much aware are they of the collective dynamics in their system? Do they feel more comfortable with self-organization or with leadership? What is the level of change and improvement that is possible in that context?
The reason for these questions is that different Agile and Lean practices and process have (consciously or unconsciously) different people-oriented characteristics, and finding the best match between those and the team is quite important, not only for the adoption of the method itself, but especially because of the positive influence that an Agile method can have on the individuals and therefore on the group as whole.
Another part is that the Agile methods focus primarily on how to respond to technical change (for example: requirements). However, sometimes change may happen at a more profound level, such as a change in the organization, in the mission or vision, or in the collective goal in a wider sense.
For me, Agility includes the capacity for a team to respond to this kind of change as well; teams and individuals that possess a good capacity to communicate and collaborate, and are properly guided, have a better chance to succeed.
Technical Proficiency
Technical competence is essential in an IT team. In my opinion, however, there are other skills that, together with competence, can help a person to perform the technical tasks required by his/her role in a software production team; these skills are a set of Intellectual Tools.
The set includes: competence on Programming Languages and Best Practices, because those are a major communication channel for developers; familiarity with Architectures and Platforms, which represent a form of collective knowledge in the industry; Design, especially with Patterns which is another form of communication; but most of all Abstract Thinking, which is the capacity to see beyond the form, and therefore to be able to address problems at their core.
While building competence results primarily by practicing and by being with more competent people (peers or a coach), abstract thinking – a faculty we humans have – tends to develop more easily when it’s consciously cultivated and guided.
Therefore, when I’m with a technical team, in addition to the providing technical information, I recommend considering the technical artifacts of the team (source code included) and the architecture as a form of systemic communication, and I provide guidance on how to do that. I also encourage and guide the team to find the resolution of technical problems applying a combination of pragmatism and abstract thinking.
Systemic Software Development
The model I discussed above describes in fact an active system with dynamic and dialectical interactions connecting Communication, Collaboration, Agility and Technical Proficiency.
The most relevant interactions are:
- Communication and Technical Proficiency are capacities of an individual
- Collaboration and Agility are capacities of a group
- Communication supports Collaboration
- Collaboration is where we practice and refine Communication
- Agility is where we practice Communication and Collaboration
- Technical Proficiency, Communication and Collaboration support Agility
- Agility helps individuals to share and to develop Technical Proficiency
In these terms, I think at a software development team as of a living system whose dynamics, when balanced, allow for the growth of the system itself and of the individuals who constitute it.
That system is itself part of a larger system, which is the organization where the team lives; and that organization is in turn part of a larger system, which is the society. The growth and prosperity of all these elements is interrelated.
In this web of relations, Integrity is quite a boost for growth. I define Integrity, in this context, as a form of alignment of what we do – and how we do it – with what we value and believe in. The effects of this level of integrity positively affect individuals and organizations alike.
An industrial software development project is, of course, also an activity where practical, economical and strategical problems come into play – I didn’t discuss those because we know them well. I find that thinking at the team in a systemic way doesn’t neglect any of these issues; instead, it activates more resources to face them, and can help building more productive and reactive technical teams, who are able to grow technically and relationally as they go, and in the process to contribute to the growth and prosperity of the larger system in which we all live.
