Role of Architect In Agile
Download as PPTX, PDF1 like51 views
The document discusses the role of an architect in agile organizations, emphasizing that successful designs emerge from self-organizing teams and that architects should empower rather than dominate. It presents various architectural approaches, including the architecture scout and architecture coach, advocating for leadership through intent and fostering collaboration among teams. The conclusion stresses the importance of relationships, framework for disagreements, and that effective leadership skills are essential for an architect's success.
Role of Architect In Agile
- 1. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 what is the role of an architect in an agile organization? 1 The Agile Architect / November 2015
- 2. Information | Analytics | Expertise © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Chris Edwards P.Eng., Senior Manager Chris.Edwards@ihs.com @AgileChrisYYC THE AGILE ARCHITECT Our Experience in Discovering a Successful Pattern NOVEMBER 2015
- 3. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Setting the Stage • 5 teams, 5-9 each (including QA) • Mix of Scrum/Kanban/Scrumban • Thick Client • C++ • Mature Codebase • Recently Adopted Agile • Major Project – Client / Server 3 The Agile Architect / November 2015
- 4. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 The best architectures, requirements, and designs emerge from self-organizing teams. 4 The Agile Architect / November 2015 Agile Manifesto
- 5. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Architecture Approach 1: Laissez Faire 5 The Agile Architect / November 2015
- 6. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 6 The Agile Architect / November 2015 HELP!!!
- 7. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 empowerment is more than just taking your hands off the wheel 7 The Agile Architect / November 2015
- 8. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 how do we incorporate an architect… without sacrificing agile values? 8 The Agile Architect / November 2015
- 9. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Wanted to avoid this: 9 The Agile Architect / November 2015 Requirements Design Code Test Deploy
- 10. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 And this: 10 The Agile Architect / November 2015 cliparthut.com
- 11. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Architecture Approach 2: The Architecture Scout 11 The Agile Architect / November 2015
- 12. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 14 The Agile Architect / November 2015 Architecture by Example ”“
- 13. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 15 The Agile Architect / November 2015
- 14. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 16 The Agile Architect / November 2015 Too many classes makes the system too complex! Big classes make the system unmaintainable!
- 15. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 17 The Agile Architect / November 2015 WORK HARDER!
- 16. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 what if the architect is WRONG? 18 The Agile Architect / November 2015
- 17. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 how do you know if the architect is WRONG? 19 The Agile Architect / November 2015
- 18. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 20 The Agile Architect / November 2015 I thought you knew something I didn’t ” “
- 19. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 architect is a leadership role 21 The Agile Architect / November 2015
- 20. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 The Agile Architect / November 2015 xkcd.com 22
- 21. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 24 The Agile Architect / November 2015 Image Source: worklifematters.net Spotify Engineering Videos
- 22. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 how do I serve the teams without telling them what to do? 25 The Agile Architect / November 2015
- 23. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Intent Based Leadership 26 The Agile Architect / November 2015 Rob van Hilten, Flickr
- 24. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 27 The Agile Architect / November 2015 Don’t move information to authority, move authority to the information ” “ David Marquet
- 25. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 28 The Agile Architect / November 2015 Image Source: worklifematters.net
- 26. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 29 The Agile Architect / November 2015 two pillars that need to be in place: the technical competence …. and organization clarity. … put those things in place and then you can give control. ” “ David Marquet
- 27. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 i intend to… 30 The Agile Architect / November 2015
- 28. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 31 The Agile Architect / November 2015 Image Source: worklifematters.net Spotify Engineering Videos
- 29. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Architecture Approach 3: The Architecture Coach 32 The Agile Architect / November 2015 Rob van Hilten, Flickr
- 30. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Daily Design Meeting • 30 minutes • Technical lead from each team • Discuss challenges that being encountered • Exercise is repeated on the team that brought the challenge 33 The Agile Architect / November 2015
- 31. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 34 The Agile Architect / November 2015 Resist the urge to provide solutions. ” “ David Marquet
- 32. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 questions communicate values 35 The Agile Architect / November 2015
- 33. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 letting go is hard 36 The Agile Architect / November 2015
- 34. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 37 The Agile Architect / November 2015 organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations ” “ M. Conway
- 35. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 38 The Agile Architect / November 2015
- 36. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Architecture Approach 3: The Architecture Coach 40 The Agile Architect / November 2015 Rob van Hilten, FlickrCoaching Agile Teams, Lyssa Adkins
- 37. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Focus on Interests Rather than Positions 41 The Agile Architect / November 2015 Rob van Hilten, Flickr
- 38. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Design Steps • What is the problem you’re trying to solve? • What solutions should we consider? • What are the pros/cons of each solution? 42 The Agile Architect / November 2015
- 39. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 create a common framework for resolving conflict 43 The Agile Architect / November 2015
- 40. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 disagreement is a mechanism for organizational clarity 44 The Agile Architect / November 2015
- 41. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 the end? 45 The Agile Architect / November 2015
- 42. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 something interesting happened 46 The Agile Architect / November 2015
- 43. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 47 The Agile Architect / November 2015 ?
- 44. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 do we still need an architect? 48 The Agile Architect / November 2015
- 45. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Final Architecture Approach: Architecting as a Team 49 The Agile Architect / November 2015 Steve Jurvetson, Flickr
- 46. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 50 The Agile Architect / November 2015 Image Source: worklifematters.netSpotify Engineering Videos
- 47. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 knowing what we know today would we do it all again? 51 The Agile Architect / November 2015
- 48. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 approach must evolve over time 52 The Agile Architect / November 2015
- 49. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Summary • Empowerment is more than standing back • Architect must be connected to the code • Lead through intent • Resist the urge to provide solutions • Build relationships between teams • Create a framework for disagreement • Disagreement is a mechanism for organizational clarity 53 The Agile Architect / November 2015
- 50. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 leadership skills are vital to an architect’s success 54 The Agile Architect / November 2015
- 51. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 •55 www.synerzip.com Hemant Elhence hemant@synerzip.com 469.374.0500 55
- 52. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Synerzip in a Nutshell Software product development partner for small/mid-sized technology companies • Exclusive focus on small/mid-sized technology companies, typically venture-backed companies in growth phase • By definition, all Synerzip work is the IP of its respective clients • Deep experience in full SDLC – design, dev, QA/testing, deployment Dedicated team of high caliber software professionals for each client • Seamlessly extends client’s local team offering full transparency • Stable teams with very low turn-over • NOT just “staff augmentation, but provide full management support Actually reduces risk of development/delivery • Experienced team – uses appropriate level of engineering discipline • Practices Agile development – responsive yet disciplined Reduces cost – dual-site team, 50% cost advantage Offers long-term flexibility – allows (facilitates) taking offshore team captive – aka “BOT” option 56
- 53. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Synerzip Clients 57
- 54. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Next Webinar Evolution of Configuration Management Into a DevOps/Agile World Complimentary Webinar: Tuesday, December 15, 2015 @ Noon CST Presented by: Marisa Sawatphadungkij, CM & Test Manager at Drillinginfo 58
- 55. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Hemant Elhence hemant@synerzip.com 469.374.0500 Connect with Synerzip @Synerzip linkedin.com/company/synerzip facebook.com/Synerzip 59
- 56. © 2015 IHS @AGILECHRISYYCWebinar Series 2015 Chris Edwards Chris.Edwards@ihs.com @AgileChrisYYC 60 The Agile Architect / November 2015 Questions?
Editor's Notes
- #6: Anecdote: First feature we worked on. PSS Model. Usually 1 person. Leap of faith and got a whole team to work on the same feature. New project:
- #13: Anecdote – Create an example that exercises all layers in the system, from the presentation layer interacting with our services, to managing a transaction, to interacting with the database
- #18: Anecdote: “Transaction manager”
- #21: Anecdote: Repository replicated many times over
- #30: Design Skills, Knowledge of DDD, Enterprise architectuer patterns, Organizational Clarity -> Conceptual integrity on architecture approach, understanding of client’s needs, assumptions of current approach. The context. The WHY
- #35: Anecdote: Melvin: Should I mock this. Me: NO! don’t do that…..
- #36: Anecdote: Team was trying to decide between two different API designs for our domain layer. I could see that one of the designs would be problematic if we ever had to make changes, because there was some sequence coupling. Each caller would be required to call a set of methods in a specific order or else a part of the underlying system wouldn’t behave properly. Option 1: “This design is better, because bl……” Option 2: “If we changed the underlying mechanism, which design would require the fewest changes?” The question communicated to them that I wanted them to be considering maintainbility, but it also engaged their thinking. The question itself communicated a value, but without handing them an answer.
- #37: Anecdote: Production aggregation -> I just want to hand them the solution! I already have it!
- #38: Anecdote: GIS Team -> Interface between the components was horrendous Note: Note used to inter-team collaboration because of component based teams.
- #41: Anecdote: Reminder back to the “SRP” example
- #42: Anecdote: We all know him. The guy who has to be right. Well we all have some of this inside.
- #43: Pull you out of the argument mode. Physically separate from the design options.
- #45: Anecdote: Database or domain layer?
- #58: 57
- #60: 59