CodeCraft – Architecting Teams Notes and follow-up

Thanks to everyone who came to the CodeCraft guided conversation last week. I’ve added some notes to the questions below to carry on the discussion, and there’s a few topics I want to revisit in this blog, and in DDD Scotland if my talk is accepted.

The code craft team did a great job of reviewing and improving the questions so thanks to them, but I think in the very busy session itself, some of the questions were too ambiguous. For example, when I was thinking about goals, I was thinking about project goals and strategy goals rather than just “Make more money”, but I suspect that’s as much to do with the ambiguity many people have about their company strategy and culture in general.

It was also interesting to me to hear how agile is interpreted. The agile manifesto is clear that people take priority over procedures, and software over documentation, but explicitly the authors “still value the things on the right”. So it’s not about no procedures, and no documentation (please tell me you have coding standards), it’s about the right ones to support the people, the delivery of working software, etc. rather than documentation in its own right. Indeed, there are a number of explicit rules that an agile team needs in order to function. Is there a framework? What is the lifecycle of a unit of work? What language are we using? Not all of it needs to be documented, but some of it absolutely does, especially if you want to understand and improve it, and remove the rules you no longer need.

Be wary of anything that interrupts transparency, whether it’s Chinese walls, secret tasks, hidden agendas or ninja developers who work in the shadows and surprise everyone when they’re least expecting it.

And it’s never just enough to say who you are and what you do. Promote, encourage, and challenge. Be proud to be a diverse employer, to be wheelchair accessible, to have staff with more than 2 years real world experience, and welcoming to fresh faces with new ideas.

Trust. Respect. Communicate.

As a general point, I’m thinking of a team as “the people you work regularly with, usually daily”.

1. How do you keep track of your team and the company goals?
2. How does your team manage risk to and changes to those goals?
   • Pre-mortem
   • Chaos monkey
   • Agile “threw away risk register and other important documents”
3. What makes a great team?
   • People
   • Feel comfortable
   • Trust
   • Communication
   • Balance
   • Good Leader
   • Sustainable development
   • Transparency
   • Healthy Debate
   • Growth and change
   • Common Goals
   • Motivation tailored to each person
   • Rules
   • Raise concerns
   • Feedback should be timely and structured
   • Coding standards
   • Process rules (e.g. how do we report a story can’t be implemented, what’s the weekly schedule)
4. What would you change about your current team?
   • Management
   • Decisions made outside the team, not taking input from the team
   • Coaching developers to talk to management
   • Wrong person promoted to lead
   • Too many rules
   • “Because we’ve always done that”
   • Needs the context of why that rule exists
   • Clear roles
   • Respect for decisions the team has made
   • No secret tasks
   • Co-located, or remote, not mixed.
   • No “them and us”
   • Manager vs developer
   • Techie vs non-techie
5. What makes you feel unsafe in a team?
   • Lack of:
   • Support
   • Communication
   • Respect
   • Goals
   • Secret genius / hero developer who does their own thing
   • Decisions made without buy-in
   • Teams without source control
   • No tests
   • Secrets
   • Success at the expense of others
   • Developers are not “resources”
   • And managers are not “overhead”
   • Fear
   • Stagnation
6. How well would your current team survive a conflict?
   • To survive, have Strong Opinions, Weakly Held
   • Have a “naughty step” project for someone who doesn’t follow the rules, or doesn’t respect the team
   • Avoid imbalance in workloads that lead to loading stress onto key individuals
7. Should teams change when projects change?
   • Teams should be mixed to avoid stagnation, but not completely break them up
   • Good teams can inspire others
   • Every good team cares about the product they produce
8. How does the culture of a team change as it grows?
   • Negatively. Easily leads to “Us vs Them” (e.g. backend vs frontend vs DBAs, developers vs testers)
   • Lines of communication fail, especially as distance increases.
   • Old vs new – “I prefered the company when it was smaller”
   • T-shaped individuals are better collaborators
   • Tribe structures can help by allowing multiple communication lines
9. What kinds of diversity should we seek in the teams we work in?
   • Diverse teams build diverse products
10. Should we recruit to enforce the current culture or diversify it?
    • Put accessibility positively on ad when true (wheelchair accessible, BSL-friendly)
    • Do you know the current culture?
    • What is “culture fit”?
    • Does anyone know your company values? (not just the 5 Apprentice team names on the posters around the office)
    • Get job adverts reviewed by as diverse a team as possible
    • Diversify where the jobs are advertised
    • Not every candidate has 20 hours for a coding exercise, or wants to give up 2 holidays to pair with you
    • Coding review should be blind
11. What one thing can a leader do to make a team great?
    • Trust
    • Delegate authority and empower the team
    • Protect the team
    • “Reading the room” understand what’s not being said so you can investigate
    • Push everyone to improve (including yourself)
    • Empathy
    • Happy people
    • Communicate
12. Are effective teams a democracy or a dictatorship?

codecraftuk-sessions/architecting-teams.md at master · craignicol/codecraftuk-sessions · GitHub