Talk given by Phil Parker (Partner at Equal Experts) at ExpertTalks Manchester, 18th October 2017. 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
Smaller
Batch Size

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

11. 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.

12. SCALING
AGILE

13. @parker0phil
Utilisation

14. @parker0phil
Utilisation

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

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

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

18. @parker0phil

19. @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

20. @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

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

22. @parker0phil
Service Teams
Service Team
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

23. @parker0phil
Over
Reuse

24. @parker0phil

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

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

27. @parker0phil
Communities (Horizontals)

28. @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.”

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

30. @parker0phil
Enablers
(Diagonals)

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

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

33. @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

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

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

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

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

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

39. @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

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