Deployments and the Art of Team-Building
Most Recently a thought crossed my mind that struck me: Deployments in software development and team building have a lot in common. This leads to further thoughts on the future of team-building measures. Spoiler alert: I am asking for your suggestions on how the future might unfold.
At the beginning of this year, our team of agile coaches is glad having a new colleague. We believe that while all teams must mutate teams are also immutable. That’s why we consider our ‘changed’ team as a completely new team. Consequently, we used the first opportunity of having the whole team together (almost the whole team since some have been on sick leave) to re-do our team-building measures.
Teams are immutable and teams must mutate (Thanks team!)
I don’t want to dive deeply into what we have done to ‘build’ our team. Just assume that we designed activities around establishing trust due to the fact that we believe trust equals speed and speed is important.*
Moreover, I’d like to take a closer look at the commonality between deployments in software development and team building. Team building is still a thing and there are quite some team building activities out there that are crafted as an event. Teams go climbing, playing, hiking or what else. Interestingly we also have one day per year as a budget for the so-called ‘team-event’.
Some of the underlying assumptions to that practice seem to be that
- Building a team is necessary
- Building a team is burdensome
- Building a team is an event
- Succeeding a team-building measure, a team is ‘built’, which means is capable of fulfilling its purpose frictionless
The deployment analogy
Not too long ago deployments also have been considered as an event. Sometimes there also was one single deployment per year. That was the time to release shiny new features and solve nagging problems in the software (hotfixes aside). Here again, the underlying assumptions are
- Deployments are necessary
- Deployments are burdensome
- A deployment is an event
- After deployment, a product is (at least to some extent) ‘finished’
If you take the time and the context of those underlying assumptions into closer consideration you might notice that those assumptions have been true at some point in time. Deployments for bigger software artifacts have been painstaking. Especially if several teams have been involved. Testing and deployment infrastructures as we know them by now were unknown more than a decade ago. Since it was strenuous to ship a software product almost every company was doing it infrequent which caused no market pressure to update and release frequently. And users have been used to that common practice and did not demand more frequent release schedules.
Those times are long gone (for most of the companies) and the DevOps movement introduced the idea of ‘if it’s hard, do it more often’. Practices, processes, and tools evolved that allowed far more frequent deployments and increased the adaptability of teams and companies to now more rapidly changing market demands. That altered the underlying assumptions regarding deployments drastically.
- Deployments are necessary
- Deployments are automated and effortless
- Deployments are no-events and may happen all the time
- The product is never ‘finished’ and it will be changed until it is taken out of the market
Back to the teams
The context of a team for a very long time has been even more stable than the context of products and deployments. Teams (they might have been called departments) often existed for a decade or longer. The people in a team did not change significantly for many years. The context of the team and its purpose were stable for the time of its existence.
We can acknowledge that the fourth underlying assumption of team building seems absolutely legit under those boundary conditions.
4. Succeeding a team-building measure, a team is ‘built’, which means is capable of fulfilling its purpose frictionless
However, our working environment changed drastically and we can no longer assume that a team is stable — in terms of people working together or context-wise — for a very long time. Which alters the fourth underlying assumption to
4. A team is never ‘built’, it constantly has to adapt to its working context
That doesn’t render team-building measures obsolete as long as the first underlying assumption — team building is necessary — remains true. I think it is in order to create trust and strong bonds with each other.**
So if we still believe that we need teams and that
- team building is necessary and
- that team building is necessary for every new team and
- that the ever faster-changing contexts of teams lead to faster changing teams
than we notice that the assumptions
2. Building a team is burdensome
3. Building a team is an event
seem somewhat contradictory to the necessities we are facing in our current working environments. In other words, the inability to change those assumptions is the inability to change our behavior. This has consequences. We avoid burdensome events. And the frequency in which we perform team building doesn’t keep up with the frequencies of the changes imposed on the teams. Ultimately this deteriorates the teams’ capability to collaborate adequately and it decreases the teams' results.
Now we have to figure out how to prove the underlying assumptions wrong in the same way the DevOps community did with the deployment***. We aim for continuous team building that is a fun non-event.
But how?
Any suggestions?
* Related to ‘The SPEED of Trust: The One Thing that Changes Everything’ by Stephen M.R. Covey
** I know that there are advocates who disagree vividly with that thought which in itself is based on underlying assumptions that are challenged by those advocates.
*** And Ohno did at Toyota in the 50s to allow smaller batch sizes in car manufacturing
