This document discusses implementing scaled agile frameworks like SAFe in large organizations. It describes how SAFe was implemented at a tax authority, using portfolio, program and team backlogs to prioritize work. It also discusses implementing SAFe at a Council for the Judiciary organization using Product and Service development teams. Some challenges discussed are implementing agile within a traditional organization, integrating multiple frameworks, dealing with mixed agile and waterfall teams, and ensuring architecture work aligns with agile. The conclusion emphasizes the need for collaboration beyond models to effectively adopt business needs in IT solutions.

1. Klasien Postma, Solution Architect
1
Agile projects do not yield an effective IT business alignment

2. Portfolio
2
ERP + CRM
(Salesforce.com, Oracle, SAP)
Maatwerk
(Mobile, Smart Tech, GEO, Java, .Net, OpenSource)
Elastische infrastructuren
Advies & onder- steuning
(Vertical, Horizontal, Professional)
Applicatie Integratie & Middleware
(Integratie, Portalen, Proces- en regelsystemen)
Online
(Concepting, design)
Business Intelligence
(Bicc, Datawarehouse, Dashboards, Analytics)

3. Introduction – My architect roles …
3

4. … in the public sector
 Council for the Judiciary (spir-it)
 Tax authority
4

5. Trends in the public sector
Centralization: fewer offices
Specialization: shared service centers
IT: Governance, demand, supply
5

6. Current objectives public sector
Business
-Shorter and simpler procedures
-Better accessibility, understandability
IT-development
Reduced time-to-market, small projects
Engaged business, happy end-users
Principles
Service oriented
Re-use, before buy, before build
Standardized building blocks
One-off creation, multiple use
6

7. 7
Natural reflex: introduce new method

8. But…how to implement into large organizations
8

9. Scaled Agile Framework TM (SAFe) – Tax authority
Original concepts from Dean Leffingwell: www.scaledagileframework.com
Backlogs:
−Portfolio-backlog  Epics
−Program-backlog  Features
−Team-backlog  Stories, Spikes
Implementation:
−Step by step started in May 2014
−Started with two projects of the business demand-unit ‘IM Surcharges’
9

10. POTs and SOTs
−POT (product development team): chain oriented, business value, project scope
−SOT (service development team): component oriented, quality & re-usability, cross- project scope
Backlogs:
−Company-backlog
−Project-backlog
−Service-backlog
−Architecture-backlog
Implementation:
−Step by step, started in February 2013
−Started with supply-unit Spir-it
−Reorganization design- and development-teams
POTs and SOTs – Council for the Judiciary (spir-it)
10

11. Challenges

12. 1. ‘During the renovation, the store remains open’
12
Think big, act small; improve during implementation

13. 2. Another framework to integrate
Manage expectations: small steps and achievements
Convince the organization, use agile-coaches
Be aware Agile requires a new mindset
13

14. 2. Another framework to integrate
14
Scrum:
•Product back-log
•Sprint back-log
•Product Increment
•Burndown chart
Think lean:
•Who needs the document?
•Why does she/he need it?
•What’s the value to him/her?
•What if the document is missing?

15. 3. Many teams, scrum and waterfall
Create teams with a broad range of skills, max 10 persons
Stubs, don’t wait with physical integration till the end of iteration
Product-owner (little time, flexible working hours, dislocated)
−Joins Daily-standups as much as possible (minimum once a week)
−Joins all milestone meetings (Sprint-planning, Demo and Review)
15

16. 4. Architecture and Agile/scrum
16
Why?
To serve organizational interests
To keep cross-project scope
To outline a global overview

17. 4. Architecture and Agile/scrum
17
What
Who
When
Domain architecture
Domain architect
Long term planning
‘Project start architecture’
Project architect
Project initiation
Architecture implementation
IT-architect
Sprints
Architecture control and changes
Project architect
Sprints

18. Issue
Demand, Supply, Business don’t act as partners
Users are referred to as clients, not colleagues
Supply is not considered as a business partner
Many prejudices, low trust
18
Next challenge: how to involve the business

19. Next challenge: how to involve the business
19
Most important: collaboration based on equality and trust
Business
Demand
Supply

20. Improve collaboration
Business
Business = IT
Dig into automated processes too
Don’t be averse to IT
20

21. Improve collaboration
Demand
It starts with operations: reality differs from theory
Involve end-users to make specifications
Don’t consider IT as difficult
21

22. Improve collaboration
Supply
Invite eg. real users for the demo
Visit specification meetings
Focus on simple explanation
22

23. Conclusion
Effective adoption of
business reality into IT solutions
requires a mindset beyond
thinking in models and
predefined patterns.
23

24. 24
www.ordina.nl
Questions?

25. 25
www.ordina.nl