Architect: the missing Scrum role

Exploring the gaps between user stories

Scrum doesn’t tell you to do software architecture. It doesn’t tell you not to either. If you build software and only do things mentioned in The Scrum Guide, you will neglect several things you might need. While product owners focus on functional design, software quality and other non-functional requirements suffer. Scrum projects need someone to focus on technical and non-functional stories, the same way the product owner focuses on user stories. Scrum projects need software architects.

This talk explores how a software architect role can complement a development team’s product owner role. Attendees will learn about system level topics that a user-story focus can neglect, such as non-functional requirements, architecture changes, and software maintenance. We will also explore how to prioritise and plan this work alongside user stories.

Transcript

1. @PeterHilton http://hilton.org.uk/ Software architect: the missing Scrum role
2. A Scrum Master and a software architect walk into a bar… 2 @PeterHilton •
4. Software development questions - a selection
5. Security How many days has it been since a CVE* was published for one of your project dependencies? * Common Vulnerabilities & Exposures https://nvd.nist.gov/vuln 5 @PeterHilton •
6. Compliance Who can give you a list of your project’s (transitive) dependencies? Which versions of Log4J do you use? https://logging.apache.org 6 @PeterHilton • 🕵
7. Dependency management How do you prioritise replacing Log4J with LogEvents? How do you plan dependency upgrades? Do you prefer zero-dependencies libraries? ‘Log Events is a small (265kb, no dependencies) logging framework built on top of SLF4J’ https://github.com/jhannes/logevents 7 @PeterHilton •
8. Technical design How will you prevent character encoding bugs ⍰ Time zones 😱 - are you feeling lucky? What’s your internationalization and localization strategy? What are the pre-requisites for published APIs? 8 @PeterHilton • s s
9. Domain modelling How do you represent and validate numbers? What about bank account, telephone, and house ‘numbers’? What’s the correct domain language? 🏥 patientnummer → patient ID → PID → PID nummertje 🤦 https://hilton.org.uk/blog/non-numeric-numbers 9 @PeterHilton •
10. Performance What’s the current highest 
 impact performance bottleneck? Does that depend on exactly what you mean by high, impact, and performance? 10 @PeterHilton • ⛷
11. Whose question is it anyway? Perhaps any developer can answer these questions, but who is responsible for asking them? 11 @PeterHilton • 👤 ?
12. Stakeholder questions What questions do stakeholders outside the team have? 12 @PeterHilton • 🧑💼
13. Can we have one of these? Stakeholder questions
14. Stakeholder questions 1. Where’s the architecture (diagram)? 2. Where’s the marketecture? 3. Why’s the application so slow? 4. Why isn’t there an iPhone version? 14 @PeterHilton • 🧑💼
15. What Scrum isn’t for
17. Project management ‘Scrum defines a project management framework in which development activities—requirements gathering, design, programming—take place.’ Agile Software Development Ecosystems, Jim Highsmith 17 @PeterHilton •
18. Scrum’s scope What is Scrum for? What’s missing? 👀 18 @PeterHilton • not Scrum Scrum
19. Which of these do not appear in The Scrum Guide? architecture documentation estimate requirement testing user experience user story 19 @PeterHilton • 🤔
20. Scrum roles vs development topics 1. Developers 2. Product owner 3. Scrum master 4. … ? 
 Security Compliance Architecture changes Dependency management Technical design Domain modelling Performance 20 @PeterHilton • 👯👯
21. Software architect is the missing Scrum role 😎 21 @PeterHilton •
22. Software architecture
24. Domain, technical design and code modelling ‘A commuting diagram, popularized in software engineering by Mary Shaw.’ Just Enough Software Architecture, George Fairbanks 24 @PeterHilton • Abstract problem Real world with problem Abstract solution Real world 
 with solution simple problem complex problem problem solution
