What attributes do an Agile team have, what does Conway's law have to do with architecture and why does it matter. How do we implement this for our own teams. What advice do you have and what can we learn from the past

1. The session will start shortly…

2. Agile Teamworking
Carolyn Hill - Project Manager
Scott Russell - Devops Advisor

3. Developers, Developers, Developers, Developers
“Teams, Teams, Teams,
Teams”
3
Not the “Steve Balmer”
quote we were looking for

4. Agile Teamworking
1. Team is the default unit of work
2. Inter teams communication
dictates “architecture”
Ref: Conways Law
3. How to do this at home(the new
workplace)
Agenda
4

5. 5
No individual stands alone in the team.
Everyone’s success depends on the teams
success
“Default Unit of work”

6. What are the attributes of an Agile team?
Attributes
6
5-9 People
Storming
Performing
Forming
Norming
Empowerment
People Man. v Teams
Long Lived
Team not
Individual
Perf.

7. 7
Enabling Platform
Complicated - subsytem
4 Types of teams
How Many?
Stream

8. Collaboration
8
<x> as A Service Facilitating
3 Ways of Interacting
Team Connections

9. 9
How teams talk to each other, has
ramifications not just for team overhead, but
also in terms of the architecture that they
implement - Oh noes!!!
Inter-Teams Communication

10. “Any organisation which designs
systems is doomed to replicate
their internal communications
structure into the architecture of
the new system”
10
Conway’s Law

11. 11
Not a random selection of individuals
Team Design (Organisational design in drag)
● Whilst setting up the team, the realisation that you are in fact designing
the architecture of the application
● Involve the architectects of the application in the setup and
instantiation of the teams(reverse conway maneuver)
● Be aware of the natural fracture planes, at team boundaries
● Empower the team designers to alter the organisational structure

12. “Just as empowerment
without sharing fails, so does
sharing without
empowerment”
12
General Stanley McChrystal

13. Team of Teams
● “Eyes on - Hands Off” leadership
Teams break down when…
○ the edge of the team meets the
wall of the silo
○ Brooks Law ”adding people to a
late project makes it later”
General Stanley McChrystal

14. Working with other (Silo)teams
● Use a team liaison person to breakdown silos. The person
either comes from the silo into your team, or you assign the
person to the Silo team.
● Choose wisely:
○ If it does not “pain” you to give the person up, pick
someone else
○ If you would not recognise their voice on a call at home at
02:00am in the morning, pick someone else
Enterprise Integration

15. Appropriate times for communication
● Inter team communication helps during discovery
● Unneccessary team communication impacts execution
● Not everyone needs to know everything
● Orginisational design trumps software architecture - Oh noes?
● Restrict teams to one “complex” or “complicated” domain or a
subset of the team to one domain where that will reduce the
cognitive load
pathways

16. Designing the team API(interaction with others)
● Cognitive loading - what is it and how do we measure it
● Context Switching, and maximum number of domains that a team
can handle.
● Design the “Team API” - or Ways of Working and Interacting with
and within the team
● When you are designing the teams structure for a given project, be
aware that you are inadvertently designing the architecture of the
system(Conway’s law). So be sure to involve the
architect’s/technical software/system experts in the design
decisions. Remember team communications channels, forma and
informal
Interactions are useful

17. Everyone has boundaries, Teams do, too.
● Be aware of the “software boundaries”.
● What are the business domains that are currently in use
● Can we map those boundaries, whilst ensuring domain
separation (ie are they affected by conway’s law?)
● What other fracture planes can we use to assist in separating
teams
Don’t cross the line…..

18. 18
No Metrics here
● Measure the informal communication structures
○ Hold a communication discovery workshop
○ Ask everyone to list all the groups/critical individuals they
communicate with in slack/teams/discord/email.
Important to “ask”. Do not data mine your team.
● Map the current architecture to the current communication
channels. Is the architecture being influenced by the
communication channels?
Measurement helps(to identify Conway’s law violations)

19. 19
Let’s talk about some steps you can take to
implement teams as the default unit of work,
whilst impacting the architecture in a positive
way - “the reverse conway maneuver”
How to do this at home(the
new work environment).

20. 20
“Instantiation”

21. “Reverse Conway Maneuver”
21

22. What to be aware of
First steps
22
● Use “Reverse Conway Maneuver”
● Involve architects, or architecture
roles in a distributed architecture
setup for team design
● Run a Ways of Working workshop with
each team, and between teams that
communicate regularly
● Run “many” refinement sessions.
These are tiring but necessary for
forward velocity, especially early on
in the team lifecycle
● Start executing, from the first
sprint, by delivering value to the
business
● “Always be getting to production”
● Establish clear boundaries of
responsibilities for teams
● Restrict team responsibilities to
match the maximum cognitive
load - important
● Involve the team in the planning from
day 1

23. 23
“Execution”

24. Someone has to do the work
This is the value add
24
● During Execution phases of the
project, reduce non - execution
comms to near zero
● Map out the communication
structures between teams, not the org
chart(this is how work actually gets
done, based on interpersonal and
inter-team reputation)
● Organisational design prevails over
software architecture design -
(remember Conway’s law)

25. Prioritisation is a real world problem
Prioritisation is an actual realworld issue
No.
of
Stories
TImeframe ( 1 year )
Business
Demand
Actual
Delivered by
Agile Team
X4 times
more demand
than actual

26. 26
Reflection

27. Recall and reflect on past events
● Hold retrospectives, at key points on the journey
● Mix up the retrospectives, use different
techniques depending on the contex eg.
good/bad/ugly, KALM, Keep/Add/More/Less
etc
● Use Futurespectives to remove immovable
barriers by projecting forward in time and
reflecting back on how the team solved the
impossible.
● Use slack/teams/Zoom for your Retros. Stop
adding more tools to do simple tasls
Looking back is how you remember

28. Any questions?
Please enter your questions
using the Q&A tab on the
right hand side of this
screen.

29. 29
Contact
Carolyn.Hill@Nordcloud.com
Scott.Russell@Nordcloud.com
SLidedeck:
https://www.slideshare.net/sc0ttruss/

30. Thank you for joining us!