The Principles in the Agile Manifesto provide us guidance on how to have an Agile mindset in our organizations. Principle 11 within the Manifesto states "The best architectures, requirements, and designs emerge from self-organizing teams". While this works well for autonomous teams, it proves to be challenging for large organizations with dozens or even hundreds of teams who need to share common architectures and design patterns. This talk will present a case study of a large retail organization and explore their journey from a highly centralized/governance-based technology organization to a more distributed/collaborative one and explore their lessons learned and success/failure patterns along the way. In the end, we'll answer the question about whether or not Principle 11 scales! More details: https://confengine.com/agile-india-2019/proposal/9281/principle-11-needs-to-go Conference link: https://2019.agileindia.org

2. Principle 11 Needs To Go!
Agile India
March 22, 2019

3. Intros
Ken France, SAFe Fellow
• VP of Scaled Agility @Cprime
• 25+ years’ experience
• Executive Enterprise Coach
• Helps Fortune 100 enterprises tackle large
complex scaled agile transformations in
various verticals (retail, healthcare,
insurance, finance. etc)
• Passionate about empowering all levels of
org in their journey to drive sustainable
improvements and meaningful change

4. Agenda
• Introduction
• Case Study
• Best Practices
• Conclusion
• Q&A

5. Introduction

6. Agile Manifesto: Principle 11
“The best architectures, requirements, and designs emerge
from self-organizing teams”
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

7. But does this Scale to the Enterprise?
• Can teams truly be empowered to define their
own architecture?
• How do we ensure integration and performance
across systems of systems?
• Can’t we just “make the enterprise smaller” by
breaking it down into smaller problems to solve?
• How do we avoid a big up front waterfall design?
• Can we truly be agile at scale?

8. Case Study

9. Context/Problem Statement: Large Retailer
Context: ~18M customers, 2,200 stores, $68B Revenue, ~300K total employees
IT Profile:
• Location: Primarily across various sites in the US as well as Bangalore
• Scope: IT Strategy, Security, Ops, Enterprise Arch, Infrastructure Engineering,
Digital Solutions
• Sample Technologies: Java/J2EE, Websphere, Azure, Google Cloud
Initial Problem Statement: Applying Lean-Agile at the team level for years; now
looking to scale across the organization
What we found: Legacy skillsets and technologies in place; most advanced in
digital space; needed to “upgrade” approach to environments – automation, hiring
and developing modern skillsets; modernize technology – move to cloud

10. Initial State: Challenges
• Company funded solutions based on projects.
• Projects drew many different resources until completion & those teams
were then disbanded (temporary teams vs. permanent ownership).
• Technical resources fragmented across many different solutions & did
not focus or put energy into single product.
• Support of products was very tenuous since original team was disbanded
& those resources may or may not work for company.
• Communication / transparency of project from ideation to delivery was
limited.
• Organization not data driven so decisions are solely based on upper
management charting direction for organization.
• Centralized architecture team focused originally on being a governance
gate for new capabilities via the architecture review board and did not
work collaboratively, early and often with solution teams.

11. Initial State: Enterprise Architecture
Centralized Architecture
Enterprise
Architects
Best Practices / Architecture / Review Boards
Solution
Teams
Solution
Teams
Solution
Teams

12. Initial State: Intake

13. Target State: Enterprise Architecture
De-Centralized Architecture
Technical
Architect
Domain
Architect
Principal
Architect
Team
Solution
Team(s)
Product
Team
Product
Owner/
Manager
Tech Strategy 12 – 36 months

14. Target State: Intake

15. Target State: Service Catalog
Focus on Automation
System Team quickly composes infrastructure from Engineering Team’s automation (e.g. Terraform, Ansible, Azure CLI)

16. Target State: Engineering Services
• Take existing administration activities and codify them into templates.
• Compose templates into larger / re-usable modules / components.
• Leverage Git to store and manage the lifecycle of templates.
• Use management consoles to validate, monitor and engage with Cloud
Git Training
Cloud Training
Template Development Training

17. Target State: System Team
Support Scrum teams in establishing Continuous Delivery Pipelines of their Software Solutions via a team
that operates on the same cadence.

