Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1
© Jerome Kehrli @ niceideas.ch
https://www.niceideas.ch/roller2/badtrash/entry/agile-planning-tools-and-processes
Agile ...
2
1. Introduction
2. Fundamentals
2.1 Extreme Programming
2.2 Scrum
2.3 DevOps
2.4 Lean Startup
2.5 Visual Management and ...
3
1. Introduction
4
Why Agile in anyway ?
The problems with Waterfall
Incomplete or moving specifications
Tunnel effect
Drop of Quality to m...
5
Agilty is a lot of things (1/2)
6
It’s up to every organization to decide and pick up the principles and practices
that make sense to it!
What I will be p...
7
2. Fundamentals
8
Agility down the line …
9
2.1 Extreme Programming
10
eXtreme Programming in a nutshell
Values
• Communication
• Simplicity
• Feedback
• Courage
• Respect
Activities
• Codin...
11
The fundamentals of Agility : XP Practices
12
2.2 Scrum
13
Scrum in a nutshell
14
Waterfall
Workload managed in terms of time
Tests are done by different roles in different phases
Every role estimates ...
15
2.3 DevOps
16
DevOps principles
Wall of Confusion
Developer Operator
17
DevOps in a nutshell
18
2.4 Lean Startup
19
Lean Startup
(2011)
(2013)
(2011)
(2012)
Alex Osterwalder
Steve Blank
Eric Ries
Ash Maurya
Just in Time !
Only implemen...
20
Lean Startup Practices
21
2.5 Visual Management and Kanban
22
(Source : http://alexsibaja.blogspot.ch/2014/08/obeya-war-room-powerful-visual.html)
Toyota
23
Kanban Board
Story Map
Product Backlog
Sprint backlog
Burndown Chart
See product owner video
Visual Management – Releva...
24
A story map is alive !
Constantly challenged, updated, adapted, changed, !
Story Map
25
Story Map Example
26
A real life example
27
Story Map Garbage
28
Product Backlog = Story Map
with more details
Story Map contains stories
Backlog contains Tasks
Both are kept in sync …...
29
Kanban is Flow oriented
Team capacity instead of Sprint capacity
Kanban
30
Example of Kanban and Story Maps
31
User Story
32
3. Principles
33
3.1 Tools
3.2 Organization
Required Roles
Requires Committees and Teams
3.3 Processes
From Story Map to product Backlog...
34
3.1 Tools
35
Product Story Map
Product Management Tool
Visual Tool
Tools to use
Product Kanban Board
Project Management Tool
Visual ...
36
3.2 Organization
37
Team Leader : animates the Team rituals (such as Sprint Planning, Sprint Retrospective, Daily scrum) and
acts as a coac...
38
Efficiency !
Roles are required to avoid having the whole organization meeting all the
time at every meeting for every ...
39
Required Committees and Teams
Identifies product features and requirements
Rituals :
Product Management Committee (X-We...
40
3.3 Processes
41
From Story Map to Product Backlog
42
Estimations
The Story Map should
contain as up to date
as possible estimations
Again : The story Map
is a management to...
43
Initial Estimations
X
13
Y
60
60
44
Refined Estimations
X
Y
68
68
21
1321
45
Final Estimations
X
Y
81
81
34
2134
46
The management tool is the story map, not the product backlog (too technical,
not visual)
The Product Management should...
47
Product Kanban Board Maintenance (1/5) - Kanban
TakenInnext
Sprint
Specified,
Design and
Estimated by
ARCHCOM
Finisheda...
48
Product Kanban Board Maintenance (2/5) – 1st Sprint
During the first sprint after this initial stage, the Kanban board ...
49
Product Kanban Board Maintenance (3/5) – 2nd Sprint
After first sprint, developed stories are put on the Story Map on t...
50
Product Kanban Board Maintenance (4/5) – After 1st release
Notes:
Actual releases WILL differ : we can release potentia...
51
Product Kanban Board Maintenance (5/5) – No releases in done
The Story Map on the right shouldn't have any notion of re...
52
Backlog is synchronized with Story Map
Ascendingpriority
Every task in
backlog should be
kept in sync with a
Story on S...
53
Synchronization Process
1. Specification and Design
2. Estimations
Sync between both
worlds is manual
Visual World Digi...
54
A task will be
implemented
when
All tasks of
prior releases
are
implemented
AND all tasks
of same
release and
HIGHER
pr...
55
Picking-up the extremes makes only little sense : people are sick, leaves on
holidays, some big task gets finished the ...
56
Range is used this way:
In case of fixed time, when we
have a fixed delivery date, the
lower and upper values give us t...
57
Development process : SCRUM
58
Sprint Kanban
59
3.4 Rituals
60
Story Mapping
Identification of new needs and requirements (also technical and technological !)
Breakdown of these requ...
61
Specification and Design of User Stories
Specification of functional and non-functional requirements
Identification of ...
62
Sprint Planning
 Beginning of sprint
Discuss Development Tasks to ensure whole team has a clear view of what needs to ...
63
Daily scrum
Round table - every team member presents :
Past or current development task
Status on that task and precise...
64
3.5 Values
65
Sticking rituals, respecting principles and enforcing practices is difficult
It’s difficult to ensure and behaves in su...
66
4. Overview of whole Process
67
68
69
1
70
2
1
71
2
1
72
2
3
1
73
2
3
1
4
74
2
3
1
4
5
75
2
3
1
4
5
6
76
2
3
1
4
5
6
77
2
3
1
4
5
6
7
78
2
3
1
4
5
6
78
79
2
3
1
4
5
6
78
9
80
2
3
1
4
5
6
78
9
10
81
2
3
1
4
5
6
78
9
10
82
2
3
1
4
5
6
78
9
10
11
83
2
3
1
4
5
6
78
9
10
11
12
84
2
3
1
4
5
6
78
9
10
11
12
13
85
2
3
1
4
5
6
78
9
10
11
12
13
14
86
• Product Management Committee (X-Weekly)
1. Identification of a new User Story
2. Initial foreseen priority (i.e. rele...
87
5. Return on Practice
88
So what practices does it take to achieve reliable planning and forecasting ?
89
Requires
90
Requires
91
Requires
92
Requires
93
Requires
94
Requires
95
Requires
96
Requires
97
Requires
98
Requires
99
6. Conclusion
100
Sprint duration : make it 2 weeks
have potentially at least 2 opportunities to release a month
2 weeks is the best dur...
101
Agile Design
Must have knowledge for the Architecture Team
A Story Map is alive
It is continuously re-prioritized, ext...
102
The method propose here is a recipe
It’s in no way a method to apply blindly, nor rocket science
A specific organizati...
103
Thanks for listening
Upcoming SlideShare
Loading in …5
×

Agility and planning : tools and processes

473 views

Published on

In this presentation, I intend to present the fundamentals, the roles, the processes, the rituals and the values that I believe a team would need to embrace to achieve success down the line in Agile Software Development Management - Product Management, Team Management and Project Management - with the ultimate goal of making planning and forecasting as simple and efficient as it can be.

Published in: Engineering
  • Be the first to comment

Agility and planning : tools and processes

  1. 1. 1 © Jerome Kehrli @ niceideas.ch https://www.niceideas.ch/roller2/badtrash/entry/agile-planning-tools-and-processes Agile Planning An overview of Tools and Processes
  2. 2. 2 1. Introduction 2. Fundamentals 2.1 Extreme Programming 2.2 Scrum 2.3 DevOps 2.4 Lean Startup 2.5 Visual Management and Kanban 3. Principles 3.1 Tools 3.2 Organization 3.3 Processes 3.4 Rituals 3.5 Values 4. Overview of whole Process 5. Return on Practices 6. Conclusion Agenda
  3. 3. 3 1. Introduction
  4. 4. 4 Why Agile in anyway ? The problems with Waterfall Incomplete or moving specifications Tunnel effect Drop of Quality to meet deadlines Agile Manifesto Individuals and interactions over processes and tools Working Software over comprehensive documentation Customer collaboration over Contract negotiation Responding to changes over following a plan Some people believes Waterfall is better for planning But that comes mostly over a lack of mastery of Agility as a whole At the end of the day, a sound respect to key agile practices work even a lot better that Traditional Software Development in regards to planning and forecasting Agile Planning
  5. 5. 5 Agilty is a lot of things (1/2)
  6. 6. 6 It’s up to every organization to decide and pick up the principles and practices that make sense to it! What I will be presenting today is a extended-subset, a derived intersections of the practices I have sometimes witnessed, sometimes used, sometimes invented, sometimes heard of in the corporations that have today a good level of mastering of Agile Planning. Agilty is a lot of things (2/2)
  7. 7. 7 2. Fundamentals
  8. 8. 8 Agility down the line …
  9. 9. 9 2.1 Extreme Programming
  10. 10. 10 eXtreme Programming in a nutshell Values • Communication • Simplicity • Feedback • Courage • Respect Activities • Coding • Testing • Listening • Designing Principles • Feedback • Assuming Simplicity • Embracing changes Practices • Pair programming • Planning Game • Test-Driven Development • Continuous Integration • Refactoring • Coding Standards • Collective Code Ownership • On site customer • Simple Design • System metaphor • Sustainable Pace • The Planning game • Boy Scout Rule • No premature Optimization • Confirm bugs by failing tests
  11. 11. 11 The fundamentals of Agility : XP Practices
  12. 12. 12 2.2 Scrum
  13. 13. 13 Scrum in a nutshell
  14. 14. 14 Waterfall Workload managed in terms of time Tests are done by different roles in different phases Every role estimates the time for his task  Downfall : work is always late, rush to release, waiting for other people, etc. Scrum Whole Scrum team, rather than individuals take the work Comparing items to each others instead of absolute estimation Estimation in relative units instead of absolute time : Story Points Breakdown of stories in as small as possible tasks Team capacity (OK… Velocity) is based on empirical observation of past sprints Planning Poker : consensus-based, gamified technique for estimating effort (relative size) of development goals force people to think independently and propose their numbers simultaneously Surprisingly … Scrum leads to way better estimations than Waterfall Story Points
  15. 15. 15 2.3 DevOps
  16. 16. 16 DevOps principles Wall of Confusion Developer Operator
  17. 17. 17 DevOps in a nutshell
  18. 18. 18 2.4 Lean Startup
  19. 19. 19 Lean Startup (2011) (2013) (2011) (2012) Alex Osterwalder Steve Blank Eric Ries Ash Maurya Just in Time ! Only implement minimum requirements, only at the time it is actually required ! Measure driven Each and every implementation is measurable and measured Don’t believe, know ! Make measurable predictions ! An action whose effect cannot be measured is useless. Speed up development cycles Deploy and implement all quality practices (XP, Agile, DevOps) to enable development cycles to be as short as possible
  20. 20. 20 Lean Startup Practices
  21. 21. 21 2.5 Visual Management and Kanban
  22. 22. 22 (Source : http://alexsibaja.blogspot.ch/2014/08/obeya-war-room-powerful-visual.html) Toyota
  23. 23. 23 Kanban Board Story Map Product Backlog Sprint backlog Burndown Chart See product owner video Visual Management – Relevant Practices
  24. 24. 24 A story map is alive ! Constantly challenged, updated, adapted, changed, ! Story Map
  25. 25. 25 Story Map Example
  26. 26. 26 A real life example
  27. 27. 27 Story Map Garbage
  28. 28. 28 Product Backlog = Story Map with more details Story Map contains stories Backlog contains Tasks Both are kept in sync … we’ll see what are the rituals later Story Map = Management Tool : we drive priorities on the Story Map and adapt priorities of tasks in Product Backlog on correspondence Product Backlog = Development tools to organize work in development team. Backlog is usually a technical tool, not a visual management tool Very important : Each and every developer activity or task should be in the backlog … And linked to a User Story  That is the only possibility to have reliable planning Product Backlog
  29. 29. 29 Kanban is Flow oriented Team capacity instead of Sprint capacity Kanban
  30. 30. 30 Example of Kanban and Story Maps
  31. 31. 31 User Story
  32. 32. 32 3. Principles
  33. 33. 33 3.1 Tools 3.2 Organization Required Roles Requires Committees and Teams 3.3 Processes From Story Map to product Backlog Refinement (more details) of tasks Story maps and Product Backlog are kept in sync Priorities recovered from Story Map (different_backlogs_priority.png) Estimation process Back and force : 2 feedback feeds (story_map_estimations.png & XX) Development process  SCRUM Using the Story Map to estimate delivery date (story_map_planing.png) Note : backlog – since kept in sync to Story Map – should lead to same result ! 3.4 Rituals 3.5 Values 3. Principles - Agenda
  34. 34. 34 3.1 Tools
  35. 35. 35 Product Story Map Product Management Tool Visual Tool Tools to use Product Kanban Board Project Management Tool Visual Tool Product Backlog Development Team Management Tool Digital Tool (not visual) Jira, Redmine, etc. Sprint Kanban Sprint Management Tool Visual Tool
  36. 36. 36 3.2 Organization
  37. 37. 37 Team Leader : animates the Team rituals (such as Sprint Planning, Sprint Retrospective, Daily scrum) and acts as a coach and a mentor to the development team. He is not a manager, he is a leader (Lead by Example, Management 3.0, etc.). He also represents the development team in other rituals (PMC) Architect : should be the most experienced developer, the one with the biggest technical and functional knowledge. Entitled to take architecture decision (refers to the whole team as much as possible) and provides guidance and support. Responsible to check the Code Quality, sticking to conventions, etc. Tech Leads and Developers form the core of the development team. Tech Leads are coaches and supports to developers and represent them in the Architecture Committee Product Owner : represents the business and drives priorities in good understanding with the market and customer needs. He is not a leader, he is an arbitrator and acts as the bridge between the business and the development team. A must see : https://www.youtube.com/watch?v=vkYEqz_MA5Y Business representatives : whenever required, business representatives (sales, customers, etc.) have to be involved in the Product Management Committee by the product Owner whenever required. Required Roles
  38. 38. 38 Efficiency ! Roles are required to avoid having the whole organization meeting all the time at every meeting for every possible concern. Focus ! Every role owner should acts as required by his role and put himself in the right mindset for every ritual. Rituals are eventually a role playing game. Roles are not functions ! We are not speaking hierarchy here, it’s more a question of role play : when someone is assigned a role, his objective is to act and challenge the matters being discussed in correspondence with his role ! Notes: Roles can be shared. A same co-worker can have multiple roles Why bother ?
  39. 39. 39 Required Committees and Teams Identifies product features and requirements Rituals : Product Management Committee (X-Weekly) Designs the Software Rituals : Architecture Committee (X-Weekly) Organizes the Development Sprints Rituals: Sprint Planning Sprint Retrospective Implements the software Rituals : Daily Scrum
  40. 40. 40 3.3 Processes
  41. 41. 41 From Story Map to Product Backlog
  42. 42. 42 Estimations The Story Map should contain as up to date as possible estimations Again : The story Map is a management tool Everyone should be able to look at it and understand: What are the priorities and coming releases More importantly, when a specific story will be available for customers! Tasks have estimations when they have been analyzed by ARCHCOM and are sync’ed in Product Backlog
  43. 43. 43 Initial Estimations X 13 Y 60 60
  44. 44. 44 Refined Estimations X Y 68 68 21 1321
  45. 45. 45 Final Estimations X Y 81 81 34 2134
  46. 46. 46 The management tool is the story map, not the product backlog (too technical, not visual) The Product Management should be able to decide about priorities using solely the Story Map In addition, it should be possible to forecast a delivery date using solely the Story Map  The Story Map should contains as up to date as possible estimations. Everyone in the company should be able to take is little calculator, go in front of the story map and know precisely when a task will be delivered We’ll see how soon ! Why bother ?
  47. 47. 47 Product Kanban Board Maintenance (1/5) - Kanban TakenInnext Sprint Specified, Design and Estimated by ARCHCOM Finishedand waitingnext Deployment Continuous Delivery Acceptance Tests
  48. 48. 48 Product Kanban Board Maintenance (2/5) – 1st Sprint During the first sprint after this initial stage, the Kanban board in the middle identifies the Stories that are being worked on and their status Notes: A User story is moved to done when all Development Tasks have been implemented
  49. 49. 49 Product Kanban Board Maintenance (3/5) – 2nd Sprint After first sprint, developed stories are put on the Story Map on the right and a next set of Stories are being developed
  50. 50. 50 Product Kanban Board Maintenance (4/5) – After 1st release Notes: Actual releases WILL differ : we can release potentially at every end of Sprint The development Team releases at every end of sprint Consider feature flipping ! Making it a customer release is a Product Management Decision
  51. 51. 51 Product Kanban Board Maintenance (5/5) – No releases in done The Story Map on the right shouldn't have any notion of releases. It represents the Product as is the current development version and it makes no sense anymore remembering there which task has been developed in which release. Variation: merge after release !
  52. 52. 52 Backlog is synchronized with Story Map Ascendingpriority Every task in backlog should be kept in sync with a Story on Story Map Priorities are kept in sync as well Synchronized
  53. 53. 53 Synchronization Process 1. Specification and Design 2. Estimations Sync between both worlds is manual Visual World Digital World 3. Priorities
  54. 54. 54 A task will be implemented when All tasks of prior releases are implemented AND all tasks of same release and HIGHER priority are implemented Note : Using the Product backlog to estimate should lead to same results since everything is in sync How do I know when a story will be delivered ?
  55. 55. 55 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 Notes If one respects all the principles presented previously, such big differences as a on the chart above should disappear Sprint Velocity   Uncertainty 138 128 Story Points Sprint
  56. 56. 56 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 Recovering our example, we get: Using the lower limit of 128 SP per sprint, it would take us 15 sprints to complete the scope, hence 30 weeks or 6.7 months Using the upper limit of 138 SP per sprint, it would take us 14 sprints to complete the scope, hence 28 weeks or 6.2 months Forecasting Story Points Months
  57. 57. 57 Development process : SCRUM
  58. 58. 58 Sprint Kanban
  59. 59. 59 3.4 Rituals
  60. 60. 60 Story Mapping Identification of new needs and requirements (also technical and technological !) Breakdown of these requirements in User Stories “Guessing” of an Initial Priority of a User Story based on Value (and foreseen size) Maintenance (update) of Priorities Setting of Actual Priorities based on Estimations from Architecture Committee Review of priorities of Whole Story Map after update of estimations From Sprint Management Committee From Development Team Product Management Committee
  61. 61. 61 Specification and Design of User Stories Specification of functional and non-functional requirements Identification of business rules Identification of Acceptance criteria Design of GUI Architecture and Design of Software Estimation of User Stories Breakdown in individual Development Tasks This needs to be done sufficiently in advance Estimation of Development Tasks Computing of total Estimation and reporting on User Story Continuous Improvement: understanding of gaps in estimation after notification of Sprint Committee and how to improve Software Architecture Identification and maintenance of Coding Standards and Architecture Standards Review of ad’hoc architecture topics Architecture Committee Note : not the same day, that PMC, a few days after …
  62. 62. 62 Sprint Planning  Beginning of sprint Discuss Development Tasks to ensure whole team has a clear view of what needs to be done  Detailed Tasks Review and challenge estimations of Detailed Tasks. Update estimation of User Story accordingly. Feed the Sprint Backlog with such Detailed Tasks until Sprint Capacity is reached Sprint Retro  End of Sprint Review Tasks not completed and create task identifying GAP for next Sprint. Update estimations. Review SP achieved during sprint and review Sprint Capacity Discuss issues encountered during Sprint and identify action points. Update processes and rituals accordingly Continuous Improvement: understanding of gaps in tasks and estimations and how to improve Sprint Demo  End of Sprint / really optional with Continuous Delivery and Continuous Acceptance Tests Present sprint developments and integrate feedback. Create new tasks and update estimations. Sprint Management Committee
  63. 63. 63 Daily scrum Round table - every team member presents : Past or current development task Status on that task and precise progress Next steps Next task if former is completed Identification of unforeseen GAPS and adaptation of estimations Identification of challenges, issues and support needs Scheduling of ad’hoc meeting and required attendees to discuss specific issues Development Team
  64. 64. 64 3.5 Values
  65. 65. 65 Sticking rituals, respecting principles and enforcing practices is difficult It’s difficult to ensure and behaves in such a way that breaking the build (failing tests) is an exception It’s difficult to respect the boyscout rule It’s a lot more difficult to design things carefully and stick to the KISS principle It’s difficult and a lot of work to keep the Story Map and Product Backlog in sync and up-to-date with the reality. It’s difficult to stick to the TDD approach It’s difficult not to squeeze the Kaizen phase at the end of every meeting and being objective when it comes to analyzing strengths and weaknesses  It takes discipline and courage Some help comes from A strict enforcement of the processes of maintaining them A strict sticking to the rituals agenda and a sound adaptation of them Why all these committees / teams / rituals if eventually a person can have several roles ? Because they enforce discipline : they are scheduled and have precise agendas  they force the corporation to stick to the processes. Values
  66. 66. 66 4. Overview of whole Process
  67. 67. 67
  68. 68. 68
  69. 69. 69 1
  70. 70. 70 2 1
  71. 71. 71 2 1
  72. 72. 72 2 3 1
  73. 73. 73 2 3 1 4
  74. 74. 74 2 3 1 4 5
  75. 75. 75 2 3 1 4 5 6
  76. 76. 76 2 3 1 4 5 6
  77. 77. 77 2 3 1 4 5 6 7
  78. 78. 78 2 3 1 4 5 6 78
  79. 79. 79 2 3 1 4 5 6 78 9
  80. 80. 80 2 3 1 4 5 6 78 9 10
  81. 81. 81 2 3 1 4 5 6 78 9 10
  82. 82. 82 2 3 1 4 5 6 78 9 10 11
  83. 83. 83 2 3 1 4 5 6 78 9 10 11 12
  84. 84. 84 2 3 1 4 5 6 78 9 10 11 12 13
  85. 85. 85 2 3 1 4 5 6 78 9 10 11 12 13 14
  86. 86. 86 • Product Management Committee (X-Weekly) 1. Identification of a new User Story 2. Initial foreseen priority (i.e. release) depending on value and initial estimation (oral) • Architecture Committee (X-Weekly) 3. Design and specification by architecture committee : Story  Development Story  Task 4. Estimation of individual tasks 5. Computation of total SP and setting of size of Development Story and User Story 6. Re-priorization (based on new estimation) • Sprint Planning + Sprint retrospective (Sprintly) 7. Review of TaskS and discussion : Task  Detailed Task 8. Adaptation of Estimation on TaskS 9. Update of Total Size of Development Story and User Story 10. Notification to Architecture Committee (Kaizen / Sprint retrospective) • Daily Scrum 11. Identification of Gap on Task 12. Adaptation of Estimation on Task 13. Update of Total Size of Development Story and User Story 14. Notification to Architecture Committee (Kaizen / Sprint retrospective) Estimation Workflow
  87. 87. 87 5. Return on Practice
  88. 88. 88 So what practices does it take to achieve reliable planning and forecasting ?
  89. 89. 89 Requires
  90. 90. 90 Requires
  91. 91. 91 Requires
  92. 92. 92 Requires
  93. 93. 93 Requires
  94. 94. 94 Requires
  95. 95. 95 Requires
  96. 96. 96 Requires
  97. 97. 97 Requires
  98. 98. 98 Requires
  99. 99. 99 6. Conclusion
  100. 100. 100 Sprint duration : make it 2 weeks have potentially at least 2 opportunities to release a month 2 weeks is the best duration to have an accurate Spring Capacity calculation. 1 week is too little. 3 weeks is too big.  Hence, continuous delivery is not optional : when releasing every 10 days, one cannot waste any time releasing (worst case : 3 /10 days for release) Hence 100% Coverage of branch, lines and features by automated tests is not optional Each and every developer activity, every day and all day, should be linked to the Story Map Identified by task which is linked to a User Story With exceptions … (Meetings, babyfoot, Coffee, etc. Sprint capacity takes them into account) How to handle support and maintenance ? Idea : A column on the left of the story map related to maintenance / support Blocking bug fixes (not urgent !): in next minor release Non-blocking bug fixes: to be put in next major releases There is no notion of urgency: bug fixes are blocking or non-blocking, not urgent ! Releases on both Product Backlog and Story Maps are virtual. They follow an a-priori grouping logic. In practice we can release at every end of sprint => We can release whenever we are happy with the stories developed in current release. A good reason for sometimes not versioning releases on Product Backlog and Story Map : simply using Next minor, next major, long term Other concerns (1/2)
  101. 101. 101 Agile Design Must have knowledge for the Architecture Team A Story Map is alive It is continuously re-prioritized, extended, adapted Where to put the Story Map + Kanban / Sprint Kanban ? Should be in a common location where everybody can easily and always see it Avoid meeting rooms and favor open and public spaces such as the cafeteria Other concerns (2/2)
  102. 102. 102 The method propose here is a recipe It’s in no way a method to apply blindly, nor rocket science A specific organization needs to adapt it to what makes sense to it Remind the Agile Landscape V3 (Chris Webb) … It forms an alternative to upfront planning and waterfall Agility : Adapting to change instead of sticking to a plan Surprisingly (or not !) it leads to more accurate results than traditional planning Story Points Learning from the field Continuous improvement Conclusion
  103. 103. 103 Thanks for listening

×