ASAS 2014 - Klasien Postma
0 likes781 views
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.
ASAS 2014 - Klasien Postma
- 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
- 25. 25 www.ordina.nl