Agile Architect - Turning Followers into Leaders
•Download as PPTX, PDF•
1 like•423 views
"The higher you go in an organization, the more your suggestions become interpreted as orders." - Marshall Goldsmith An Architect garners a high level of authority by being an expert. People will follow their lead. But what if the Architect is wrong? They will follow right off a cliff. In the book "Turn the Ship Around", David Marquet tells his story as Captain of the US submarine the Sante Fe. On January 21, 1999, Marquet gave an order that could not be carried out, but the crew tried anyway. When he asked why, they responded "Because you told me to". After this incident, Marquet vowed to never give another order. Instead he replaced it with intent. Instead of asking for permission, his crew would tell him what they intend to do. Marquet took his first steps to get his crew to start thinking like the Captain. How do we get people to think like the Architect? Use the principles of Intent-Based Leadership to decouple the success of your project from the personality of the architect. By creating clarity around architectural goals and by engaging people in problem solving rather than defining rules and standards we can divest control and create an organization of leaders.
Recommended
Recommended
More Related Content
Similar to Agile Architect - Turning Followers into Leaders
Similar to Agile Architect - Turning Followers into Leaders (20)
More from Chris Edwards, P.Eng.
More from Chris Edwards, P.Eng. (7)
Recently uploaded
Recently uploaded (17)
Agile Architect - Turning Followers into Leaders
- 1. © 2016 IHS Markit. All Rights Reserved. The Agile Architect Turning Followers into Leaders Chris Edwards P.Eng., Senior Manager chris.edwards@ihsmarkit.com @AgileChrisYYC @ChrisSeanAgile 1
- 2. © 2016 IHS Markit. All Rights Reserved.
- 3. © 2016 IHS Markit. All Rights Reserved.
- 4. © 2016 IHS Markit. All Rights Reserved. Is it OK that I just donated blood? 4
- 5. © 2016 IHS Markit. All Rights Reserved. Doctor: There isn’t any reason it should interfere 5
- 6. © 2016 IHS Markit. All Rights Reserved.
- 7. © 2016 IHS Markit. All Rights Reserved. Confession: I‘m terrified of needles 7
- 8. © 2016 IHS Markit. All Rights Reserved. 8
- 9. © 2016 IHS Markit. All Rights Reserved. 9
- 10. © 2016 IHS Markit. All Rights Reserved. OUCH 10
- 11. © 2016 IHS Markit. All Rights Reserved. Why is the doctor pressing right into where I just had blood taken? 11
- 12. © 2016 IHS Markit. All Rights Reserved. It‘s ok, she probably has a really good reason 12
- 13. © 2016 IHS Markit. All Rights Reserved. After all, she’s a doctor 13
- 14. © 2016 IHS Markit. All Rights Reserved. Why didn’t I say anything? 14
- 15. © 2016 IHS Markit. All Rights Reserved. Disclaimer: This is not a talk about architecture 15
- 16. © 2016 IHS Markit. All Rights Reserved. What is the role of an architect in an agile organization? 16
- 17. © 2016 IHS Markit. All Rights Reserved. What are you hoping to get out of this talk? 17
- 18. © 2016 IHS Markit. All Rights Reserved. Your mileage may vary 18
- 19. © 2016 IHS Markit. All Rights Reserved. Meet Our Protagonist 19
- 20. © 2016 IHS Markit. All Rights Reserved. 20
- 21. © 2016 IHS Markit. All Rights Reserved. 21
- 22. © 2016 IHS Markit. All Rights Reserved. 22
- 23. © 2016 IHS Markit. All Rights Reserved. 23
- 24. © 2016 IHS Markit. All Rights Reserved. 24 XKCD
- 25. © 2016 IHS Markit. All Rights Reserved. I’d like to get to know you! 25
- 26. © 2016 IHS Markit. All Rights Reserved. Setting the Stage • 5 teams, 5-9 each (including QA) • Mix of Scrum/Kanban/Scrumban • Thick Client • C++ • Mature Codebase • Oil & Gas Engineering Analytics • Recently Adopted Agile • Major Project – Client / Server 26
- 27. © 2016 IHS Markit. All Rights Reserved. ” “ The best architectures, requirements, and designs emerge from self-organizing teams. 27 Agile Manfesto
- 28. © 2016 IHS Markit. All Rights Reserved. Architecture Approach 1: Laissez Faire 28
- 29. © 2016 IHS Markit. All Rights Reserved. 29 HELP!!!
- 30. © 2016 IHS Markit. All Rights Reserved. ” “ Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 30 Agile Manifesto
- 31. © 2016 IHS Markit. All Rights Reserved. Empowerment is more than just taking your hands off the wheel 31
- 32. © 2016 IHS Markit. All Rights Reserved. 32
- 33. © 2016 IHS Markit. All Rights Reserved. How do we incorporate an architect… without sacrificing agile values? 33
- 34. © 2016 IHS Markit. All Rights Reserved. We want to avoid this: 34 Requirements Design Code Test Deploy
- 35. © 2016 IHS Markit. All Rights Reserved. And this: 35 cliparthut.com
- 36. © 2016 IHS Markit. All Rights Reserved. Architecture Approach 2: The Architecture Scout 36
- 37. © 2016 IHS Markit. All Rights Reserved. I have a hypothesis! An idea you can test! 37
- 38. © 2016 IHS Markit. All Rights Reserved. My Hypothesis: • If I feed the team’s a continuous stream of prototypes and examples • Then they will have enough information to be productive • AND • They will take ownership over their designs 38
- 39. © 2016 IHS Markit. All Rights Reserved. Architecture by Example 39
- 40. © 2016 IHS Markit. All Rights Reserved. 40
- 41. © 2016 IHS Markit. All Rights Reserved. Problem 1: Mistakes everywhere! 41
- 42. © 2016 IHS Markit. All Rights Reserved. 42 IF YOU COULD JUST GO AHEAD AND REDO THE LAST 2 WEEKS OF WORK THAT’D BE GREAT
- 43. © 2016 IHS Markit. All Rights Reserved. Problem 2: Team disagreements 43
- 44. © 2016 IHS Markit. All Rights Reserved. 44 Too many classes makes the system too complex! Big classes make the system unmaintainable!
- 45. © 2016 IHS Markit. All Rights Reserved. 45
- 46. © 2016 IHS Markit. All Rights Reserved. 46 WORK HARDER!
- 47. © 2016 IHS Markit. All Rights Reserved. Problem 3: What if the architect is WRONG? 47
- 48. © 2016 IHS Markit. All Rights Reserved. How do you know if the architect is WRONG? 48
- 49. © 2016 IHS Markit. All Rights Reserved. ” “ No battle plan every survives contact with the enemy 49 Helmuth von Moltke the Elder
- 50. © 2016 IHS Markit. All Rights Reserved. ” “ I thought you knew something I didn’t 50
- 51. © 2016 IHS Markit. All Rights Reserved. Epiphany: Architect is a leadership role 51
- 52. © 2016 IHS Markit. All Rights Reserved. 52 xkcd.com
- 53. © 2016 IHS Markit. All Rights Reserved. 53 Image Source: worklifematters.net Spotify Engineering Videos
- 54. © 2016 IHS Markit. All Rights Reserved. How do I serve the teams without telling them what to do? 54
- 55. © 2016 IHS Markit. All Rights Reserved. Intent-Based Leadership 55 Rob van Hilten, Flickr
- 56. © 2016 IHS Markit. All Rights Reserved. ” “ Don’t move information to authority, move authority to the information 56 David Marquet
- 57. © 2016 IHS Markit. All Rights Reserved. ” “ 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. 58 David Marquet
- 58. © 2016 IHS Markit. All Rights Reserved. I intend to… 60
- 59. © 2016 IHS Markit. All Rights Reserved. 61 Image Source: worklifematters.net Spotify Engineering Videos
- 60. © 2016 IHS Markit. All Rights Reserved. 62 Architecture Approach 3: The Architecture Coach Rob van Hilten, Flickr
- 61. © 2016 IHS Markit. All Rights Reserved. ” “ Resist the urge to provide solutions 63 David Marquet
- 62. © 2016 IHS Markit. All Rights Reserved. ” “ Questions communicate values 64 Sean Dunn
- 63. © 2016 IHS Markit. All Rights Reserved. Spend time with the teams 65
- 64. © 2016 IHS Markit. All Rights Reserved. 66 https://www.youtube.com/watch?v=QaZ0L7aDx50
- 65. © 2016 IHS Markit. All Rights Reserved. 67 Make it safe to speak truth to power
- 66. © 2016 IHS Markit. All Rights Reserved. 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 68
- 67. © 2016 IHS Markit. All Rights Reserved. Letting go is hard 69
- 68. © 2016 IHS Markit. All Rights Reserved. 71
- 69. © 2016 IHS Markit. All Rights Reserved. 72
- 70. © 2016 IHS Markit. All Rights Reserved.
- 71. © 2016 IHS Markit. All Rights Reserved. Design Steps • What is the problem you’re trying to solve? • What solutions should we consider? • What are the pros/cons of each solution? 75
- 72. © 2016 IHS Markit. All Rights Reserved. 76 Sources: Edward de Bono, retrospectivewiki.org
- 73. © 2016 IHS Markit. All Rights Reserved. Create a common framework for resolving conflict 77
- 74. © 2016 IHS Markit. All Rights Reserved. Scenario • Design problem with 2 options: > Enforce business rules in the database > Enforce business rules in the domain layer • The design team unanimously agrees to put the business rule in the domain layer • Tech lead brings it back to their team, and they decide to put it in the database 78
- 75. © 2016 IHS Markit. All Rights Reserved. Disagreement is a mechanism for organizational clarity 79
- 76. © 2016 IHS Markit. All Rights Reserved. The end? 81
- 77. © 2016 IHS Markit. All Rights Reserved. Something interesting happened 82
- 78. © 2016 IHS Markit. All Rights Reserved. 83 ?
- 79. © 2016 IHS Markit. All Rights Reserved. Do we still need an architect? 84
- 80. © 2016 IHS Markit. All Rights Reserved. Final Architecture Approach: Architecting as a Team 85 Steve Jurvetson, Flickr
- 81. © 2016 IHS Markit. All Rights Reserved. 86 Image Source: worklifematters.netSpotify Engineering Videos
- 82. © 2016 IHS Markit. All Rights Reserved. Imagine: You leave your team for 1 year 87
- 83. © 2016 IHS Markit. All Rights Reserved. When you return, the architecture has changed dramatically 88
- 84. © 2016 IHS Markit. All Rights Reserved. How do you react? 89
- 85. © 2016 IHS Markit. All Rights Reserved. “This is just too risky!” Wouldn’t it be less risky to leverage the brainpower of your entire team? 91
- 86. © 2016 IHS Markit. All Rights Reserved. “My Architect can’t learn this” Leadership can be taught 93
- 87. © 2016 IHS Markit. All Rights Reserved. Summary • Empowerment is more than standing back • Lead through intent • Every moment is an opportunity to teach • Resist the urge to provide solutions • Let go! • Create a framework for disagreement • Disagreement is a mechanism for organizational clarity 98
- 88. © 2016 IHS Markit. All Rights Reserved. Approach must evolve over time 99
- 89. © 2016 IHS Markit. All Rights Reserved. Architect is a leadership role 100
- 90. © 2016 IHS Markit. All Rights Reserved. And remember… 101
- 91. © 2016 IHS Markit. All Rights Reserved. 102
- 92. © 2016 IHS Markit. All Rights Reserved. Thank You! Chris Edwards chris.edwards@ihsmarkit.com @AgileChrisYYC @ChrisSeanAgile www.ChrisAndSeanAgile.com 103
Editor's Notes
- I’m going to tell you a story. I was scheduled to go in to get allergy testing. For those that have had it, it is a pretty routine operation. It is painless and goes by quite quickly.
- It just happens that morning I had gone in to donate blood. (Gesture to the area in the elbow where they put the needle in) Another routine procedure, and one would think has nothing to do with allergy testing.
- Back to the allergy testing I’m talking to the doctor I like to be really sure about medical stuff, so just for safety I made sure the doctor knew that I had just donated blood. I didn’t think it would affect the allergy tests, but you never know.
- He doctor of course let me know that the two things have nothing to do with each other and it would be fine. (better safe that sorry though!)
- The procedure itself goes fairly quickly. The nurse puts a grid of allergens on your arm and proceeds to prick them into your skin one at a time.
- Here is where I should confess… I’m really not great with needles.
- They have this unfortunate side effect of causing me to lose conciousness. I thought I would be fine though. These were very small pricks and they didn’t hurt it all so I assumed I would be fine. However, the accumulation of this sensation seemed to be building up and I started to feel a bit funny. The nurse was just finishing up and I told her that I was feeling like I might faint. She laid me down immediately and called the doctor in.
- The doctor wants to make sure I’m OK and proceeds to take my heart rate and blood pressure. In order to do this, she presses her stethosocope right into my elbow.
- At this point two things are racing through my head. The first one: OUCH The second: Isn’t she worried this is going to rupture my puncture mark? She knows I just had blood taken?
- At this point two things are racing through my head. The first one: OUCH The second: Isn’t she worried this is going to rupture my puncture mark? She knows I just had blood taken?
- It’s ok, she probably has a really good reason for this.
- After all, she is a doctor.
- After all, she is a doctor.
- 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:
- Anecdote: “Transaction manager”
- Anecdote: Repository replicated many times over
- Anecdote: Repository replicated many times over
- 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
- 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.
- 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.
- Anecdote: Production aggregation -> I just want to hand them the solution! I already have it!
- Pull you out of the argument mode. Physically separate from the design options.
- Pull you out of the argument mode. Physically separate from the design options.
- Anecdote: Database or domain layer?