Talk given by Phil Parker (Partner at Equal Experts) at ExpertTalks Sydney, 27th February 2018. Continuous Delivery requires “a close, collaborative working relationship between everyone involved in delivery” but - as you are probably all too aware - most organisations don’t structure teams (or software) to achieve this. This talk explores what the communications structures of our organisations really are, and how they should best serve the systems we design? A Continuous Delivery talk with no mention of Continuous Integration, virtually nothing on Deployment Pipelines and a real effort not to mention DevOps (people, teams or mindset!) This is a lot about Organisations and Domains (a definition of the latter will be forthcoming), but mostly it’s about People…

1. @parker0phil
CONTINUOUS
ORGANISING
DELIVERY
for

2. @parker0phil

3. @parker0phil
Smaller
Batch Size
a ready feature can be put in front of
real customers at little notice, with no panic
Continuous Delivery

4. @parker0phil
Continuous Delivery
“When speed and stability satisfy
business demand.”
* See also:
Discontinuous Delivery
Continuous Delivery *
Shorter
Cycle Time

5. Quantity (and complexity) of a
single unit of production
deployment.
@parker0phil
Response TimeBatch Size
single unit

6. ✗ ✓
(Smaller) Batch Size
@parker0phil

7. Wait time between an idea
(hypotheses) of a piece of value
and that value being in
production, used by a real
customer.
@parker0phil
Response TimeCycle Time
piece of value

8. @parker0phil
(Shorter) Cycle Time
✗
✓

9. @parker0phil
a close, collaborative
working relationship
between everyone
involved in delivery
extensive
automation of all
possible parts of
the delivery
process
How do we get Continuous Delivery?

10. a close, collaborative
working relationship
between everyone
involved in delivery
1. The team has a shared AND single focus.
2. No waiting for referrals.
3. Decisions are made using local context.

11. SCALING
AGILE

12. @parker0phil
Utilisation

13. @parker0phil
Utilisation

14. @parker0phil
Utilisation and Flow
Organisations that focus on utilisation tend to
see reduced flow and poor (effective)
utilisation.
Focussing on flow
improves utilisation.

15. @parker0phil
Utilisation and Flow
So if you want high utilization,
you should
develop in very
small batches.
“
”

16. @parker0phil
Utilisation and Flow
So if you want high utilization,
you should
develop in very
small batches.
“
”

17. @parker0phil

18. @parker0phil
Projects
ResourcePools
● Resources are owned by heads of
discipline
● Allocated to projects by resourcing
manager
● When projects end (allocated
portion of) resource returns to pool
Matrix Management

19. @parker0phil
● Teams are long-lived and
cross-functional
● Work is moved to teams rather
than teams formed around work
● BUT not long-lived product
ownership
Feature Factories
FeatureTeams
Products

20. @parker0phil
USER COMMAND %CPU
weblogic java 99.9
Over
Allocation

21. @parker0phil
Over
Allocation
● Failure to be able to deal
with unexpected demand
● Burnout
● Cost of context switching

22. @parker0phil
There is no such thing as
multi-tasking,
there is only
context switching.

23. @parker0phil
Service Teams
Service Team
Product Team
● Lack of ability to affect end-to-end
change
● Escalating cycle times through wait
delays
● Escalating batch size
Ops/DeploymentTeam
Change Approval Board
Security/Pen Testing
Business Sign Off
Service Any Referral Teams

24. @parker0phil
Over
Reuse

25. @parker0phil

26. @parker0phil
Domains
(Verticals)
Enablers
(Diagonals)
Communities
(Horizontals)
Domain Alignment

27. @parker0phil
Communities
(Horizontals)
Domains
(Verticals)
Enablers
(Diagonals)

28. @parker0phil
Communities (Horizontals)

29. @parker0phil
“It doesn’t make sense to hire smart people
and then tell them what to do; we hire smart
people so they can tell us what to do.”
“If you are the smartest person
in the room, invite smarter people,
or find a different room.”

30. @parker0phil
Enablers
(Diagonals)
Domains
(Verticals)
Communities
(Horizontals)

31. @parker0phil
Enablers
(Diagonals)

32. @parker0phil
Enablement Teams
● Self-service
● Optional

33. @parker0phil
Domains
(Verticals)
Enablers
(Diagonals)
Communities
(Horizontals)

34. @parker0phil
1. an area of territory owned or controlled by a single ruler
or government
2. (Computer Science) A group of networked computers that
share a common communications address.
3. (DDD) a sphere of knowledge (ontology), influence, or
activity
Domain
[doh-meyn]

35. @parker0phil
1. an area of territory owned or controlled by a single ruler
or government
2. (Computer Science) A group of networked computers that
share a common communications address.
3. (DDD) a sphere of knowledge (ontology), influence, or
activity
Domain
[doh-meyn]
An area of business capability owned AND controlled by a
single group
A group of people and systems that share common
communications.
A sphere of knowledge, influence, and activity

36. @parker0phil
“
”
organizations which
design systems ... are
constrained to produce
designs which are copies
of the communication
structures of these
organizations

37. @parker0phil
gather together those
things that change for
the same reason, and
separate those things
that change for different
reasons
SRPSRP

38. @parker0phil
Response TimeOrganising for Continuous Delivery
Domain teams own
systems that change
together and should
be able to deliver
value independently
of other systems
(and so, other
teams)
Reuse is good
(but comes at the cost of
dependencies)

39. @parker0phil
Response TimeOrganising for Continuous Delivery
Boundaries between
Domain teams (and
therefore systems)
are well-defined,
relatively stable and
not too granular
Communication is good
(but too much might be an
anti-pattern)

40. @parker0phil
Architecture
Cohesion
(high)
Coupling
(loose)

41. @parker0phil
Organising is what
you do before you
do something, so
that when you do it,
it’s not all
mixed up.
“
”
- A.A. Milne

42. @parker0phil
ThankYou!
@parker0phil
CONTINUOUS
ORGANISING
DELIVERY
for