The Trouble with Jira - The Architecture Gathering 2019

Agile conferences, blogs, twitter – wherever lean and agile people come together it is easy to stir up a tumult with emotions running high just by mentioning Jira. But why is there always such a strong reaction? Is it the quality of the tool? Not in my experience. The problem lies in the actual adoption in many organizations and – to be fair –similar points could be made about other tools as well. This talk will look into the systemic, sociological and organizational issues that make (some) of us wince each time we hear that our clients use Jira. And it will show how to deal with these issues!

This is not meant to be a Jira bashing session, but a talk that aims to provide actual guidance for all agile initiatives challenged with centrally administered systems. After this talk participants will know (more) about
- A better –and more objective– understanding on why so many people in the lean and agile communities object the usage of Jira
- Some Approaches to succeeding with lean and agile initiatives despite centrally administered ticketing systems like the one mentioned in the title

Transcript

1. Slide # 2019 Michael Mahlberg The trouble with Jira 1 Michael Mahlberg – Oktober 2019
2. Slide # 2019 Michael Mahlberg 2 Source: Wikipedia https://en.wikipedia.org/wiki/The_Trouble_with_Harry#/media/File:The_Trouble_with_Harry.jpg JIRA
3. Slide # 2019 Michael Mahlberg 3 This talk might not agree with Jira-haters and challenge some precious misconceptions ADVISORY G E N E R A L N o J i r a B a s h i n g
4. Slide # 2019 Michael Mahlberg 4 Quelle: Thomas Epping, persönliche Kommunikation, 2019 Team Process Company Community
5. Slide # 2019 Michael Mahlberg The Specialist Specialist know-how and rights Centralised administration 5
6. Slide # 2019 Michael Mahlberg 6 True Story… Physical board March 2017 (5 Teams ~ 40 People) Centrally administered tool 3 Month until this version was available electronically Flow-Efficiency: 1,3% …
7. Slide # 2019 Michael Mahlberg 7 The means of production belong in the hands of the people who actually do the work. (paraphrased of course)
8. Slide # 2019 Michael Mahlberg 8
9. Slide # 2013 Michael Mahlberg PRINCIPLES BEHIND THE AGILE MANIFESTO - Our highest priority is to satisfy the customer
 through early and continuous delivery
 of valuable software. - Welcome changing requirements, even late in 
 development. Agile processes harness change for 
 the customer's competitive advantage. - Deliver working software frequently, from a 
 couple of weeks to a couple of months, with a 
 preference to the shorter timescale. - Business people and developers must work 
 together daily throughout the project. - Build projects around motivated individuals. 
 Give them the environment and support they need, 
 and trust them to get the job done. - The most efficient and effective method of 
 conveying information to and within a development 
 team is face-to-face conversation. - Working software is the primary measure of progress. - Agile processes promote sustainable development. 
 The sponsors, developers, and users should be able 
 to maintain a constant pace indefinitely. - Continuous attention to technical excellence 
 and good design enhances agility. - Simplicity--the art of maximizing the amount 
 of work not done--is essential. - The best architectures, requirements, and designs 
 emerge from self-organizing teams. - At regular intervals, the team reflects on how 
 to become more effective, then tunes and adjusts 
 its behavior accordingly. 9
10. Slide # 2013 Michael Mahlberg PRINCIPLES BEHIND THE AGILE MANIFESTO - Our highest priority is to satisfy the customer
 through early and continuous delivery
 of valuable software. - Welcome changing requirements, even late in 
 development. Agile processes harness change for 
 the customer's competitive advantage. - Deliver working software frequently, from a 
 couple of weeks to a couple of months, with a 
 preference to the shorter timescale. - Business people and developers must work 
 together daily throughout the project. - Build projects around motivated individuals. 
 Give them the environment and support they need, 
 and trust them to get the job done. - The most efficient and effective method of 
 conveying information to and within a development 
 team is face-to-face conversation. - Working software is the primary measure of progress. - Agile processes promote sustainable development. 
 The sponsors, developers, and users should be able 
 to maintain a constant pace indefinitely. - Continuous attention to technical excellence 
 and good design enhances agility. - Simplicity--the art of maximizing the amount 
 of work not done--is essential. - The best architectures, requirements, and designs 
 emerge from self-organizing teams. - At regular intervals, the team reflects on how 
 to become more effective, then tunes and adjusts 
 its behavior accordingly. 10
