Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scaling Architecture, Requirements and Design – The Mystery of the 11th Principle


Published on

The Principles outlined in the Agile Manifesto provide us with guidance and direction on how to adopt an Agile mindset in our organizations. The eleventh principle in the manifesto states: "The best architectures, requirements, and designs emerge from self-organizing teams".

While this seems to work 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.

In this presentation we present a case study of a large retail organization and explore their transformational journey from a highly centralized/governance-based technology organization to a more distributed/collaborative one. We will review their lessons learned and note success/failure patterns along the way.
At the end, we'll answer the question whether Principle 11 scales or not!

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Scaling Architecture, Requirements and Design – The Mystery of the 11th Principle

  1. 1. Today’s Speaker KEN FRANCE, SAFe FELLOW • • • • •
  2. 2. Introduction
  3. 3. Agile Manifesto: Principle 11 Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
  4. 4. But does this Scale to the Enterprise? • • • • •
  5. 5. Case Study
  6. 6. Context/Problem Statement: Large Retailer • • •
  7. 7. Initial State: Challenges • • • • • • •
  8. 8. Initial State: Enterprise Architecture Centralized Architecture Enterprise Architects Best Practices / Architecture / Review Boards Solution Teams Solution Teams Solution Teams
  9. 9. Initial State: Intake
  10. 10. Target State: Enterprise Architecture Technical Architect Domain Architect Principal Architect Team Product Owner/ Manager
  11. 11. Target State: Intake
  12. 12. Target State: Service Catalog
  13. 13. Target State: Engineering Services • • • • Git Training Cloud Training Template Development Training
  14. 14. Target State: System Team
  15. 15. Target State: Summary • • • •
  16. 16. Best Practices
  17. 17. Agile Architecture • • • • • © Scaled Agile, Inc.
  18. 18. De-centralized Architecture in SAFe © Scaled Agile, Inc. Enterprise Architect Solution Architect System Architect
  19. 19. Architecture is a Collaboration © Scaled Agile, Inc. ‒ ‒
  20. 20. 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
  21. 21. 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
  22. 22. Architects Collaborate to Align Teams © Scaled Agile, Inc. NFRs ProgramBacklog Roadmap Vision NFRs SolutionBacklog Roadmap Vision
  23. 23. Architect’s Role in DevOps © Scaled Agile, Inc. • • • • •
  24. 24. Architect's Focus on Enablers © Scaled Agile, Inc. • • • • • Feature Feature Feature Feature Enabler Enabler Program Backlog
  25. 25. Sample Roadmap © Scaled Agile, Inc.  Location-Based Order Placement  Order Status, Tracking, & Reporting  Dynamic Business Rules Management System  Order Management Upgrade  Fulfillment API Integration  Cloud-Based CRM & APIs for New Customer Registration May July Sep  New Customer Registration  Platform-Independent Order Capture  BI System Integration  Order Management APIs  Billing System Feeds  Data Warehouse Integration  New Cust. Support Platform  Mobile Platform Prototype  Tiered Services & Pricing  Customer Support Portal with Live Chat  Predictive Delivery Analytics  Pricing Sub-System Upgrade  Support Platform Integration  Mobile Order Capture  Big Data Platform MVP Committed Safety Audit (8/23) Forecast BusinessFeatures Architectural Enablers
  26. 26. Architect’s Role during Execution © Scaled Agile, Inc.
  27. 27. Architect Sync © Scaled Agile, Inc. • • • •
  28. 28. 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
  29. 29. Conclusion
  30. 30. Takeaways • ☺ • • •
  31. 31. Keep the conversation going ….. • • • • • • • • • • •