by Thierry de Pauw on
Mastery in Software Development Teams, Emily Bach, @emilybache
Job adverts ...
looking for a cowboy, ninja, ...
they are looking for a very productive engineer
About 10x Engineer
Book mentioned by @emilybache: Rethinking productivity in Software Engineering
distribution of work for 73 developers:
mean time: 7h
one developer: 40min
one developer: >73h
They also looked at what they produced.
There might be 10x developer, but there are developers that are 10x worse. You want to avoid these. @emilybache
Story: New to the Team
This thing about individual productivity is a minefield. What we really want is team productivity. @emilybach
What makes a great Software Engineer? Research by Microsoft
There are 53 attributes:
- personal characteristics
- decisions making abilities
- work with teammates
- work on software products
Being a great software engineer is not only about code. @emilybache
Research from Google: project Aristotle
What factors influence team productivity?
- psychological safety
- dependability: doing what you said you would do
- structure & clarity: clear roles, plans and goals
This concept of team productivity seems to be lots more important than individual productivity.
Accelerate: Research into the state of the art in DevOps
two important findings:
- effective development matters for organisational success
in last 10 years, a lot of companies outsourced IT because IT is a cost
it seems that was wrong
the most successful organisations have the best IT
- you can measure a development organisation and compare with your peers
Behaviours => Metrics => Success factors
Great software is built by empowered, autonomous teams
the research is very specific about what that is:
empowered teams can:
- perform large-scale design changes
- without detailed coordination outside the team
- deploy on-demand
- do their own testing
If I would say that to some of the teams I work with, it would be a disaster.
You cannot just say: now you are an empowered team.
For this (empowered teams) to be true, you have to have architecture. And your architecture has to be aligned with your organisation. @emilybach
Supporting empowered teams:
- CD pipeline
- architecture advice
- standard tools
This quite stands against traditional architecture.
Architects can't dictate from on high
- teams should have the power to decide
=> technical leaders are servant leaders at the bottom of the organisation
My experience as a technical leader in building a test automation framework.
What I did wrong: I spend too much time on my own and too few time asking the teams what they want.
This is a basic agile principle: ask your customer what they want.
Since then I've done a lot of mob programming with teams.
All the brilliant people working on the same thing, at the same thing, ...
-- Woody Zuill
- Mob member
- Rotate roles often
Working agreement for Mob Programming:
- we treat everyone with kindness, consideration and respect.
Books on Mob Programming:
- Mob Programming, Woody
- The Mob Programming Guidebook
Isn't that really unproductive?
I have 5 people working on one thing where it could 5 people working on 5 things.
That hasn't been measured (yet).
But other studies on team productivity say: safety, less context switching
Everyone understands the code you mob on (that's from where the name comes from: everyone is responsible for the code produced)
- team learns to collaborate better
- skill transfer
- visitors can very quickly become contributors
Technical Coach mob with all the teams:
- teams are empowered
- technical coach can see needs and influence decision without dictating
About the 53 attributes found by Microsoft: it says also coding skills
=> Book: The Coding Dojo book, Emily Bache
Summary: Achieve mastery in software development teams:
About the 10x dev myth: most developers are ok, they do more than just coding.
We need architecture and we need architects. But ... not dictating. We need architects that give gifts.
Use Mob programming to find out what gifts a team need.