11. Slide # 2013 Michael Mahlberg PRINCIPLES BEHIND THE AGILE MANIFESTO 11 -At regular intervals, the team reflects on how 
 to become more effective, then tunes and adjusts 
 its behavior accordingly.
12. Slide # 2019 Michael Mahlberg 12
13. Slide # 2019 Michael Mahlberg 13
14. Slide # 2019 Michael Mahlberg 14
15. Slide # 2019 Michael Mahlberg 15
16. Slide # 2019 Michael Mahlberg 16
17. Slide # 2019 Michael Mahlberg 17
18. Slide # 2019 Michael Mahlberg 18
19. Slide # 2019 Michael Mahlberg 19
20. Slide # 2019 Michael Mahlberg Two weeks later 20
21. Slide # 2019 Michael Mahlberg 21
22. Slide # 2019 Michael Mahlberg 22 True Story… Physical board March 2017 (5 Teams ~ 40 People) Centrally administered tool 3 Month until this version was available electronically Flow-Efficiency: 1,3% …
23. Slide # 2019 Michael Mahlberg 23 T r o u b l e R e m e d y Use a physical board for the details Use a higher level of abstraction in the tool Have an administrator on every team Loss of adaptability
24. Slide # 2019 Michael Mahlberg 24 Quelle: Thomas Epping, persönliche Kommunikation, 2019 Process Company Community
25. Slide # 2019 Michael Mahlberg Sharing is caring? Processes & Work Item Types 25
26. Slide # 2013 Michael Mahlberg PRINCIPLES BEHIND THE AGILE MANIFESTO - Our highest priority is to satisfy the customer
 through early and continuous delivery
 of valuable software. - Welcome changing requirements, even late in 
 development. Agile processes harness change for 
 the customer's competitive advantage. - Deliver working software frequently, from a 
 couple of weeks to a couple of months, with a 
 preference to the shorter timescale. - Business people and developers must work 
 together daily throughout the project. - Build projects around motivated individuals. 
 Give them the environment and support they need, 
 and trust them to get the job done. - The most efficient and effective method of 
 conveying information to and within a development 
 team is face-to-face conversation. - Working software is the primary measure of progress. - Agile processes promote sustainable development. 
 The sponsors, developers, and users should be able 
 to maintain a constant pace indefinitely. - Continuous attention to technical excellence 
 and good design enhances agility. - Simplicity--the art of maximizing the amount 
 of work not done--is essential. - The best architectures, requirements, and designs 
 emerge from self-organizing teams. - At regular intervals, the team reflects on how 
 to become more effective, then tunes and adjusts 
 its behavior accordingly. 26
27. Slide # 2013 Michael Mahlberg PRINCIPLES BEHIND THE AGILE MANIFESTO -Build projects around motivated individuals. 
 Give them the environment and support they need, 
 and trust them to get the job done. -[…] -The best architectures, requirements, and designs 
 emerge from self-organizing teams. - 27
