Agile architecture.and.programmanager
2 likes1,242 views
The document discusses the role of agile architects on programs and projects. It notes that programs involve coordinating several projects into a single deliverable. Agile architects can provide just-in-time attention to teams through activities like wayfinding, scouting, architecture spikes, and vertical prototypes. The document outlines challenges like communication, risk management, and deciding when to make architecture decisions in a program context. It proposes using an architectural backlog and kanban to manage this work.
Agile architecture.and.programmanager
- 1. The Agile Architect and the Project/Program Manager Johanna Rothman New: Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects @johannarothman www.jrothman.com jr@jrothman.com 781-641-4046
- 2. Agile Architect “Isn’t that an oxymoron?” We need agile architects on programs We often need agile architects on projects We use them differently than on serial lifecycle projects 2 © 2011 Johanna Rothman
- 3. A Program Organization and coordination of several projects’ results into one deliverable. That deliverable has the value to the organization 3 © 2011 Johanna Rothman
- 4. Two Architecture Myths “We can just can churning out features and let the architecture evolve and never look to the future.” “We must spend months doing BDUF without proving any framework with a single feature” Both lead to architecture debt and technical debt Both lead to unhappy project and program managers 4 © 2011 Johanna Rothman
- 5. The Wrong Kind of Architects 5 © 2011 Johanna Rothman
- 6. Program Management of Concurrent Projects 6 © 2011 Johanna Rothman
- 7. What Do you Need on a Feature Team in a Program? Enough developers and testers to swarm around a feature Enough “other” people to finish a feature (writers, BA, DBA, UX, whatever the product needs) Architect attention 7 © 2011 Johanna Rothman
- 8. Just-in-Time Architect Attention Wayfinding: just what is waiting for us out there, anyway? Scouting: explore potential paths Architecture spike to answer architectural questions Vertical prototype: bigger than an XP design spike 8 © 2011 Johanna Rothman
- 9. Agile Business Value Triad 9 © 2011 Johanna Rothman
- 10. Programs Are Riskier Than Projects You all know that projects don’t scale The larger and the longer the program, the more risky it is The more pieces the program has, the more risky it is Hardware and software Mechanical and hardware and software Embedded and hardware and software Regulated industries 10 © 2011 Johanna Rothman
- 11. Making Risks Transparent Many people say, “Just do Scrum-of-Scrums” Scrum-of-Scrums has its place, and it’s not for everyone Remember Scrum is not the only agile framework A Scrum Master is not a project manager A Scrum Master does not manage technical risks A Scrum Master is not an architect 11 © 2011 Johanna Rothman
- 12. Issues in Program Management Especially in concurrent projects, how do you manage, what do you manage when you have 7, 18, 25 teams of people all working on the same product? Backlog management When to make architecture decisions and perform architecture work Managing the risks, up, down, sideways How to understand and explain status 12 © 2011 Johanna Rothman
- 13. Communication in an Agile Team Communication Paths=(N*N-N)/2 4 people, (16-4)/2=6 5 people, (25-5)/2=10 6 people, (36-6)/2=15 7 people, (49-7)/2=21 8 people, (56-8)/2=24 9 people, (81-9)/2=36 10 people (100-10)/2=45 13 © 2011 Johanna Rothman
- 14. Communication Problems on a Program 14 © 2011 Johanna Rothman
- 15. Need to Organize as a Program S-o-S works for small programs, of up to, say, 7 teams. What about more teams? There are too many people for a daily standup Possibly too many risks for the program team to manage Organize as a program 15 © 2011 Johanna Rothman
- 16. Programs Have Been Around Forever Whenever you need to integrate deliverables across the organization, you use program management approaches Cross-functional team who commits to their deliverables on a timely basis Difference is that architects (and architecture) are built into the teams, not up front 16 © 2011 Johanna Rothman
- 17. One Approach to Programs I’ve Used for Decades (Not Agile) 17 © 2011 Johanna Rothman
- 18. What Agile Architects Might Do Create Landing Zone with Architecture investigation PPO Design spike related task Prototype Scout (Design by Walking Wayfind Around) Roadmap exploration Watch out for debt of all Architecturally meaty kinds feature .... Prototype YMMV 18 © 2011 Johanna Rothman
- 19. Example: Landing Zone Specify and update the landing zone as the feature teams build features What do we know more about? What do the tests tell us about technical debt? How does the landing zone prevent technical debt? Do our prototypes tell us anything about the features and the landing zones? 19 © 2011 Johanna Rothman
- 20. How Do We Manage Architectural Work? Add to the Program Backlog Keep a separate architecture backlog Have a separate architecture kanban 20 © 2011 Johanna Rothman
- 21. Backlog and Architecture Kanban: Realize a Task Needs to Start 21 © 2011 Johanna Rothman
- 22. Work on a Task in Architectural Kanban 22 © 2011 Johanna Rothman
- 23. Architectural Kanban: Finish 23 © 2011 Johanna Rothman
- 24. Feature-itis Do You Have Feature-itis? blog entry Requires project/program managers stand up to PO PMs need nerves and backbones to do their jobs And make sure you have the conversation nicely 24 © 2011 Johanna Rothman
- 25. Decisions, Decisions, Decisions When to make architectural decisions When is the most responsible moment? How long can you wait? How long should you wait? 25 © 2011 Johanna Rothman
- 26. What do You Think? 26 © 2011 Johanna Rothman
- 27. Last vs. Most Responsible Moment 27 © 2011 Johanna Rothman
- 28. Product Delivery and Architecture Decisions Typical Product Delivery Cost of delivery User involvement When to make architecture Mechanism or update with update decisions Software as a Service (SaaS) Negligible 0 As late as responsible Boxed (Shipped) software Minimal Total As late as responsible Low to Last responsible moment, but not Firmware upgradeable in the field Minimal manageable later As early as responsible because of Hardware or other difficult-to- High Significant program risks (development and upgrade product delivery) 28 © 2011 Johanna Rothman
- 29. Agile Architects Work across the program With the program manager and the program product owner In a large enough program, with a team of architects working with feature teams, throughout the lifetime of the release Exploring the possibilities just in front of the feature teams Their work must be visible, whether it’s in a backlog or a kanban Make decisions based on risk 29 © 2011 Johanna Rothman
- 30. References and Reading Manage It! and Manage Your Project Portfolio have a number of how-to’s on programs Tons more on jrothman.com If you’d like me to stay in touch with you, please sign up for my email newsletter on http://www.jrothman.com/pragmaticmanager I appreciate Hayim for organizing this talk on such short notice. I appreciate Dima and SAP for letting us use this space. Thank you. I appreciate all of you for being here! I would love to connect with you on LinkedIn as a token of my appreciation. 30 © 2011 Johanna Rothman