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.

Architectural thinking - the Sucess Factor of Scaled Agile


Published on

There is currently much debate about whether and how agility scales at the enterprise level. Many approaches exist, such as scaled Agile frameworks (SAFe, LeSS, DaD), Beta Codex, Beyond Budgeting, Sociocracy or Open Space, but success stories are rare..

Design thinking and Agile are the methods currently used to implement innovative point solutions at short notice. Companies rarely take enough time for long-term thinking. Fast innovation, sloppily integrated into the existing IT landscape, however, has lead to a complexity explosion that made IT tremendously expensive and increasingly sluggish for change. And this is not an IT problem but the result of bad funding decisions by business executives. Therefore it must be addressed at a business- and governance level, not by autonomous solution development teams.
Many people of the Agile community perceive IT governance and architecture management as too rigid and heavyweight to be integrated with Agil. This is not surprising given the prevailing heavy and immature enterprise architecture frameworks and their ivory-tower use in practice.
This presentation discusses why Agile will never scale without a consistent model of the business (=’business architecture’) that is understood, maintained an accepted by everybody, from CEO to software developer. It presents a lightweight, business-focused approach to architecture that should be integrated with common scaled agile frameworks (such as SAFe, LeSS, DaD) to really make them scale.

Published in: Business
  • Be the first to comment