28. Slide # 2019 Michael Mahlberg 28 40 teams 2 week iterations 2 changes related to process or work item definition per iteration (fostered by the process improvement meeting at the end of each iteration) 15 Minutes to describe the change 15 Minutes to understand it 15 Minutes to implement it. 40(teams) / 2(weeks) * 2 (changes) => 40 Changes per week 30 hours implementing changes not feasible 3 People in admin team Just some assumptions – real life data might be worse
29. Slide # 2019 Michael Mahlberg 29 Why is it not feasible? - Overhead for information sharing between admins - Overhead for “re-learning” the specifics of the model
30. Slide # 2019 Michael Mahlberg 30 Source: Google Image Search 2019-10-15
31. Slide # 2019 Michael Mahlberg 31
32. Slide # 2019 Michael Mahlberg 32
33. Slide # 2019 Michael Mahlberg 33
34. Slide # 2019 Michael Mahlberg 34
35. Slide # 2019 Michael Mahlberg 35
36. Slide # 2019 Michael Mahlberg 36 Why is it not feasible? - Overhead for information sharing between admins - Overhead for “re-learning” the specifics of the model - Changes would queue up and admins would become the bottleneck for the teams Team 1 2 3 4 (not to scale) (retrospective) (change)
37. Slide # 2019 Michael Mahlberg Enter: Economy of scale 37 This is an Anti-Pattern
38. Slide # 2019 Michael Mahlberg Let’s have fewer models And specialized teams to find the best process-models 38 This is an Anti-Pattern
39. Slide # 2019 Michael Mahlberg 39 This is an Anti-Pattern The actual team (doing the work) The way they work Process-team (observing and optimizing) Admin-team (executing what the process team deems right) The implemented process The gap produced by “chinese whispers” and time passing
40. Slide # 2019 Michael Mahlberg 40 T r o u b l e R e m e d y Loss of autonomy Loss of adaptability Have an administrator on every team Use only very few shared objects In case of Jira: allow “Simplified Workflow” Use a physical board for the details Use a higher level of abstraction in the tool Have an administrator on every team
41. Slide # 2019 Michael Mahlberg In the beginning… Once upon a time, Jira was a bug-tracker… 41
42. Slide # 2019 Michael Mahlberg What is Jira, actually? 42
43. Slide # 2019 Michael Mahlberg 43 Bugzilla
44. Slide # 2019 Michael Mahlberg Jira was an Issue-Tracker, too 44
45. Slide # 2019 Michael Mahlberg Jey-ra vs. Jee-ra [/ˈdʒaɪˈrə/] [/ˈdʒiːrə/] 45
46. Slide # 2019 Michael Mahlberg 46 Source: Wikipedia https://en.wikipedia.org/wiki/Godzilla#/media/File:Godzilla_1954-2014_incarnations.jpg
47. Slide # 2019 Michael Mahlberg Then came GreenHopper About 2007 47
48. Slide # 2019 Michael Mahlberg 48 Source: https://wiki.base22.com/btg/agile-or-no-agile-greenhopper-s-good-for-jira-34963523.html
49. Slide # 2019 Michael Mahlberg Later GreenHopper became JiraAgile 49
50. Slide # 2019 Michael Mahlberg Workflow-Engine with biomechanical actuators 50
51. Slide # 2019 Michael Mahlberg This applies to almost all electronic ticket systems 51
52. Slide # 2019 Michael Mahlberg People are actuators? or at least that’s how the systems treat them as opposed to People define their own process … constantly 52
53. Slide # 2019 Michael Mahlberg 53 Quelle: Thomas Epping, persönliche Kommunikation, 2019 Company Community
54. Slide # 2019 Michael Mahlberg Individuals & interactions Assigning someone a Jira Ticket over… 54
55. Slide # 2019 Michael Mahlberg 55
56. Slide # 2019 Michael Mahlberg 56
57. Slide # 2019 Michael Mahlberg 57
58. Slide # 2019 Michael Mahlberg 58 T r o u b l e R e m e d y Loss of autonomy Loss of adaptability Have an administrator on every team Use only very few shared objects In case of Jira: allow “Simplified Workflow” Use a physical board for the details Use a higher level of abstraction in the tool Have an administrator on every team
59. Slide # 2019 Michael Mahlberg 59 T r o u b l e R e m e d y Loss of autonomy Loss of adaptability Have an administrator on every team Use only very few shared objects In case of Jira: allow “Simplified Workflow” Use a physical board for the details Use a higher level of abstraction in the tool Have an administrator on every team Loss of motivation Avoid using the tool a primary means of communication. Use it to capture
 agreements between people.