25. Software maintenance categories Separate software maintenance into categories: 1. corrective → bug fixing 2. adaptive → accommodating changes in the environment 3. perfective → improving performance or maintainability 4. preventive → preventing bugs https://en.wikipedia.org/wiki/Software_maintenance#Categories_of_software_maintenance 25 @PeterHilton •
26. Non-functional requirements - pick three! 26 @PeterHilton • Accessibility Adaptability Auditability/control Availability Backup Boot up time Capacity, current and forecast Certification Compliance Config management Cost Data integrity Data retention Dependencies Deployment Dev environment Disaster recovery Documentation Durability Efficiency Effectiveness Elasticity Emotional factors Environmental protection Escrow Exploitability Extensibility Failure management Fault tolerance Flexibility Footprint reduction Integrability Internationalization and localization Interoperability Legal/licensing issues Maintainability Management Memory optimization Modifiability Network topology Open source Operability Performance Platform compatibility Privacy Portability Quality Readability Reliability Reporting Resilience Resource constraints Response time Reusability Robustness Safety Scalability Security Software standards Stability Supportability Testability Throughput Transparency Usability Volume testing
27. Non-functional requirements - pick three! 27 @PeterHilton • Accessibility Adaptability Auditability/control Availability Backup Boot up time Capacity, current and forecast Certification Compliance Config management Cost Data integrity Data retention Dependencies Deployment Dev environment Disaster recovery Documentation Durability Efficiency Effectiveness Elasticity Emotional factors Environmental protection Escrow Exploitability Extensibility Failure management Fault tolerance Flexibility Footprint reduction Integrability Internationalization and localization Interoperability Legal/licensing issues Maintainability Management Memory optimization Modifiability Network topology Open source Operability Performance Platform compatibility Privacy Portability Quality Readability Reliability Reporting Resilience Resource constraints Response time Reusability Robustness Safety Scalability Security Software standards Stability Supportability Testability Throughput Transparency Usability Volume testing
28. Planning architectural work Separate tech backlog vs separate story type Fixed time allocation vs business value prioritisation Bottom-up planning vs top-down planning 28 @PeterHilton •
29. Scrum + architecture
31. The Product Trio Continuous Discovery Habits, Teresa Torres (@ttorres) 31 @PeterHilton • Product Manager Designer Software Engineer
32. The Three Amigos ‘Run smaller workshops that involve one developer, one tester, and one business analyst. A popular name for such meetings is Three Amigos. ’ Specification by Example, Gojko Adzic (@gojkoadzic) 32 @PeterHilton •
33. How architects work with product owners Good software requires more than a good product owner (which is a difficult enough role as it is) Good software requires a partnership between specialists (in several different disciplines) 33 @PeterHilton • 👯
34. Artefacts 34 @PeterHilton • 1. Architecture decision records 2. System component inventory 3. System/infrastructure diagram 4. Risk register (technical risks) 5. Disaster recovery plan Product owners don’t usually read → https://www.datacenterdynamics.com/en/news/aws-us-east-1-outage-brings-down-services-around-the-world/
35. Tech stories ‘Like user stories but for architectural work’ Sounds reasonable like a reasonable analogy to user stories But no protagonist to tell the story Not actually story Relative prioritisation impossible Doesn’t work well 35 @PeterHilton • 🧑💻
36. 🥷 Bottom-up planning Technical/housekeeping tasks 👍 separate tasks 👎 nested in user stories 20 per cent time 㱺 shadow backlog 36 @PeterHilton • 🥷
37. Software architecture planning & prioritisation
41. ‘After how many years will this system be decommissioned?’ Jason Goodman
42. @johncutlefish • https://cutlefish.substack.com/p/tbm-4952-your-calendar-your-priorities Unstructured Innovation/ Experimentation Add New Capabilities Enhance Existing Capabilities Manage Complexity Unplanned work / Interruptions Add New Capabilities Unplanned work / Interruptions Unplanned work / Interruptions Enhance Existing Capabilities Manage Complexity Do this… Not this … or this will happen
43. Separate backlog Instead of tech stories mixed with user stories, use a parallel backlog for non-functional requirements work Instead of comparing user stories and tech tasks’ value, adjust how you split your effort between them 43 @PeterHilton • 🍎 ≠ 🍊
44. Filling jars with rocks, stones, and sand Denise Johnson microservices
45. Top-down planning Technical vision ▶︎ Where we can get to in the future (1-3 years) Roadmap ▶︎ How we might 
 get there (1-3 quarters) Backlog ▶︎ What we are working on (1-3 weeks) 45 @PeterHilton •
46. Technical vision and roadmap What are the rocks for the next 1-3 years? Which long-term initiatives start this year? 46 @PeterHilton • Q1 Q2 Q3 🧑🔧🧑🔧🧑🔧 Q4 🧑🔧🧑🔧🧑🔧 🧑🔧🧑🔧🧑🔧
47. Similar responsibilities to the product owner’s Aligning with business strategy Communicating with executive stakeholders Spending development budget Managing risk Saying ‘it depends’ in meetings 47 @PeterHilton • 🤷
48. Summary
49. Summary 1. The Scrum Guide doesn’t say you should do architecture 2. It doesn’t say you shouldn’t either 3. Scrum’s product owner cannot own architecture issues 4. Software architect is the missing Scrum role 5. I don’t care if you call it lead engineer or tech lead instead 6. Planning and prioritisation is hard 7. Both both functionality and architecture need planning 49 @PeterHilton •
50. @PeterHilton http://hilton.org.uk/ https://hilton.org.uk/presentations/architect