18. Target State: Summary
• Moving to multi-cloud and microservices
• Automation to standardize path to production including infrastructure,
builds and testing
• Develop KPIs / metrics / dashboard to determine health of a team and their
solution
• Upskill teams with latest approaches and technology in order to retain and
gain new talent into the organization

19. Best Practices

20. Agile Architecture
As defined in SAFe, Agile Architecture is a set of values and practices that
support the active evolution of the design and architecture of a system while
implementing new system capabilities.
Agile Architecture:
• Evolves over time while supporting needs of current users
• Avoids overhead and delays associated with phase-gate methods
• Ensures system always runs
• Supports continuous flow of value
• Balances emergent design and intentionality
© Scaled Agile, Inc.

21. De-centralized Architecture in SAFe
© Scaled Agile, Inc.
Enterprise
Architect
Solution
Architect
System
Architect

22. Architecture is a Collaboration
© Scaled Agile, Inc.
Every team deserves to see the bigger picture. Every team is empowered to design their part.
Emergent design ‒ teams grow the system
design as Features require
Intentional architecture ‒ fosters team alignment
and defines Architectural Runway
A balance between emergent design and intentional
architecture is required for speed of development
and maintainability.

23. Architect Responsibilities
© Scaled Agile, Inc.
Enterprise Architect
Across Value Streams
Solution Architect
Across Systems
System Architect
Single System
4Defines key technical initiatives
4Collaborates with Lean Portfolio
Management
4Guides strategy for Architectural
Runway
4Communicates Strategic Themes
4Promotes modern technical and
DevOps practices
4Synchronizes key disciplines
across Solutions
4Plans the Architectural Runway for
a full Solution
4Actively supports design and
steering of Continuous Delivery
pipeline
4Establishes and supports definition
of Nonfunctional Requirements
4Partners with System Architects to
elaborate Capabilities and
Features
4Fosters Built-in Quality for the
entire Solution
4Plans the Architectural Runway
4Actively supports design and
steering of CI/CD pipeline
4Establishes and supports definition
of Nonfunctional Requirements
4Partners with Solution and
Enterprise Architects to elaborate
Epics, Capabilities, and Business
Capabilities
4Fosters Built-in Quality for the ART’s
systems

24. Architect Roles Span Domains
© Scaled Agile, Inc.
Business Architecture
Information Architecture
Application Architecture
Technical Architecture
________ Architecture
Enterprise Architect Solution Architect System Architect
Across
Value
Streams
Across
Systems
Single
System
People
Domains

25. Architects Collaborate to Align Teams
© Scaled Agile, Inc.
NFRs
ProgramBacklog
Roadmap
Vision
NFRs
SolutionBacklog
Roadmap
Vision

26. Lead and Steer Shared Services
© Scaled Agile, Inc.
High–Touch
Low–touch
• Member per team (1-2 teams)
• Supports intense needs
• Experienced practitioner on every Agile Team
• Direct interaction with specific person for a period of time
• Works with team to clarify needs
• Affinity to small number of teams or trains
• Has a core team for backup support
• Pure service; ticket-based
• People make requests and get a response
Consultative services
Hybrid Services
Embedded Services
Ticketed Services

27. Architect’s Role in DevOps
© Scaled Agile, Inc.
• Design to make DevOps easy and obvious
• Design standards to include full pipeline, telemetry,
etc.
• Sponsor and act as Epic Owner (for example: PaaS
and IaaS work)
• Facilitate change management and
communications
• Provide expertise in third-party sourcing and
systems integration

28. Architects Contribute to Business Backlog
Architects often contribute to:
• Determining Acceptance Criteria
• Communicating intent
• Defining critical NFRs and unique
quality attributes
Program
Backlog
© Scaled Agile, Inc.

29. Architect's Focus on Enablers
© Scaled Agile, Inc.
Enablers support activities needed to extend Architectural
Runway to provide future business functionality
Captured in backlogs at all levels of Framework (as Enabler
Epics, Enabler Capabilities, Enabler Features, and Enabler
Stories)
Created and managed by System Architect/Engineering
Are managed in backlogs and are subject to:
• Estimating
• Visibility and tracking
• Work in Process limits
• Feedback
• Presentation of results
Feature
Feature
Feature
Feature
Enabler
Enabler
Program
Backlog