60. Slide # 2019 Michael Mahlberg Visual Management Boards are used to drive self-organization by displaying relevant information (Layout et. al. & functionality) 60
61. Slide # 2019 Michael Mahlberg 61 Electronic boards: - … are endless (it makes no difference whether there are two or twohundred items below the edge of the screen) - … usually don’t support free-hand placement of items and/or lanes - … allow for multiple viewpoints (People see the world differently) (Worst offender: Quickfilter “my tickets only”) - … tend to contain too much information
62. Slide # 2019 Michael Mahlberg 62
63. Slide # 2019 Michael Mahlberg 63 T r o u b l e R e m e d y Loss of autonomy Loss of adaptability Have an administrator on every team Use only very few shared objects In case of Jira: allow “Simplified Workflow” Use a physical board for the details Use a higher level of abstraction in the tool Have an administrator on every team Loss of motivation Avoid using the tool a primary means of communication. Use it to capture
 agreements between people.
64. Slide # 2019 Michael Mahlberg 64 T r o u b l e R e m e d y Loss of autonomy Loss of adaptability Have an administrator on every team Use only very few shared objects In case of Jira: allow “Simplified Workflow” Use a physical board for the details Use a higher level of abstraction in the tool Have an administrator on every team Loss of motivation Avoid using the tool a primary means of communication. Use it to capture
 agreements between people. Loss of flexibility and visibility Use physical boards and/or be creative (e.g. use multiple displays for swimlanes visualize critical data only, etc.)
65. Slide # 2019 Michael Mahlberg 65 Quelle: Thomas Epping, persönliche Kommunikation, 2019 Company Community
66. Slide # 2019 Michael Mahlberg Subverting the Community The tool subverts the efforts of the community => Kanban Board => Epic 66
67. Slide # 2019 Michael Mahlberg Let’s look at Kanban as an Example 67
68. Slide # 2019 Michael Mahlberg Let’s look at Kanban as an Example 68
69. Slide # 2018 Michael Mahlberg Fundamental assumption about Vizualizition 69 The intelligence is in front of the Board —— Simon Kühn Limited WIP Society Köln 2012
70. Slide # 2019 Michael Mahlberg 70 T r o u b l e R e m e d y Loss of autonomy Loss of adaptability Have an administrator on every team Use only very few shared objects In case of Jira: allow “Simplified Workflow” Use a physical board for the details Use a higher level of abstraction in the tool Have an administrator on every team Loss of motivation Avoid using the tool a primary means of communication. Use it to capture
 agreements between people. Loss of flexibility and visibility Use physical boards and/or be creative (e.g. use multiple displays for swimlanes visualize critical data only, etc.) Loss of initiative Don’t follow the tool, have communities of practice and external exchanges – a lot!
71. Slide # 2019 Michael Mahlberg It’s all in the cards Jira used as a requirement & documentation tool 71
72. Slide # 2019 Michael Mahlberg 72
73. Slide # 2019 Michael Mahlberg 73 As returning visitor of the site, I want the system to recognize me unmaskingly, so that I actually can order the articles in my basket even weeks after my last visit. As returning visitor of the site, I want the system to recognize me unmaskingly, so that I actually can order the articles in my basket even weeks after my last visit. As returning visitor of the site, I want the system to recognize me unmaskingly, so that I actually can order the articles in my basket even weeks after my last visit. As returning visitor of the site, I want the system to recognize me unmaskingly, so that I actually can order the articles in my basket even weeks after my last visit. As returning visitor of the site, I want the system to recognize me unmaskingly, so that I actually can order the articles in my basket even weeks after my last visit. As returning visitor of the site, I want the system to recognize me unmaskingly, so that I actually can order the articles in my basket even weeks after my last visit. As returning visitor of the site, I want the system to recognize me unmaskingly, so that I actually can order the articles in my basket even weeks after my last visit. As returning visitor of the site, I want the system to recognize me unmaskingly, so that I actually can order the articles in my basket even weeks after my last visit. As returning visitor of the site, I want the system to recognize me unmaskingly, so that I actually can order the articles in my basket even weeks after my last visit. As returning visitor of the site, I want the system to recognize me unmaskingly, so that I actually can order the articles in my basket even weeks after my last visit.
74. Slide # 2019 Michael Mahlberg 74 T r o u b l e R e m e d y Loss of autonomy Loss of adaptability Have an administrator on every team Use only very few shared objects In case of Jira: allow “Simplified Workflow” Use a physical board for the details Use a higher level of abstraction in the tool Have an administrator on every team Loss of motivation Avoid using the tool a primary means of communication. Use it to capture
 agreements between people. Loss of flexibility and visibility Use physical boards and/or be creative (e.g. use multiple displays for swimlanes visualize critical data only, etc.) Loss of initiative Don’t follow the tool, have communities of practice and external exchanges – a lot!
