$30 off During Our Annual Pro Sale. View Details »

Architect: the missing Scrum role

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.

Peter Hilton

January 17, 2022
Tweet

More Decks by Peter Hilton

Other Decks in Technology

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 •
  3. None
  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

  16. None
  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

  23. None
  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

  30. None
  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

  38. None
  39. None
  40. None
  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