The lecture was presented at the 2016 LAST Conference in Sydney, July 25th 2016. It presents experiences with different types of Agile Specialist Teams and shows several ways how they can address their specific needs. Agile Specialist Teams, such as Shared Services, DevOps, Infrastructure, Databases, Networking, etc., are usually on the fringes of Agile Transformations. For a variety of reasons, they usually do not receive Agile training and coaching, and definitely not Agile coaching specific to their needs. However, they are expected to: - build assets, such as networking, cloud, infrastructure, databases etc. on time and on budget, and - support the Development Teams and Operations, often at short notice. This Dual Nature of the work of Agile Specialist Teams requires a different approach to that of Agile Development Teams. Unless carefully analyzed and adaptively addressed, it can lead to Specialist Teams becoming roadblocks for the rest of the Agile Organisation.

1. Running Agile
Specialist Teams
Presented by
Mihail Sestakov

2. Running Agile Specialist Teams
… it’s a journey, not a destination ...
25th July 2016
Mihail Sestakov (@use8020)
LAST Conference Sydney, July 25th 2016
© 2016 Mihail Sestakov

3. 3
Agile Specialist Teams (loose definition)
1. Agile Teams other than Agile Software Development
/ Feature teams
2. Agile Specialist Teams (almost always)
- build Capabilities and
- implement non-Functional Requirements
© 2016 Mihail Sestakov25th July 2016

4. 4 © 2016 Mihail Sestakov25th July 2016
Methodology Specialist Team Examples
SAFe DevOps, System Team, Shared Services
XSCALE
System Squads: Quality Automation,
Process Automation, Production
Support
Nexus Nexus Integration Team
DA/DAD DevOps Team
Agile Specialist Teams and Agile Methodologies

5. Audience Check:
Hands up if you are in a
Specialist Team?
(You are in the right session!)
© 2016 Mihail Sestakov25th July 2016

6. 6 © 2016 Mihail Sestakov25th July 2016 – v3
[…insert your Specialist Team here…]
F*@#ED UP!!!
Again!!!

7. 7
Why do Agile Specialist Teams get in trouble?
Scenario #1 – Specialist Team has no Agile experience:
1. Do NOT receive Agile support
2. Continue working as before (waterfall, ITIL, ...)
3. Roadblocks visible too late
4. Blame-game begins: Specialist Teams are …@%$#
© 2016 Mihail Sestakov25th July 2016

8. 8
Scenario #2 – Specialist Team has some Agile experience:
1. DO receive Agile support as Feature/Dev Teams
2. Start working like Feature/Dev Teams
3. Initially do deliver, but start getting interrupted
4. Roadblocks visible too late
5. Blame-game begins: Specialist Teams are …@%$#
© 2016 Mihail Sestakov25th July 2016
Why do Agile Specialist Teams get in trouble?

9. 9
From Experience and Analysis…
Insight #1
Specialist Teams have Dual Nature of Work:
- build Assets
- provide service (mainly for those Assets)
© 2016 Mihail Sestakov25th July 2016

10. 10
Insight #1
Specialist Teams have Dual Nature of Work:
- build Assets
- provide service (mainly for those Assets)
Insight #2
All Specialist Teams are Different, so DIYO Agile WoW
1. try minimal viable change (MVC)
2. retrospect and learn
3. repeat
© 2016 Mihail Sestakov25th July 2016
From Experience and Analysis…

11. 11 © 2016 Mihail Sestakov25th July 2016
Insight #1: Dual Nature of Work Differences…
Nature Build Asset Provide Service
Focus Most Valuable work Most Urgent work
Work sequence Time based Priority based
Sync with Dev/
Feature Teams
Yes No
Suitable Agile
approach
Sprint/Scrum
Kanban *or* Support
Epic (if combining with
Sprint/Scrum)

12. 12 © 2016 Mihail Sestakov25th July 2016
Sprint
Build
Committed
Build
Delivered
Build
Failed to
Deliver
Service
Requested
Service
Delivered
Service Failed to
Deliver
Total
Delivered
Minimum Viable Change (MVC)
/ Result (R)
12 96 25 74% 60 40 33% 65 R: Failed ¾ of Build!
13 96
MVC: none?
Insight #1 applied – DevOps team example

13. 13 © 2016 Mihail Sestakov25th July 2016
Sprint
Build
Committed
Build
Delivered
Build
Failed to
Deliver
Service
Requested
Service
Delivered
Service Failed to
Deliver
Total
Delivered
Minimum Viable Change (MVC)
/ Result (R)
12 96 25 74% 60 40 33% 65 R: Failed ¾ of Build!
13 96 22 77% 11 11 0% 33
MVC: none?
R: Failed ¾ of Build AGAIN!
14 99
MVC: AGAIN none ??
Insight #1 applied – DevOps team example (cont.)

