This document discusses modeling teams as objects in object-oriented design. It explains that object-oriented design requires a different way of thinking about decomposition that produces organizational architectures outside traditional structured design. An object has behaviors, knows private information, and interacts with others via messages and an interface. The goal is to create public interfaces that allow others to get what they want without knowing how the team implements its behavior, similar to a RESTful API. Examples of typical messages sent to teams and useful methods for responding are provided, as well as helpful and unhelpful object-oriented design principles.

1. If your team is an object,
what is its API?
(Object-Oriented Team Design)
Andrew Annett
@akannett

2. PLEASE NOTE
SLIDES ≠ PRESENTATION
• These slides are designed to be viewed in
conjunction with a human being talking and
interacting with you.
• They may not make much sense to you if you
were not at the live session.

3. The BIG idea:
Let’s talk with teams about
organizing work in terms they use
every day – object-oriented
design

4. Why is this important?
…object-oriented design is
fundamentally different than
traditional structured design
approaches: it requires different
ways of thinking about
decomposition, and it produces
software architectures that are
largely outside the realm of
structured design culture.
- Grady Booch, 1991

5. Why is this important?
…object-oriented design is
fundamentally different than
traditional structured design
approaches: it requires different
ways of thinking about
decomposition, and it produces
organizational architectures that are
largely outside the realm of
structured design culture.
- Me, 2017

6. Methods
An object can DO stuff:

7. An object KNOWS (private) stuff:
Methods
Variables

8. An object interacts with others
via messages;
it has
behaviour
Methods
Variables
Interface

9. Because it has
behaviour, an
object can be
thought of as an
“animated data store”
Methods
Variables
Interface

10. An object's autonomy doesn't
extend to choices
in shared
standards and
protocols
Methods
Variables
Interface

11. “You don’t send messages
because you have objects, you
have objects because you send
messages” – Sandi Metz

12. Private Kitchen methods + knowledgeMessagesPublic Restaurant Interface
Diner – Kitchen Object Relationship
Relationship is the infrastructure for tasks

13. What is an API*?
Technically, an API is a set
of rules that two sides of
an interaction agree to
follow. It’s implemented as
an INTERFACE
* Application Programming Interface

14. The value of an API
It decouples an object’s function
from its implementation
It makes future (internal) change
easier
Dependency on a private method is
a form of technical (and
organizational) debt

15. The goal of an API
Create public interfaces that allow
senders to get (or do) what they
want without knowing how your
team implements its behaviour

16. POST
GET
PUT
DELETE
RESTful* messages types
* REpresentational State Transfer

17. Work on this initiative
Add this team member
Do this thing differently
Can you also do this thing?
What are you working on?
When will you be done?
What skillsets are needed?
Who is dependent on you?
What skillsets does your team have?
What risks are you accepting?
What are your dependencies?
What will be delivered?
How is team morale?
Stop working on current item(s)
Reduce team size
POST
GET
PUT
DELETE
Typical RESTful messages sent to Teams

18. Work on this initiative
Add this team member
Do this thing differently
Can you also do this thing?
What are you working on?
When will you be done?
What skillsets are needed?
Who is dependent on you?
What skillsets does your team have?
What risks are you accepting?
What are your dependencies?
What will be delivered?
How is team morale?
Stop working on current item(s)
Reduce team size
POST
GET
PUT
DELETE
Story map, options board
Reteaming, Onboarding
Story map, options board
Release plan
Story map,
Skills matrix
Release plan
Issues board
Defect density plot
Throughput histogram
Dependency graph
Cumulative Flow Diagram
Happiness Index
Dependency graph
Skills matrix
Useful METHODS to respond to messages

19. Helpful OOD principles
S ingle Responsibility….
L iscov Substitution…
O pen/Closed (Extension/Modification)…
D ependency Inversion…
I nterface segregation……………

20. Unhelpful non-OOD principles
S ingleton
T ight Coupling
U ntestable
P remature Optimization
I ndescriptive naming
D uplication

21. If you’re a reader:
David A Taylor
Business Engineering
with Object Technology
Dave Grey
The Connected
Company
David West
Object Thinking
Sandi Metz
Practical Object-
Oriented Design in
Ruby

22. Thanks for your attention!
@akannett
andrew@leanintuit.com