A proposed framework for Agile Roadmap Design and Maintenance

1. 1 © Jerome Kehrli @ niceideas.ch A proposed framework for Agile Roadmap Design and Maintenance

2. 2 1. An Agile Roadmap

3. 3 We are not going to end up with this… (I am not saying this doesn’t work, but it definitely doesn’t work for us)

4. 4 Aligns with company strategy, rallies all around this and steers us towards delivering on this strategy Focuses on delivering customer value & articulating benefits Excites our customers about our company & product direction Reflects what we have learned, over time, as an organisation Does not pretend to have all the answers, or indeed need to Characteristics of a Good Roadmap Done well, a roadmap is a strategic communication tool, a statement of intent and direction © Roy Belchamber @ NetGuardians

5. 5 Excessive granularity – too much focus on detail and dates means it will inevitably soon be inaccurate or even obsolete! Mistakenly thinking every item in the roadmap demands upfront design and estimation – this is impossible & wasteful Believing each stakeholders must personally value every item Ensuring our roadmap is not conflated with our product release plan! Potential Pitfalls It is possible to set clear direction & simultaneously embrace uncertainty inherent in product development © Roy Belchamber @ NetGuardians

6. 6 The Roadmap as a Strategic Tool Elements Product Vision Timeframes Themes Business Objectives * Disclaimer Focus on outcomes (strategic) not on outputs (tactical) A good roadmap starts with a vision of where we are going, guides us there and explains the stops along the way… Outcomes Roadmap Now Next Later Backlog Outputs Backlog Backlog Backlog Inspired from Roy Belchamber @ NetGuardians

7. 7 The Roadmap Illustrated Elements Product Vision Timeframes Themes Business Objectives * Disclaimer PRODUCT VISION RIA Organizer providing UX of Desktop applications Our product vision is our guiding principle Inspired from Roy Belchamber @ NetGuardians

8. 8 Elements Business Objectives Timeframes The Roadmap Illustrated Product Vision Themes * Disclaimer PRODUCT VISION RIA Organizer providing UX of Desktop applications H1/2021 H2/2021 2022 Future Broad timeframes avoid overcommitment - It is the sequence that matters (now, next, future) Inspired from Roy Belchamber @ NetGuardians

9. 9 The Roadmap Illustrated Elements Product Vision Timeframes * Disclaimer PRODUCT VISION RIA Organizer providing UX of Desktop applications H1/2021 H2/2021 2022 Future Email CRUD Focus on outcomes not outputs. Themes are not granular features and functions Email Search Attachment Management RTF Emails and appointments description HTML Emails and appointments Scheduler Genius Cal. Search Contact Search Contact CRUD Calendar CRUD Business Objectives Themes Outlook compatibility Inspired from Roy Belchamber @ NetGuardians

10. 10 The Roadmap Illustrated Elements Product Vision Timeframes Themes Business Objectives * Disclaimer PRODUCT VISION RIA Organizer providing UX of Desktop applications H1/2021 H2/2021 2022 Future What goals will our product accomplish? What outcomes? Email CRUD Email Management MVP Email Search Google-like experience on emails Cal. Search Google-like experience on appointments Contact Search Advanced Contacts Management Contact CRUD Contact Management MVP Calendar CRUD Calendar Management MVP Attachment Management RTF Emails and appointments description HTML Emails and appointments Scheduler Genius Outlook compatibility Inspired from Roy Belchamber @ NetGuardians

11. 11 The Roadmap Illustrated PRODUCT VISION RIA Organizer providing UX of Desktop applications H1/2021 H2/2021 2022 Future Protects against claims of broken promises by explaining that changes can happen Email CRUD Email Management MVP Email Search Google-like experience on emails Cal. Search Google-like experience on appointments Contact Search Advanced Contacts Management Contact CRUD Contact Management MVP Calendar CRUD Calendar Management MVP Attachment Management RTF Emails and appointments description HTML Emails and appointments Scheduler Genius Outlook compatibility Elements Product Vision Timeframes Themes Business Objectives * Disclaimer * Updated 30 April 2021, subject to change without notice Inspired from Roy Belchamber @ NetGuardians