14. 14 © 2016 Mihail Sestakov25th July 2016
Sprint
Build
Committed
Build
Delivered
Build
Failed to
Deliver
Service
Requested
Service
Delivered
Service Failed to
Deliver
Total
Delivered
Minimum Viable Change (MVC)
/ Result (R)
12 96 25 74% 60 40 33% 65 R: Failed ¾ of Build!
13 96 22 77% 11 11 0% 33
MVC: none?
R: Failed ¾ of Build AGAIN!
14 99 48 52% 41 23 44% 71
MVC: AGAIN none ??
Failed ½ of Build.
15 48
MVC: reduce Build by 50%,
Services Staff up by 50%
Insight #1 applied – DevOps team example (cont.)

15. 15 © 2016 Mihail Sestakov25th July 2016
Sprint
Build
Committed
Build
Delivered
Build
Failed to
Deliver
Service
Requested
Service
Delivered
Service Failed to
Deliver
Total
Delivered
Minimum Viable Change (MVC)
/ Result (R)
12 96 25 74% 60 40 33% 65 R: Failed ¾ of Build!
13 96 22 77% 11 11 0% 33
MVC: none?
R: Failed ¾ of Build AGAIN!
14 99 48 52% 41 23 44% 71
MVC: AGAIN none ??
Failed ½ of Build.
15 48 43 10% 85 77 9% 120
MVC: reduce Build by 50%,
Services Staff up by 50%
R: Close!!!
16 52
MVC: 10% Build increase
Insight #1 applied – DevOps team example (cont.)

16. 16 © 2016 Mihail Sestakov25th July 2016
Sprint
Build
Committed
Build
Delivered
Build
Failed to
Deliver
Service
Requested
Service
Delivered
Service Failed to
Deliver
Total
Delivered
Minimum Viable Change (MVC)
/ Result (R)
12 96 25 74% 60 40 33% 65 R: Failed ¾ of Build!
13 96 22 77% 11 11 0% 33
MVC: none?
R: Failed ¾ of Build AGAIN!
14 99 48 52% 41 23 44% 71
MVC: AGAIN none ??
Failed ½ of Build.
15 48 43 10% 85 77 9% 120
MVC: reduce Build by 50%,
Services Staff up by 50%
R: Close!!!
16 52 31 40% 75 67 11% 98
MVC: 10% Build increase
R: Missed! Supply blocker…
17 44
MVC: reduced Build by 15%
Insight #1 applied – DevOps team example (cont.)

17. 17 © 2016 Mihail Sestakov25th July 2016
Sprint
Build
Committed
Build
Delivered
Build
Failed to
Deliver
Service
Requested
Service
Delivered
Service Failed to
Deliver
Total
Delivered
Minimum Viable Change (MVC)
/ Result (R)
12 96 25 74% 60 40 33% 65 R: Failed ¾ of Build!
13 96 22 77% 11 11 0% 33
MVC: none?
R: Failed ¾ of Build AGAIN!
14 99 48 52% 41 23 44% 71
MVC: AGAIN none ??
Failed ½ of Build.
15 48 43 10% 85 77 9% 120
MVC: reduce Build by 50%,
Services Staff up by 50%
R: Close!!!
16 52 31 40% 88 80 9% 111
MVC: 10% Build increase
R: Missed! Supply blocker…
17 44 36 18% 84 68 20% 104
MVC: reduced Build by 15%
R: Needs closer...
Insight #1 applied – DevOps team example (cont.)

18. 18 © 2016 Mihail Sestakov25th July 2016
Sprint
Build
Committed
Build
Delivered
Build
Failed to
Deliver
Service
Requested
Service
Delivered
Service Failed to
Deliver
Total
Delivered
Minimum Viable Change (MVC)
/ Result (R)
.. .. .. .. .. .. .. .. ..
16 52 31 40% 88 80 9% 111
MVC: 10% Build increase
R: Missed! Supply blocker…
17 44 36 18% 84 68 20% 104
MVC: reduced Build by 15%
R: Needs closer...
18 34
MVC: reduced Build by 23%
So… Keep trying??? (google “BA 9 quadruple engine failure”)
Insight #1 applied – DevOps team example (cont.)

19. 19 © 2016 Mihail Sestakov25th July 2016
Sprint
Build
Committed
Build
Delivered
Build
Failed to
Deliver
Service
Requested
Service
Delivered
Service Failed to
Deliver
Total
Delivered
Minimum Viable Change (MVC)
/ Result (R)
.. .. .. .. .. .. .. .. ..
16 52 31 40% 88 80 9% 111
MVC: 10% Build increase
R: Missed! Supply blocker…
17 44 36 18% 84 68 20% 104
MVC: reduced Build by 15%
R: Needs closer...
18 34 32 6% 90 81 10% 113
MVC: reduced Build by 23%
R: Reliable Build estimates
19 37
MVC: 9% Build increase
Got it!
Insight #1 applied – DevOps team example (cont.)