Architectural thinking - the Sucess Factor of Scaled Agile

  1. 1. Architectural Thinking: the Sucess Factor of Scaled Agile Dr. Wolfgang Goebl November 2018 1
  2. 2. About us • Non Profit Association • “Förderung des architekturellen Denkens in Unternehmen” • Truly open Architectural Thinking Framework® • 2
  3. 3. About us – current Status 3
  4. 4. Basic Assumption of my Presentation 4 vs.? And! Design by a Genius Team Design see [Westerman15]
  5. 5. “The more participation in design, the better. This is surely not universally true. Most great works of the human mind have been made by one mind, or two working closely. This is true of most of the great engineering feats of the 19th and early 20th centuries. But now, team design has become the modern standard, for good reasons. The danger is the loss of conceptual integrity in the product, a very grave loss indeed. So the challenge is how to achieve conceptual integrity while doing team design, and at the same time to achieve the very real benefits of collaboration.” [Brooks10] 5 Basic Assumption of my Presentation
  6. 6. 1. The Problem 6
  7. 7. The Problem 7 Dark Waters of Legacy IT Disruptor Company Agile! Agile! Agile! Innovation! ? Architecture ?
  8. 8. 2. Attempts that verifiably do not work* 8 * in Isolation
  9. 9. Separated Disciplines 9 ”It is all about Leadership” “Cloud is the only remedy” “Its all about Innovation” “Be Agile” “Microservices to the Rescue!”
  10. 10. A sole Discipline as Connector 10 Vision/Strategy Management Design Thinking Business Analysis Business Process Management IT Operations Project Management Programm Management EAM (Agile-)Solution Development Business Units
  11. 11. Bloated EAM Frameworks 11 Archimate® Zachmann TOGAF® [Carr18] [Kostic 16]
  12. 12. Ivory Tower Architects
  13. 13. Software/System Architecture only
  14. 14. Microservices as universal Remedy Tiny modules to the rescue Redundant Data makes Agile scale!
  15. 15. The Cloud as universal Remedy 15
  16. 16. Hardcore Agility 16
  17. 17. 17 Autonomous Teams without a Plan
  18. 18. 18 Time-to-market Thinking only
  19. 19. 19 Focus on Culture/Leadership only ChainsofLegacy Company Be agile! Lead agile! Run like Hell!
  20. 20. 20 Design Thinking Let’s have Fun! ... and create yet another unrealizable point solution!
  21. 21. Nexus™
  22. 22. 22 Nexus™ Pros Cons Extremely lean (12 pages) No real guidance Architecture not mentioned
  23. 23. Large Scale Scrum™ (LeSS) 23
  24. 24. Large Scale Scrum (LeSS) - Quotes 24 • What to model: • low-fidelity UI modeling • algorithm modeling with UML activity diagrams, • object-oriented software design modeling • database modeling likewise. “The real software architecture evolves as people do programming.” “Think ‘gardening’ over ‘architecting’—Create a culture of living, growing design”
  25. 25. 25 Large Scale Scrum (LeSS) Pros Cons Evolutionary Approach No Inception Phase Team creates Architecture No ‘Architecture Owner’ – Integrity?? Tekkie Architecture only Focus on Solution only Enterprise Awareness?
  26. 26. Scaled Agile Framework® (SAFe®) 26
  27. 27. 27 Scaled Agile Framework® (SAFe®) EA’s Responsibility: 90% Tekkie
  28. 28. 28 Pros Cons Nexus to BizArch (Value Stream) No other BizArch Artefacts (Information, Capabilities) Explicit Architecture Roles - No Inception Phase - Ignores Wisdom of EA&BA - 90% Tekkie Architecture Enterprise Awareness Hard to understand Expensive Trainings needed. Too heavyweight? Scaled Agile Framework® (SAFe®)
  29. 29. Disciplined Agile Delivery (DaD) 29
  30. 30. 30 Disciplined Agile Delivery (DaD) Inception Phase: • foundation from which the project can be successful in a lightweight manner • Enterprise awareness • Vision, scope, connection with Biz-& EA of the company • Enterprise as another customer
  31. 31. 31 Pros Cons Understands Biz&IT Architecture in depth Not as widespread as SAFe® ‘Architecture Owner’ role Evolves evolutionary from team Inception Phase Enterprise Awareness Easy to understand Disciplined Agile Delivery (DaD)
  32. 32. 3. What might work 32
  33. 33. A new, more holistic Manifesto 33
  34. 34. 34 YES A new, more holistic Manifesto
  35. 35. Sustainable solutions over working software 35 A new, more holistic Manifesto
  36. 36. 36 Considering all stakeholders over customer only A new, more holistic Manifesto Incl. Enterprise as a whole
  37. 37. 37 Malleable plans over strict plans & anarchy
  38. 38. Business (Architecture) over IT (Architecture) 38 A new, more holistic Manifesto New
  39. 39. 39 Vision/Strategy Management Design Thinking Business Analysis Business Process Management IT Operations Project Management Programm Management (Agile-)Solution Development Business Units Architectural Thinking as a Mindset
  40. 40. 40 • Overlapping responsibilities between departments • Unclear data- and process ownership • Acting in departmental silos • Weak links between departments • Short term thinking • Bad (IT-) funding decisions • Ordering the wrong IT solutions Business aspects/decisions are the reason of IT Chaos Focus on Business Architecture
  41. 41. Focus on Business Architecture • Model of the Business Architecture drives IT Architecture • Capabilities • Processes/Value Streams • Business Information • Applications 41 [BAGuild16]
  42. 42. Simple Model everybody agrees upon 42 Ear Leg Tooth Trunk Eye
  43. 43. Connect everything to Model 43 Ear Leg Tooth Trunk Eye Require ment Budget Solution Vision Strategy Project Code Architectural Thinking Framework® Metamodel (Draft) Gover nance
  44. 44. Connect Solution Stories and Biz Arch 44 CapabilityMap(ExampleBank)
  45. 45. 45 SolutionLevel StoryMapBoard EnterpriseLevel CapabilityMap Connect Solution Stories and Biz Arch
  46. 46. 46 Connect Solution Stories and EntArch
  47. 47. Modularize by Business Information 47
  48. 48. Manage technical Debt proactively 48 Dark Waters of Legacy IT
  49. 49. “Agility does not mean to maximize speed. It means maneuverability, i.e. finding the right speed to make the right deflection.” 49 Find right speed, modernize System
  50. 50. Culture to transform the System • The “System” (business & IT structures) make a company Agile • Agile culture • alone does not transform a company • is important but not a means by itself 50 + Culture + (Reengineering-) Methods ---------------------------------- = Transformation
  51. 51. Strict Governance & autonomous Teams 51
  52. 52. Add Architectural to Design Thinking 52 Design Thinking Workshops are cool! But…. *) Architecture Maps and Architecture Owner must be in the room *)
  53. 53. Architectural Thinking Framework® 53
  54. 54. 4. Conclusion 54
  55. 55. Conclusion: How to scale Agile • Disciplines working together using the same Enterprise Model • Strong focus on Business Architecture • Integration of Scaled Agile- & Lightweight Architecture Framework • Centralized governance AND autonomous teams • Cultural Change AND (engineering) methods • Collaboration between Enterprise- and Solution Architecture 55
  56. 56. Recommended Reading [Ambler10]: S. Ambler: ‘Disciplined Agile Delivery’ [BAGuild16]: Business Architecture Guild, “A Guide to the Business Architecture Body of Knowledge®” (BIZBOK® Guide, v6.5), [Brooks10]: F. Brooks: ‘The Design of Design: Essays from a Computer Scientist’ [Carr18]: D. Carr 'State of Enterprise Architecture Survey: Results and Findings' [Eckstein18]: J. Eckstein: ‘Company-wide Agility’ [Kostic 16]: N. Kostic: ‘Demystifying Enterprise Architecture‘ [Westerman15]: ‘Leading Digital Turning Technology into Business Transformation’ 56
  57. 57. One last thing… 57 “Sometimes we are Agile without the Discipline. Sometimes we are disciplined without the Agile. We need both.”
  58. 58. Thank you! 58 Dr. Wolfgang Goebl