Delivered by Phil Parker as part of the Agility in Business track at Agile on the Beach, Cornwall, July 7th 2017. https://www.agileonthebeach.co.uk/agenda/session/172717

1. @parker0phil
CONTINUOUS
ORGANISING
DELIVERY
for

2. @parker0phil

3. @parker0phil
``

4. @parker0phil
`

5. @parker0phil
`

6. @parker0phil
Shorter
Cycle Time
Smaller
Batch Size
“a ready feature can be put in front of
real customers at little notice, with no panic”
Continuous Delivery

7. @parker0phil
Continuous Delivery
“When speed and stability satisfy
business demand.”
* See also: Discontinuous Delivery
Continuous Delivery *

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

9. ✗ ✓
(Smaller) Batch Size
@parker0phil

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

11. @parker0phil
(Shorter) Cycle Time
✗
✓

12. @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?

13. @parker0phil
``

15. a close, collaborative
working relationship
between everyone
involved in delivery

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

17. SCALING
AGILE

18. @parker0phil
Utilisation

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

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

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

22. @parker0phil
`

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

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

25. @parker0phil

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

27. @parker0phil
Over
Reuse

28. @parker0phil

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

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

31. @parker0phil
Communities (Horizontals)

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

33. @parker0phil
Enablers
(Diagonals)

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

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

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

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

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

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

40. @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)

41. @parker0phil
Response TimeOrganising for Continuous Delivery
Boundaries between
Domain teams (and
therefore systems)
should be
well-defined,
relatively stable and
not too granular

42. @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)

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

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

45. @parker0phil
Thank
You!
@parker0phil