12. 12 R&D The Hierarchy… What Why How Why we are doing this? Why it aligns with our strategy What customer problems will we solve? Finally, how should we solve it? Roadmap Now Need Next Later Product Mgmt Backlog Backlog Backlog Inspired from Roy Belchamber @ NetGuardians

13. 13 Let’s have a look at something more realistic

14. 14 An Outcome-Based Roadmap – How it Could Look PRODUCT VISION Product Vision Statement * Updated 30 April 2021, subject to change without notice Outcome Roadmap - Up To 2023 Team May Jun Jul -Q3/2021 Q4/2021 H1/2022 H2/2022 2023 Research Analytics prototype 1 Analytics Research 1 Analytics Research 2 Analytics Proto. 2 Analytics Res. 3 Software Technology Research 1 Software Technology Research 2 Dev FT 1 H2 Evolution 1 Project C Gaps Project E Gaps H2 Evolution 4 H1 Evolutions batch 4 Dev FT 2 Project A Gaps H2 Evolution 3 H3 Evolution 3 H1 Evolutions Batch 1 Project D Gaps Dev FT 3 Project B Gaps H3 Evolution 1 H1 Evolutions Batch 2 Dev FT 4 H2 Evolution 2 H3 Evolution 2 H1 Evolutions Batch 3 Project E Gaps H2 Evolution 5

15. 15 An Outcome-Based Roadmap – How it Could Look PRODUCT VISION Product Vision Statement * Updated 30 April 2021, subject to change without notice Outcome Roadmap - Up To 2023 Team May Jun Jul -Q3/2021 Q4/2021 H1/2022 H2/2022 2023 Research Analytics prototype 1 Analytics Research 1 Analytics Research 2 Analytics Proto. 2 Analytics Res. 3 Software Technology Research 1 Software Technology Research 2 Dev FT 1 H2 Evolution 1 Project C Gaps Project E Gaps H2 Evolution 4 H1 Evolutions batch 4 Dev FT 2 Project A Gaps H2 Evolution 3 H3 Evolution 3 H1 Evolutions Batch 1 Project D Gaps Dev FT 3 Project B Gaps H3 Evolution 1 H1 Evolutions Batch 2 Dev FT 4 H2 Evolution 2 H3 Evolution 2 H1 Evolutions Batch 3 Project E Gaps H2 Evolution 5 CERTAINTY & CONFIDENCE DISCOVERY / UNSCHEDULED

16. 16 What we will be discussing now … • What are these teams ? • How are they organized ? • How is the Roadmap managed and evolved ? • What is a good update frequency ? • What is the level of commitment ? • What are these items on the Roadmap • What is H1 / H2 / H3 ? • How are epics estimated ? D A B C

17. 18 2.A - Agile Software Development Teams

18. 19 Reliable forecasting … The whole game is : How to build a team with - A culture - An organization - set of practices and principles that makes estimations and forecasting reliable ?

19. 20 Agile Prerequisites Maturity / Difficulty Agile Development (e.g. Scrum) DevOps Lean Startup Company-wide Kanban / Kaizen Scaling Agile / Agile corporation XP Practices Digital Transformation Dependency

20. 21 Where you should be Maturity / Difficulty Agile Development (e.g. Scrum) DevOps Lean Startup Company-wide Kanban / Kaizen Scaling Agile / Agile corporation XP Practices Digital Transformation Dependency

21. 22 Periodic Table of Agile Principles and Practices https://www.niceideas.ch/roller2/badtrash/entry/periodic-table-of-agile-principles

22. 23 Direct relationship with planning / road-mapping abilities

23. 24 Well actually you need them all ➔ Even only within XP, they all depend on each others XP Practices dependency Graph

24. 25 “If it hurts, do it more often” Firstly most of these tasks become much more difficult as the amount of work to be done increases, but when broken up into smaller chunks they compose easily. The second reason is Feedback. Much of agile thinking is about setting up feedback loops so that we can learn more quickly. The third reason is practice. With any activity, we improve as we do it more often Small releases / Deploy More Often

25. 26 Tests are not optional. There is no continuous delivery without tests. There is no easy release process without continuous delivery. There is no reliable forecasting with stop the world releases. 80% is not an appropriate target anymore, the target is 100% ! Tests, tests and more tests Commit Build Nightly Build