75. Slide # 2019 Michael Mahlberg 75 T r o u b l e R e m e d y Loss of autonomy Loss of adaptability Have an administrator on every team Use only very few shared objects In case of Jira: allow “Simplified Workflow” Use a physical board for the details Use a higher level of abstraction in the tool Have an administrator on every team Loss of motivation Avoid using the tool a primary means of communication. Use it to capture agreements between people. Loss of flexibility and visibility Use physical boards and/or be creative (e.g. use multiple displays for swimlanes visualize critical data only, etc.) Loss of initiative Don’t follow the tool, have communities of practice and external exchanges – a lot! Loss of knowedge Use other tools for documentation and link to them! includes education, training, permissions, autonomy, etc
76. Slide # 2019 Michael Mahlberg Recap Troubles and Remedies 76
77. Slide # 2019 Michael Mahlberg Working in a post agile world is… Local decisions (governed by negotiated policies) Adaptive development processes Teams change process all the time 77
78. Slide # 2019 Michael Mahlberg At regular intervals, the team reflects on how 
 to become more effective, then tunes and adjusts 
 its behavior accordingly. Quote from the Manifesto for Agile Software Development 78
79. Slide # 2019 Michael Mahlberg Centrally administered workflows don’t agree with self organized teams 79
80. Slide # 2019 Michael Mahlberg During each Sprint Retrospective, the […] Team plans ways to increase product quality by improving work processes […] Quote from the Scrum-Guide 80
81. Slide # 2019 Michael Mahlberg Depending on external “mechanics” subverts the idea of local process improvements 81
82. Slide # 2019 Michael Mahlberg Agree to pursue improvement through evolutionary change. Quoting the second principle of change management of the Kanban method 82
83. Slide # 2019 Michael Mahlberg Evolutionary change needs experiments – hard to do with centralized artifacts 83
84. Slide # 2019 Michael Mahlberg 84 The means of production belong in the hands of the people who actually do the work. (paraphrased of course)
85. Slide # 2019 Michael Mahlberg Let The Tool do what The Tool does best Use The Tool (e.g. Jira) to capture data, but Use physical boards for communication 85
86. Slide # 2019 Michael Mahlberg 86 T r o u b l e R e m e d y Loss of autonomy Loss of adaptability Have an administrator on every team Use only very few shared objects In case of Jira: allow “Simplified Workflow” Use a physical board for the details Use a higher level of abstraction in the tool Have an administrator on every team Loss of motivation Avoid using the tool a primary means of communication. Use it to capture agreements between people. Loss of flexibility and visibility Use physical boards and/or be creative (e.g. use multiple displays for swimlanes visualize critical data only, etc.) Loss of initiative Don’t follow the tool, have communities of practice and external exchanges – a lot! Loss of knowedge Use other tools for documentation and link to them! includes education, training, permissions, autonomy, etc
87. Slide # 2019 Michael Mahlberg Questions? 87
88. Slide # 2019 Michael Mahlberg Contact Information 88 If you have questions, don’t hesitate to contact me via mail at: mm@michaelmahlberg.com You can also find me on Twitter as MMahlberg I blog on http://agile-aspects.michaelmahlberg.com My homepage is http://www.michaelmahlberg.de