Software Delivery, Teams, & Togetherness
The only thing that beats a good experience is a shared one and shared(> 1 brain) software delivery is really hard.
SimBu 2023_
There is a lot of great articles, studies, examples of how to be a modern business with high performing teams, to embrace change and be more agile in your approach, for me there is not enough emphasis on working together, it gets mentioned in most approaches, but that tends to be it.
From school onwards we are taught to collaborate but not really encourage to work together on the same tasks regularly.
Invariably when we go back to our desks, our safe place, our ideas and opinions start to differ.
Does this thinking come from historical thinking, divide and conquer, the industrial revolution, and the profit motive ?
What approaches should we use today ?
Competing in today’s world where you are never much more than 30 seconds away from using a cpu of some kind, has challenged executives and management to transform the way their organisations work.
Its difficult for organisations that are using the traditional command and control approach to change.
To change, those that issued the commands need to listen, guide and facilitate and those that carried out the instructions need to understand, continuously learn, and adapt to constant change in processes and networks.
It needs more collaboration, more sharing and more openness:
Privacy <-> Transparency
In the past, information was the currency of power: hard to come by and hard to spread. In the industrial-era environment, organisations guarded this scarce information carefully, and leveraged their information as a competitive advantage.Today, we have access to so much information that it’s become impossible to predict which information might be useful, or who might use that information in a productive way. In this world of abundant information and connectedness the potential benefits of trusting people who share the organisation’s purpose to act on information as they see fit often outweighs the potential risks of open information being used in counter-productive ways.
From the Responsive Org — Manifesto
Is there any advantage or excuse for keeping secrets in organisations, excluding the laws around privacy ?
For instance what would having your salary next to your position mean, assuming you consented ?
I’m not going to answer this, but just say that secrets don’t help togetherness, purpose, so maybe melt those icebergs ?
Alistair Cockburn has spend more than 20 years studying how to design with teams:
He doesn’t solutionise, he just points out that people have to constantly learn new skills and processes, to network and form teams as needed at all levels, to be aware as a team, have each others backs and to be tolerant of differences and moods, to be prepared to experiment to learn fast, to look at the whole process and remove road blocks and to trim the number of functions to get stuff out the door.
He warns this is all theory, that you have to get your hands dirty with real people.
Ask yourself, is your office often like a library, but everyone is extremely busy are your meetings monologs ?
If so, its unlikely that people will form networks, teams and adapt quickly to change.
Responsive organisations form teams that are noisy fun places to be and you need that level communication and energy, to raise your heart beat and engage.
Getting your hands dirty requires exposing your soft underbelly, if I work with that person will I show my weaknesses, this is particular pertinent when it comes to programmers who may closely guard their skills, or lack of.
When teams work you feel part of it, you can be immediately open with people, over discussing things with others away from the team. You will try to raise other members moral, getting them believing when they start to doubt or are just low, introducing new ways and ideas when things start to fail, you will spend social time with the people on the team and it will be great fun, have a purpose. I’m talking about sports like football, tennis but it equally applies to those networks and teams at work, its just not so obvious as to where the team boundaries lie, or should lie.
In software delivery you often have this type of situation:
You will need some version of the three+ amigos to build cross functional teams, networks, to stop the blockages and remove the waste, but more importantly by working together on design and delivery tasks those networks can build strong teams, that start to share common language across boundaries, an understanding of the whole.
If its really broken, collocation maybe a good option, because people will react when they over hear the issues other functions are facing, its one of the strengths of start-ups.
Don’t impose processes like Scrum, let the teams that emerge to work on design, decide on each project which processes and tools they can use and have an easy way to build and share knowledge on processes and techniques.
How we work together in teams of unpredictable people is at the heart heart of how we design and deliver software, the processes and tools are only useful once you get that right.
Command and control works but is not competitive and leaves a bad taste, creates stress:
With every decision having economic consequences, those doing the work, reacting to change need to earn the trust if they want the controls to be reduced and eventually removed.
Aim to work together in a fun way, in a safe environment and concentrating on the ideas, doing exciting things together, building places and processes we want to be in and use, aim for brilliant shared experiences.
It maybe difficult to make changes if the light is not on in the organisation you work for, which will make change extremely difficult but hopefully all organisations are waking up to the responsive manifesto and changes at large.
I was working with a new dev this morning and introducing him to the laws of TDD when we strayed onto the subject of individual opinions in the code base.
When I showed him the diagram above on code opinions, he read the bit about feeling safer at his desk than with others and about working together more often and learning. He said that some people don’t like to work that way felt he could learn on his own and not whilst working with others, which is good feedback.
If he read this article he may agree in principle, but probably not in practice, but that is when he is reading and thinking alone and this is one of the biggest challenges and why I feel you need to experiment with group working, at least pairing up.
One other interesting thing that came out of the morning on TDD was that his typing skills are poor at best, so thats something that is easy to fix and would really help his productivity, keeping his focus on the design and development and not the mechanics, to make him a better craftsman.
Its a simple change but a good one that surfaced whilst working together.
I would advocate working together often, making it the norm instead of the exception, get closer to those around you and see what happens.