26. 27 Why TDD ? This can be estimated (SP) We need to be able to predict the time things will take. Story Points and the whole Scrum approach are terrific for this. However none of it works if most of the development workload is fundamentally unpredictable Here comes TDD ! This can be estimated (SP) https://www.niceideas.ch/roller2/badtrash/entry/tdd-test-driven-development-is

27. 28 Product Owner = onsite customer Don’t rely on external teams / processes for specification and prioritization ➔ Independent and Autonomous teams Get access to business expertise immediately Streamline and flatten Acceptance Testing Get feedback immediately The Product Owner is able to definitely close a task without any dependency outside of the team. No “stop-the-world” pre-release Acceptance Test campaign Planning Game with Story Points (no man / days !) Transform a difficult estimation process – What is the weight of this stone ? Into an easier comparison process – Is this stone lighter or heavier than this other stone? Planning Poker : consensus-based, gamified technique for estimating effort (relative size) of development goals force people to think independently and propose their numbers simultaneously Onsite customer and Planning Game

28. 29 XP – Take Aways The Product Owner - on-site customer - enables the team to be autonomous and work without interruption by answering questions (refined specifications) immediately and running acceptance tests continuously Acceptance tests / Feedback Refined specifications (DevOps) Continuous Delivery – small releases - enables to avoid Stop-the-world Releases breaking teams autonomy and forcing killing synchronization events Stop the world Release N Stop the world Release N + 1 TDD enables to have reliable forecasts by bringing most of the development team workload to actual development time that can be estimated (vs. unpredictable nasty debugging session, patches and fixed round trips, etc.) The Planning Poker Estimation Game – planning game – enables to have reliable estimations and forecasting abilities (surprisingly much more that traditional waterfall) X X

29. 30 The Lean Startup 1 Customer Discovery 2 Customer Validation 3 Get new Customers 4 Company creation Identify a problem Generate demand Design / Implement the Minimum Viable product Re-adapt the product Problem Interview Solution Interview A/B Testing Measure Obsession Pizza teams Build Vs. Buy Feature Teams Get out of the Building Scaling Agile MVP Fail Fast Growth Hacking Gamification / Viral Marketing ... Pivot Get out of the Building Product- Market Fit https://www.niceideas.ch/roller2/badtrash/entry/lean-startup-a-focus-on

30. 31 Small Teams As team size grows, the number of one-on-one communication channels explodes, following the formula to compute number of links between people which is n ( n - 1) / 2 . This is O(n2) (Hello Engineers) and is really a combinatorial explosion.