30. Types of Enablers
© Scaled Agile, Inc.
Enablers can represent different types of work.
Infrastructure ‒ build, enhance, & automate development, testing, &
deployment environments
Exploration ‒ research, prototyping, evaluating
solution alternatives
Architecture ‒ build Architectural
Runway, proof-of-concept
Compliance ‒ schedule &
manage specific compliance
events or activities

31. Sample Roadmap
© Scaled Agile, Inc.
4 Location-Based Order Placement
4 Order Status, Tracking, &
Reporting
4 Dynamic Business Rules
Management System
4 Order Management Upgrade
4 Fulfillment API Integration
4 Cloud-Based CRM & APIs for New
Customer Registration
May July Sep
4 New Customer Registration
4 Platform-Independent Order
Capture
4 BI System Integration
4 Order Management APIs
4 Billing System Feeds
4 Data Warehouse Integration
4 New Cust. Support Platform
4 Mobile Platform Prototype
4 Tiered Services & Pricing
4 Customer Support Portal with
Live Chat
4 Predictive Delivery Analytics
4 Pricing Sub-System Upgrade
4 Support Platform Integration
4 Mobile Order Capture
4 Big Data Platform MVP
Committed
Safety Audit (8/23)
Forecast
BusinessFeatures
Architectural
Enablers

32. Architect’s Role during Execution
© Scaled Agile, Inc.
Prioritize day-to-day work of architects to address:
1. Team blockers
2.Cross-team coordination
and alignment
3.Team support (especially
knowledge and education)
4.Team pairing (on Enablers)
5.Work coming from outside the
ART’s goals

33. Architect Sync
© Scaled Agile, Inc.
Attended by tech leads, architects,
key subject matter experts
Provides opportunity to:
• Align on approach
• Share learning
• Request opinions
• Highlight new capabilities
NOT a review or approval board

34. Support System Team in driving to Demos
© Scaled Agile, Inc.
Iteration Review System Demo Solution Demo
4WHAT: A critical method for gathering
immediate, Team-level feedback
4WHEN: Occurs every iteration
4WHO: Presented by the teams doing
the work to themselves and interested
stakeholders, which may include
other teams
4SHOWS: Real measure of team
value, velocity, and progress during
the prior iteration
4WHAT: Gathering immediate, system-
level feedback of full system in
representative staging environment
4WHEN: Occurs every iteration and
at end of PI (as part of Inspect
and Adapt)
4WHO: Presented by the ART Product
Manager and Product owners.
Attended by sponsors, stakeholders,
and customers
4SHOWS: Real measure of system
value, velocity, and progress to learn
and adjust
4WHAT: A ‘pull’ event to ensure ARTs
and suppliers create integrated and
tests solutions demonstrated in as true
a solution context as possible
4WHEN: Occurs at least at the end of
each PI, more frequently if possible
4 WHO: Presented by the ARTs.
Attended by suppliers, sponsors,
stakeholders, and customers
4SHOWS: Results of the combined
development efforts of multiple ARTs
which determines the future course of
action for investment in the Solution

35. Conclusion

36. Takeaways
• Principle 11 does NOT have to go! J
• Establish the proper balance between centralized intentional architecture
and de-centralized emergent design
• Set proper cadence & process for collaboration between architects,
business, and teams
• Great is the enemy of good!

37. Keep the conversation going …..
• Reach out and connect with Ken
• //www.linkedin.com/in/kenfrance/
• @kfranceUS on twitter
• Ken.France@cprime.com
• Check out our upcoming webinars; read our blog, download whitepapers/case studies &
more:
• www.cprime.com/resources
• Share with us what topics you are interested in, ask us questions or give us feedback!
• learn@cprime.com
• Follow us on Social Media and share in the conversation & keep updated on thought
leadership, events & more.
• www.linkedin.com/company/cprime-inc
• @CprimeInc on Twitter

38. Q&A