20. 20 © 2016 Mihail Sestakov25th July 2016 – v3
Insight #2 – DIYO Agile Ways of Working
Retrospect
and Learn
Try a Minimal
Viable Change
(MVC)
(AKA Inspect-Adapt Cycle)

21. 21 © 2016 Mihail Sestakov25th July 2016 – v3
Stages in Creating Your Own Ways of Working
Novice
- Internal Focus
- Team MVCs
Intermediate
- External Focus
- Stakeholder
MVCs
Advanced
- Optimization
Focus
- Continuous
Learning MVCs
Gate 1 - Behavioural Criteria:
velocity is reasonablypredictable
(+/-20%), usually takes 3-6 sprints
Gate 2 - Behavioural Criteria:
velocity is predictable (< +/-10%),
usually 4-8 sprints

22. 22
Before you begin…
- Agility is a Team Sport
- if the Team does not want to do it, Do Not Start! (DNS)
- if you get in any trouble, Use The Team! (UTT)
- Train the Team at the Start – scrum, kanban, roles,
ceremonies, etc.
- Coach – will help enormously, get one or at least a part-
time one, “steal” her/him for few hours if needed!
© 2016 Mihail Sestakov25th July 2016

23. 23
NOVICE
© 2016 Mihail Sestakov25th July 2016
- Do: basics, as any other Agile team - establish roles,
Product Owner & Scrum Master, social contract (DoR,
DoD), create board/s, run ceremonies, select tool (jira)
- Likely MVCs: improve internals – board, ceremonies,
estimation, stats
- Critical to Success: keeping stats (build and support
velocity,...)

24. 24 © 2016 Mihail Sestakov25th July 2016 – v3
Example – Radiator Improvement – Sprint 4
Started with using
Burndown Chart
Support stories added mid
sprint (72 to 87 jump)
Visibility is low, not clear
how many support stories
were added mid-sprint.

25. 25 © 2016 Mihail Sestakov25th July 2016 – v3
Example – Radiator Improvement – Sprint 7
Improved by using
Burnup Chart, much better
visibility:
- Committed 55 points
(yellow line)
- Added 11 points by day 7 of
sprint (blue line and step graph
between yellow and blue line)
- Histogram at bottom:
36 points done by day 7

26. 26
INTERMEDIATE
© 2016 Mihail Sestakov25th July 2016
- Do: Stakeholder management, Supplier/Vendor
managment, establish separate “Front doors” for Build
(backlog) and Support (queue),
- Likely MVCs: improve externals – governance, supplier
reliability
- Critical to success: streamlined work, minimised
external blockers

27. 27 © 2016 Mihail Sestakov25th July 2016
Architecture
Development
and other
Specialist
Teams
Operations
Target: Best Value
Example – “Light” Governance: Stakeholders

28. 28 © 2016 Mihail Sestakov25th July 2016
Example – “Light” Governance: Process
- Select and agree on Stakeholders
- Architect/s, senior Developer/s, senior Tester/s, senior
Operations staff, other Specialist Team senior representatives
- Established weekly 30min Stakeholders catch-up meeting to:
- discuss latest / current progress
- (re)prioritize backlog
- discuss next sprint goal and scope
- check / update roadmap and strategy
- Use prioritized backlog in Sprint Planning meeting

29. ADVANCED
29 © 2016 Mihail Sestakov25th July 2016
- Do: optimize flow, build reliability, knowledge
management, self service, automation, SLAs
- Likely MVCs: optimise – build/support capacity
allocation, cross-skilling, optimised support mix (support,
self-service, automation), analytics, knowledge
repository
- Critical to success: employee and customer satisfaction,
employee engagement, proactive/reactive work ratio

30. 30 © 2016 Mihail Sestakov25th July 2016 – v3
Support (BAU)
capacity is same
as Stretch Goal.
Low Support
requests? Tackle
Stretch Goal.
Allocate min 15%
of Sprint Capacity
(velocity) to clear
Technical Debt
and Automate.
Example – Capacity Optimization

31. So…
© 2016 Mihail Sestakov25th July 2016

32. 32
Specialist Teams have Dual Nature of Work:
- build Assets
- provide service (mainly for those Assets)
All Specialist Teams are Different, so DIYO Agile WoW
1. try minimal viable change (MVC)
2. retrospect and learn
3. repeat
© 2016 Mihail Sestakov25th July 2016
Presentation Takeaways

33. Thank you!
Questions?
© 2016 Mihail Sestakov25th July 2016