31. 32 Introducing Feature Teams (Source : Large Scale Scrum : http://less.works/)

32. 33 The characteristics of a feature team are : long-lived—the team stays together so that they can ‘jell’ for higher performance; they take on new features over time autonomous and independent – no friction with other team complete - support, UI/UX, DevOps cross-functional and cross-component ideally, co-located work on a complete customer-centric feature, across all components and disciplines (analysis, programming, testing, …) Multi-competencies in Scrum, typically 7 ± 2 people Feature Teams (Source : Large Scale Scrum : http://less.works/)

33. 34 Star Trek

34. 35 Component Teams vs Feature Teams Component Team Feature Team optimized for delivering the maximum number of lines of code optimized for delivering the maximum customer value focus on increased individual productivity by implementing ‘easy’ lower- value features focus on high-value features and system productivity (value throughput) responsible for only part of a customer-centric feature responsible for complete customer-centric feature traditional way of organizing teams — follows Conway’s law ‘modern’ way of organizing teams — avoids Conway’s law leads to ‘invented’ work and a forever-growing organization leads to customer focus, visibility, and smaller organizations dependencies between teams leads to additional planning minimizes dependencies between teams to increase flexibility focus on single specialization focus on multiple specializations individual/team code ownership shared product code ownership clear individual responsibilities shared team responsibilities results in ‘waterfall’ development supports iterative development exploits existing expertise; lower level of learning new skills exploits flexibility; continuous and broad learning works with sloppy engineering practices—effects are localized requires skilled engineering practices—effects are broadly visible contrary to belief, often leads to low-quality code in component provides a motivation to make code easy to maintain and test seemingly easy to implement seemingly difficult to implement (Source : Large Scale Scrum : http://less.works/)

35. 36 Product 3 Product 1 Product 2 Component Team vs Product Teams ? Feature teams work tremendously good … within a product ! Having different set of teams for different set of products is mandatory (business vs. technical specialization) Product Teams UI / UX Java backend Data Science / Research Java backend UI / UX Java backend Data / DB Data Science Operators Component Teams Model Product 3 Product 1 Product 2 FT1 Data Science / Research FT1 FT2 FT3 FT4 Feature Teams Model FT2 FT3 Data Science

36. 37 Squads Equivalent to a Scrum Team As Autonomous as possible Tribes Same office < 100 FTE Common area of the system (product) Organized for minimum interdependency Chapters Skills community (community of practices) Chapter lead is line manager Guilds Community of interest Cross tribe groups Guild unconferences The Spotify Way Squad Squad Squad Squad Squad Squad Squad Squad

37. 38 Lean Startup – Take Aways One wants as many independent teams as required to run independent topics in parallel Dev Teams should never ever be exposed to customers directly, they do 3rd level support only Custo- mer Deploy. Refined design Most of the time, a team should have 1 or 2 core focus at a time, typically a long term focus and some more short term fillers. Support Functions : Customer 1st level support, 2nd level support, HR, Management, etc. A feature being given to 1 autonomous team, and that team being able to work without interruption, Team Sprint Velocity enables to do forecasting. A Feature Team implements a Feature from A to Z, where Z is release / deployment to the customer, independently and autonomously. The rule is : as soon as a team has any dependency on another team, estimations and forecasts are not reliable anymore ! (multi-team consolidated planning and forecasting is a much more difficult game !) A to Z includes everything: 3rd level support, documentation, automated tests, code review, IT testing, Acceptance Testing, Release, Deploy, Deployment automation, etc. ➔ EVERYTHING (… DoD) Because the team is autonomous and independent, it’s own planning and forecasts are reliable.

38. 39 DevOps https://www.niceideas.ch/roller2/badtrash/entry/devops-explained Developer Operator

39. 40 DevOps in a nutshell Key For Planning

40. 41 Infrastructure as Code Cloud, Container or VM Instantiation OS Installation System Installation / Configuration Application / Service Deployment / Orchestration • Capistrano • Scripts / Python • Jenkins • Maven • Specific tools • Chef • Puppet • Ansible • Red Hat Satellite • Vagrant • OpenStack • VMWare Vcloud • Docker • OpenShift • ExaLogic • Kubernetes CMDB - Configuration Management Database (All of this is versionned under SVN, git, …) Application Deployment Deploy application code … and rollback Configure resources (RDBMS, etc.) Start applications Join clusters System Configuration JVM, app servers … Middlewares … Service configuration (logs, ports, user / groups, etc. Registration to supervision Machine Installation Virtualization Self-Service environments

41. 42 The more often you deploy, the more you master the deployment process and the better you automate it. If you have to do something 3 times a day, you will make it bullet proof and reliable soon enough, when you will be fed up of fixing the same issues over and over again. The more often you deploy, the smallest will be the changesets you deploy and hence the smallest will be the risk of something going wrong, or the chances of losing control over the changesets The more often you deploy, the best will be your TTR (Time to Repair / Resolution) Key for Planning ! You don’t want to loose time on Deployment You want deployment to be automated You want deployment and production release to happen without you even noticing Key to avoid multiple team synchronization Continuous Delivery – “If it hurts, do it more often” (Source : Ops Meta-Metrics: The Currency You Pay For Change - http://fr.slideshare.net/jallspaw/ops-metametrics-the-currency- you-pay-for-change-4608108)

42. 43 Continuous integration of both the software components development as well as the platform provisioning and setup. TDD - Test Driven Development. This is questionable ... But in the end let's face it: TDD is really the single and only way to have an acceptable coverage of the code and branches with unit tests (and unit tests makes is so much easier to fix issues than integration or functional tests). Code reviews ! At least code reviews ... pair programming would be better of course. Continuous auditing software - such as Sonar. Functional testing automation on production-level environment Strong non-functional testing automation (performance, availability, etc.) Automated packaging and deployment, independent of target environment Continuous Delivery requirements

43. 44 "Zero Downtime Deployment (ZDD) consists in deploying a new version of a system without any interruption of service.“ ZDD consists in deploying an application without interruption of service in such a way that one introduces a new version of an application to production without making the user see that the application went down in the meantime. From the user's and the company's point of view it's the best possible scenario of deployment since new features can be introduced and bugs can be eliminated without any outage. I'll mention 3 techniques: Feature Flipping ➔ Key for Continuous Deployment Shippable version at the end of every sprint Multi-sprint developments become possible without harming Continuous delivery Blue/Green Deployments Canari release Zero Downtime Deployments

44. 45 Feature flipping allows to enable / disable features while the software is running. It's really straightforward to understand and put in place: simply use a configuration properly to entirely disable a feature from production and only activate it when its completely polished and working well. For instance to disable or activate a feature globally for a whole application: Or if one wants to do it on a per-user basis: Feature flipping

45. 46 Blue/Green Deployments consists in building a second complete line of production for version N + 1. Both development and operation teams can peacefully build up version N + 1 on this second production line. Whenever the version N + 1 is ready to be used, the configuration is changed on the load balancer and users are automatically and transparently redirected to the new version N + 1. At this moment, the production line for version N is recovered and used to peacefully build version N + 2. And so on. Blue/Green Deployments (Source : Les Patterns des Géants du Web – Zero Downtime Deployment - http://blog.octo.com/zero-downtime- deployment/)

46. 47 Canari release is very similar in nature to Blue/Green Deployments but it addresses the problem to have multiple complete production lines. The idea is to switch users to the new version in an incremental fashion : as more servers are migrated from the version N line to the version N + 1 line, an equivalent proportion of users are migrated as well. At first, only a few servers are migrated to version N + 1 along with a small subset of the users. This also allows to test the new release without risking an impact on all users. When all servers have eventually been migrated from line N to line N + 1, the release is finished and everything can start all over again for release N + 2. Canari Release (Source : Les Patterns des Géants du Web – Zero Downtime Deployment - http://blog.octo.com/zero- downtime-deployment/)

47. 48 DevOps – Take Aways Custo- mer Deploy. Automated tests – End-to-End tests – on integration and tests environment are key to avoid debugging sessions and production regressions. Infrastructure as Code enables to streamline and automated end-to-end tests on production-like test environments and is key to Continuous Delivery. Finally, Automated tests should validate non-functional requirements. Stop the world Release N Stop the world Release N + 1 Releasing / Deploying to customer has to be a marginal, one-day, push-a-button event. Continuous Delivery techniques are absolutely key to avoid stop-the-world releases / deployments which breaks the team independence and autonomy, which, again, is absolutely key to have accurate forecasts. Just as TDD eliminates unpredictable development-related tasks, Continuous Delivery and ZDD techniques enable to eliminate unpredictable deployment-related tasks. X X

48. 49 2.B – The 3 Horizon Framework

49. 50 Business Economics The need for innovation Technological Progress Cumulative Effort Technology S-curve Technology Profit Curve Profit Time

50. 51 The 3 Horizon model (McKinsey) The 3 horizons model is a growth strategy framework by McKinsey that you can use to think about the future of your company. Value Time / Effort H1 1-2 years H2 2-4 years H3 3-5 years Technology S-curve Technology Profit Curve Horizon 1 Maintain & strengthen core business Horizon 2 Explore & discover emerging expansions / opportunities Horizon 3 Create genuinely new businesses / competencies / possibilities

51. 52 The 3 Horizon model (McKinsey) Value Time H1 H2 H3 Horizon 1 Maintenance, functional evolutions, Project Gaps The first horizon involves implementing innovations that improve current operations Horizon 2 Product & Technology Evolutions Horizon 2 innovations are those that extend your current competencies into new, related markets. Horizon 3 Disruption, new technologies, new product Horizon 3 innovations are the ones that would change the nature of your industry and generate new competencies NG : now – 18 months NG : 6 – 24 months NG : 1 – 3 years

52. 53 A sound approach to Product Management Value Time H1 H2 H3 NG : now – 18 months NG : 6 – 24 months NG : 1 – 3 years Current Backlog H1 H1 H1 H1 H1 H1 H1 H1 H1 H1 H1 H1 H2 H2 H2 H2 H2 H2 H2 H2 H2 H3 H3 H3 H3 H3 H3

53. 54 3 Horizon Framework – Take Aways Multiple Teams enable to spread workload among the 3 horizons (fair share) Some epics / stories - often related to projects - can sometimes not be estimated properly because the scope is blurry. In this case we take reserve. Some backlog fillers - small tasks - are used to fill in the gaps Type of Stories / Epics on the roadmap - Product evolutions (PMC) - Functional evolutions (PMC, BA, PO) - Technology evolutions and maintenance (CTO) - Projects Gaps (Delivery) - Evolution / Improvement batches (Delivery, Sales, R&D, etc.) ➔ Granularity has to be "large topics" or "important topic" or customer / delivery commitments Multiple small tasks in H1 – delivery wishes, minor bug corrections, cosmetic changes, UX improvements, small evolutions – etc, are grouped together by theme and scope in an Evolution batch. The Evolution batch is then prioritized and scheduled as a consistent unit. Have the Teams switch / rotate between H1 / H2 / H3 to avoid frustration

54. 55 2.C – The Estimation Process

55. 56 Key Product-related Roles Product Manager(s) ➔ Marketing / Corporate Function • Product Marketing / Market studies • Voice of customers / market • Animates PMC • Roadmap Maintenance • Story Map Product Owner(s) ➔ Dev Team Function • Represents / Liaise with PMC • Business Analysis • Acceptance Tests • Release Management • Backlog prioritization • Release Notes • Development Story Specification Team Leader(s) • Liaise with Product Owner • Fill-in Team Sprint backlog • Animates team rituals • Dev Team Management (People Management) Architect(s) / UX / Data Science • Functional / Application Architecture • Technical / System Architecture • User Experience • Data Architecture • Epic Specification • Epic Breakdown in Dev Tasks • Tasks Estimation Tech Lead • Application / Technical Design • Developer support • Epic Specification • Epic Breakdown in Tasks • Tasks Estimation Developers… • Full-stack development • Operation Automation • Deployment Automation • Documentation • Support CTO - Architecture Lead - Voice of technology - Software Development Methodology guarantor - Cloud Operations Management - Animates ARCHCOM + of course 1st Level support / 2nd Level support / Scrum Master / Perhaps Cloud Operations / etc.

56. 57 Key Rituals Product Management Committee - PMC Product Manager(s) Product Owner(s) Head of Sales CTO Preparation: PM collects opportunities and needs Walkthrough: Promote / Eliminate / Prioritize Evolutions Offline: PM prepares User stories Offline: later, continuously, collect estimations then update roadmap Architecture Committee - ARCHCOM Preparation: CTO and Product Owner creates Epics corresponding to stories Walkthrough: N: Dispatch epics to be specified Offline: review specifications and comment / challenge N + 1: discuss comments and amend Offline: breakdown in tasks, tasks estimation Product Owner(s) Team Leader(s) CTO Architect(s) Tech Lead + of course TechCom / Sprint planning / Sprint retro / Daily scrum / Delivery Rituals / Management Rituals (O3s) / etc.

57. 58 A typical development month Monday Tuesday Wednesday Thursday Friday Sat Sun Sprint planning Sprint Retro Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Sprint planning Sprint Retro Test Deployment Sprint N Sprint N+1 ARCHCOM ARCHCOM ARCHCOM ARCHCOM PMC Test Deployment Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. Integration Depl. UX Committee UX Committee Tech Committee Tech Committee Integration Depl. Integration Depl. ARCHCOM PMC UX Committee Tech Com. Cross-team meetings (company wide): All these rituals are prepared in advanced by all participants! Rituals are clearly and consistently scheduled / no unforeseen interruption of sprint Delivery Project Gaps Review Proj. Gaps Rev.

58. 59 The Estimation Process Story Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed … Detailed Story Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim … Development Epic Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Task Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed … Task Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed … Task Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed … Specification & Design Process Estimation Process PMC PM PO CTO / / PM PO / Roadmap Tm. L PO CTO / Archi. / / CTO ARCHCOM Tm. L Archi. CTO Tk. L Delivery wishes Task Task Task Development Epic Story ARCHCOM Specification Design Estimations Planning 21 34 55 110 110 Product Management R&D Tk. L Developers PM PM PO CTO / PO CTO / UPDATES!

59. 60 Picking-up the extremes makes only little sense : people are sick, leaves on holidays, some big task gets finished the next sprint, etc ➔ So we should pick up the second and last-but-one. This gives us a lower range and an upper range ➔ Using a range addresses uncertainty (REMINDER) Team Sprint Velocity   Uncertainty 138 128 Story Points Sprint

60. 61 Range is used this way: In case of fixed time, when we have a fixed delivery date, the lower and upper values give us the minimum or maximum set of features we can have implemented at that date. In case of fixed scope, when we have to release a version of the software with a given set of features, the lower and upper values are used to compute earliest or latest release date We now have everything we need for accurate estimations (REMINDER) Forecasting Story Points Months Team. L PO /

61. 62 Estimation game – Take Aways We can compute the Team Sprint Velocity In this model, Project Gaps are the only items with hard commitment. A Delivery project being planned and with a Go-Live date, the related deliverables due date has to be respected. When designing the roadmap, these are put first and can’t be moved afterwards (frozen items) 120 150 110 180 170 The estimation game tells us the total story points for this Story. With the team capacity, it can be planned in terms of number of sprints, assuming 2 sprints per month. The keyword here is reserve, reserve and more reserve. D D D D D D These batches are where we have some flexibility for urgent stuff popping up! Fixed scope: keep all tasks in the batch and add new stuff. Fixed date (fixed roadmap): add new stuff and remove an equal amount of SP

62. 63 2.D – Roadmap timeline

63. 64 Now about the timeline PRODUCT VISION Product Vision Statement * Updated 30 April 2021, subject to change without notice Outcome Roadmap - Up To 2023 Team May Jun Jul -Q3/2021 Q4/2021 H1/2022 H2/2022 2023 Research Analytics prototype 1 Analytics Research 1 Analytics Research 2 Analytics Proto. 2 Analytics Res. 3 Software Technology Research 1 Software Technology Research 2 Dev FT 1 H2 Evolution 1 Project C Gaps Project E Gaps H2 Evolution 4 H1 Evolutions batch 4 Dev FT 2 Project A Gaps H2 Evolution 3 H3 Evolution 3 H1 Evolutions Batch 1 Project D Gaps Dev FT 3 Project B Gaps H3 Evolution 1 H1 Evolutions Batch 2 Dev FT 4 H2 Evolution 2 H3 Evolution 2 H1 Evolutions Batch 3 Project E Gaps H2 Evolution 5

64. 65 Short-term vs. Long-term commitments Outcome Roadmap - Up To 2023 Team May Jun Jul -Q3/2021 Q4/2021 H1/2022 H2/2022 2023 • Hard commitment - no slippage should occur • due dates are respected / fixed • Scope can evolve (support, critical bug fixes, etc.), in which case tasks of lesser priority can be postponed • Transparent communication to delivery, sales, customers, etc. • Strong commitment – slippage should support business opportunities • Opaque communication • Soft commitment – this can really change entirely if required • Cautious communication • Internal only • No commitment • No communication Month Granularity Quarter Semester Year

65. 66 Timeline evolution April Roadmap Outcome Roadmap - Up To 2023 Team May Jun Jul -Q3/2021 Q4/2021 H1/2022 H2/2022 2023 May Roadmap Outcome Roadmap - Up To 2023 Team Jun Jul Aug Sep Q4/2021 H1/2022 H2/2022 2023 Jun Roadmap Outcome Roadmap - Up To 2023 Team Jul Aug Sep Q4/2021 Q1/2022 Q2/2022 H2/2022 2023 M+1 M+1 Oct Roadmap Outcome Roadmap - Up To 2024 Team Nov Dec Jan/2022 -Q1/2022 Q2/2022 H2/2022 H1/2023 H2/2023 – H1/2024 M+4

66. 67 “Stop the world” refactoring or technology evolutions ? Feature flipping, API versioning, library versioning, etc. If a “stop-the-world” refactoring or evolution can’t be avoided, it needs to be planned and accounted in the roadmap (big vertical box) Kaizen burst Every end of quarter PMC starts with a Quarter retrospective Challenge everything ! Delivery SaaS : continuous deployment On-premise deployment continuous delivery, periodic end customer releases. Migration is a concern. Specific rituals are required between PM and Delivery Teams ➔ Doesn’t change a whole lot of things for planning Other aspects

67. 68 SaaS / Cloud / Web deployment Amazon - Continuous Deployment in production - Code is being deployed in production every 11.7 seconds on average. - Continuous Deployment in production - Devs push code to production thousands of times per day! - Develop for failure - Chaos monkeys randomly kills services and machines continuously Facebook - Continuous Deployment in production - Before 2016, - Up to 3 release trains a day - Cherry pick (manual) / periodic resync - Since 2016 - Release train every few hours - Push from master

68. 69 On premise deployments 8.3-SN. 14329 8.3-SN. 14361 8.3-SN. 14398 R 8.3 8.4-SN. 14475 R 8.4 B B R 8.5 R 8.6 R 9 B B B B B B End of Sprint Release - Internal Release / Automated deployment on Test Env. Customer Release - Official Release / Deployable and versioned package with release notes, etc.

69. 70 3. Take Aways and other models

70. 71 Take Aways XP • TDD / Tests Coverage • On-site customer (Product Owner ) • Code Reviews • Sustainable Pace • Small Releases (Continuous Delivery) • Acceptance tests • Planning Game Scrum • DoD - Definition of Done • Sprint planning / Spring Retro • Daily Scrum • Product Increment (Continuous Delivery) • Estimation Game / Planning Poker / SP • Product Backlog • Team Velocity • Product Owner Lean Startup • Pizza Teams • Feature Teams • Feedback Loop DevOps • Automated Provisioning • ZDD • Feature Flipping • Automated Releases • Continuous Delivery Product Management • Story Mapping • PMC • Product Vision • Roadmap Maintenance Reliable Roadmap

71. 72 Required Tools Need Tool Description Collaborative source code development git Need to be able to have a large number of concurrent branches and convenience for managing them. Feature Branches and Code reviews Gitlab (or gitbucket, etc.) Enforcing code reviews Merge request / Pull requests. Comments arbitration, conflicts resolution, etc. Continuous Integration and automated tests Gitlab CI (or jenkins, etc.) Integration test suite on every branch at every commit, full automated tests twice a day. Deployment Automation Integration deployment twice a day, test deployment end of every sprint, environment promotion, etc. Sprint backlog management Jira Sprint Kanban board, Sprint burndown chart, etc. Product Backlog Management Product backlog, Stories, Epics and task specification and relations, priorities management, etc. Documentation as Code ASCIIDoc Version-able documentation and editing integrated in development processes End-to-End tests Selenium (or Protractor, etc.) Production-like environment non-regression tests Infrastructure as Code Ansible (or Chef, Puppet) Environment provisioning, automated installation and deployment. Database migration Liquibase Automated DB updates Code quality Sonar Code Quality guarantee Development Manifesto Wiki (e.g. confluence, etc.) Document your culture, values, organization, principles and practices (light !) Planning Poker www.pointingpoker.com Distributed planning poker app Kanban / Visual Board Trello (or MS Planner, etc.) ARCHCOM Topics, discussion topics, prioritization games, etc. Agenda Outlook Rituals over processes Roadmap Powerpoint / Excel If you need more than excel or Powerpoint to draw your roadmap, then your roadmap is not the right one. Plenty of others …

72. 73 Other Model : Holacracy Every Team is a Project team - Circle (ultimate Feature Team); there are transverse projects Every Team – Circle - has its own culture, organization, processes, rituals, tools, etc. as require to fulfill its objectives and purpose Governance – where dependencies and streams between Teams – Circles – are defined is key (and tricky) (from https://www.tealschool.se/2019/07/12/holacracy-for-schools/)

73. 74 Other models Fixed time – fixed release dates roadmap Flexible / variable scope Commitment comes from identifying the subset of stories we have to stick to and the ones that are fillers Fixed scope – fixed content releases Flexible release dates Other aspects … Management 3.0 Google-like Office space Scaling Agile Other aspects / final notes

74. 75 Thanks for listening

A proposed framework for Agile Roadmap Design and Maintenance

A proposed framework for Agile Roadmap Design and Maintenance

Recommended

More Related Content

What's hot

What's hot(20)

Similar to A proposed framework for Agile Roadmap Design and Maintenance

Similar to A proposed framework for Agile Roadmap Design and Maintenance(20)

More from Jérôme Kehrli

More from Jérôme Kehrli(18)

Recently uploaded

Recently uploaded(20)

A proposed framework for Agile Roadmap Design and Maintenance