Uploaded byMatthew Salerno
Non Developer Scrum Teams: How Scrum Can Improve Your Operations
This document discusses how scrum principles can help non-development teams like operations, HR, and office management. It outlines how scrum can help teams deal with multiple stakeholders, communication issues, and extensive work in progress by establishing a product owner, backlog, and sprint planning. Using scrum practices like limiting work in progress and identifying dependencies helps provide reliable estimates and visibility into workflows. Organization-wide adoption of scrum principles can create aligned, accountable, and efficient teams across all parts of an organization.
More Related Content
Similar to Non Developer Scrum Teams: How Scrum Can Improve Your Operations
Non Developer Scrum Teams: How Scrum Can Improve Your Operations
- 1. How Scrum CanImprove Your Operations and Support Teams Presented by Matthew Salerno Operations Manager and Scrum Master at Cyrus Innovation
- 2. Non-Development Teams © Matthew Salerno 2012
- 3. Non-Development Teams • Operations © Matthew Salerno 2012
- 4. Non-Development Teams • Operations • Human Resources © Matthew Salerno 2012
- 5. Non-Development Teams • Operations • Human Resources • Office Management © Matthew Salerno 2012
- 6. Non-Development Teams • Operations • Human Resources • Office Management • Recruiting • Sales • Management © Matthew Salerno 2012
- 7.
- 8. R&R Repeating Processes © Matthew Salerno 2012
- 9. R&R Repeating Processes Requests © Matthew Salerno 2012
- 10. SCRUM is aProject Management Tool! © Matthew Salerno 2012
- 11. LINE IN THESAND © Matthew Salerno 2012
- 12. SCRUM is aTool for Identifying and Dealing with Impediments © Matthew Salerno 2012
- 13. Multiple Stakeholders © Matthew Salerno 2012
- 14. Communication Breakdown © Matthew Salerno 2012
- 15. Extensive Workin Progress (WiP) © Matthew Salerno 2012
- 16. Scrum is anexcellent tool for managing • Multiple Stakeholders • Communication Issues • Extensive Work in Progress © Matthew Salerno 2012
- 17. Dealing with… MULTIPLE STAKEHOLDERS © Matthew Salerno 2012
- 18. Stakeholders ©Matthew Salerno 2012
- 19. Stakeholders • Business Units © Matthew Salerno 2012
- 20. Stakeholders • Individual Employees © Matthew Salerno 2012
- 21. Stakeholders • Management © Matthew Salerno 2012
- 22. Unaware of OtherStakeholders © Matthew Salerno 2012
- 23. Unaware of OtherStakeholders It is the Team’s responsibility to make Stakeholders aware of their place in the ‘ecosystem’ © Matthew Salerno 2012
- 24. Scrum Master/Product Owner © Matthew Salerno 2012
- 25. Unified Product Backlog © Matthew Salerno 2012
- 26. Scrum Master/Product Ownercan groom the product backlog © Matthew Salerno 2012
- 27. Avoid Requests (Stories)Getting Lost in the Cross Fire © Matthew Salerno 2012
- 28. The Team Becomes‘Self-Aware’ © Matthew Salerno 2012
- 29. Scrum Master/Product OwnerAllows the Team To: © Matthew Salerno 2012
- 30. Scrum Master/Product OwnerAllows the Team To: Create unified product backlog © Matthew Salerno 2012
- 31. Scrum Master/Product OwnerAllows the Team To: Create unified product backlog and Provide a Central Point of Contact for Multiple Stakeholders © Matthew Salerno 2012
- 32. ‘What’ and ‘When’ © Matthew Salerno 2012
- 33. ‘What’ and ‘When’ ‘what’needs to be done © Matthew Salerno 2012
- 34. ‘What’ and ‘When’ ‘what’needs to be done and ‘when’ will it be done © Matthew Salerno 2012
- 35. CLEAR COMMUNICATION © Matthew Salerno 2012
- 36. CLEAR COMMUNICATION is the key to a successful organization © Matthew Salerno 2012
- 37. Dealing with… COMMUNICATION ISSUES © Matthew Salerno 2012
- 38. Requester/Responder © Matthew Salerno 2012
- 39. ‘Success of anorganization hinges on the ability to make clear requests’ (via Tobias Mayer, Scrum Master ‘Dogma Free Scrum’) © Matthew Salerno 2012
- 40. Requester/Responder Stakeholders/Scrum Team © Matthew Salerno 2012
- 41. Requester/Responder Requester • What (needsto be done) © Matthew Salerno 2012
- 42. Requester/Responder Requester • What (needsto be done) • Why (context) © Matthew Salerno 2012
- 43. Requester/Responder Requester Responder • What (needs to • How (what will be done) the team do to • Why (context) ensure completion) © Matthew Salerno 2012
- 44. EXHIBIT A: LATENIGHT SNACK © Matthew Salerno 2012
- 45. EXHIBIT A: LATENIGHT SNACK • Requester – beautiful, loving girlfriend © Matthew Salerno 2012
- 46. EXHIBIT A: LATENIGHT SNACK • Requester – beautiful, loving girlfriend • Responder - ME © Matthew Salerno 2012
- 47. EXHIBIT A: LATENIGHT SNACK © Matthew Salerno 2012
- 48. EXHIBIT A: LATENIGHT SNACK © Matthew Salerno 2012
- 49. EXHIBIT A: LATENIGHT SNACK © Matthew Salerno 2012
- 50. Sprint Planning Sessionsand Story Estimating © Matthew Salerno 2012
- 51. Sprint Planning Sessionsand Story Estimating Enable the Scrum Team to provide authoritative responses to requests © Matthew Salerno 2012
- 52. STORYBOARD ©Matthew Salerno 2012
- 53. Sprint Planning givesthe workload ‘Form’ and ‘Visibility’ © Matthew Salerno 2012
- 54. Sprint Planning givesthe workload ‘Form’ and ‘Visibility’ © Matthew Salerno 2012
- 55. Reliable Estimates ofDelivery Dates and Visible Workflow © Matthew Salerno 2012
- 56. Reliable Estimates ofDelivery Dates and Visible Workflow • Set the Stage © Matthew Salerno 2012
- 57. Reliable Estimates ofDelivery Dates and Visible Workflow • Set the Stage • Establish a vernacular © Matthew Salerno 2012
- 58.
- 59. RECAP • Scrum Master/PO– manage multiple Stakeholders and create unified workload © Matthew Salerno 2012
- 60. RECAP • Scrum Master/PO– manage multiple Stakeholders and create unified workload • Planning/Estimating – establish a protocol for managing workflow. Working vernacular for requester/responder interaction © Matthew Salerno 2012
- 61. WORK, WORK, WORK,WORK © Matthew Salerno 2012
- 62. WORK, WORK, WORK,WORK LIKE IT’S THEIR JOB! © Matthew Salerno 2012
- 63. The Stakeholders willrespond by asking for more… © Matthew Salerno 2012
- 64. Dealing with… WORK INPROGRESS (WIP) © Matthew Salerno 2012
- 65. DEPENDENCIES © Matthew Salerno 2012
- 66. DEPENDENCIES • HR requestsgo to areas outside organization (payroll admin, insurance companies) © Matthew Salerno 2012
- 67. DEPENDENCIES • HR requestsgo to areas outside organization (payroll admin, insurance companies) • A/R is dependent on teams entering hours for billing, clients payment schedules © Matthew Salerno 2012
- 68. DEPENDENCIES • HR requestsgo to areas outside organization (payroll admin, insurance companies) • A/R is dependent on teams entering hours for billing, clients payment schedules • Logistics, dealing with outside vendors © Matthew Salerno 2012
- 69. DEPENDENCIES MAKE WIPSKYROCKET © Matthew Salerno 2012
- 70. SCRUM-BAN ©Matthew Salerno 2012
- 71. SCRUM-BAN WIP limited to‘1’ story per team member © Matthew Salerno 2012
- 72. ON HOLD © MatthewSalerno 2012
- 73. ON HOLD The ‘ON HOLD’ column can become an easy starting point for identifying impediments at A.M. Standup © Matthew Salerno 2012
- 74. Scrum-Ban helps makethe team aware of dependencies © Matthew Salerno 2012
- 75. Scrum-Ban helps makethe team aware of dependencies ‘Scrum, grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the story board to know the difference’ © Matthew Salerno 2012
- 76. Benefits of… THE SCRUM OPERATIONSTEAM © Matthew Salerno 2012
- 77. THE SCRUM OPERATIONSTEAM ONE POINT OF CONTACT FOR MULTIPLE STAKEHOLDERS © Matthew Salerno 2012
- 78. THE SCRUM OPERATIONSTEAM ONE POINT OF CONTACT FOR MULTIPLE STAKEHOLDERS UNIFIED BACKLOG © Matthew Salerno 2012
- 79. THE SCRUM OPERATIONSTEAM ONE POINT OF CONTACT FOR MULTIPLE STAKEHOLDERS UNIFIED BACKLOG PROVIDE CLEAR ESTIMATES FOR STORY COMPLETION – VISIBLE WORKFLOW © Matthew Salerno 2012
- 80. THE SCRUM OPERATIONSTEAM ONE POINT OF CONTACT FOR MULTIPLE STAKEHOLDERS UNIFIED BACKLOG PROVIDE CLEAR ESTIMATES FOR STORY COMPLETION – VISIBLE WORKFLOW MANAGING WORK IN PROGRESS – AVOID MULTI-TASKING © Matthew Salerno 2012
- 81. TRUSTED AND ACCOUNTABLE © Matthew Salerno 2012
- 82. LIFTS THE ‘WEIGHTOF WORRYING’ OFF THE SHOULDERS OF THE ORGANIZATION © Matthew Salerno 2012
- 83. SPEAK THE SAMELANGUAGE © Matthew Salerno 2012
- 84. ORGANIZATION-WIDE AGILE/SCRUM © Matthew Salerno 2012
- 85. ORGANIZATION-WIDE AGILE/SCRUM ‘WHENONLY PART OF THE FIRM IS AGILE, THE ORGANIZATION IS AT WAR WITH ITSELF’ (via Stephen Denning, author and thought leader in leadership and management) © Matthew Salerno 2012
- 86. FINAL WORDS © Matthew Salerno 2012
- 87. FINAL WORDS • Scrumcan help teams turn non-project workloads into manageable, project-like workloads © Matthew Salerno 2012
- 88. FINAL WORDS • Scrumcan help teams turn non-project workloads into manageable, project-like workloads • Scrum/Agile not just for Dev Teams! © Matthew Salerno 2012
- 89. FINAL WORDS • Scrumcan help teams turn non-project workloads into manageable, project-like workloads • Scrum/Agile not just for Dev Teams! • Organization-wide Scrum will benefit ALL parts of your organization © Matthew Salerno 2012
- 90. QUESTIONS! Matthew Salerno Scrum Master and Operations Manager © Matthew Salerno 2012
- 91. Call to Action © Matthew Salerno 2012
- 92. Call to Action •Create a product backlog with stories © Matthew Salerno 2012
- 93. Call to Action •Create a product backlog with stories • If on a team, hold a daily standup © Matthew Salerno 2012
- 94. Call to Action •Create a product backlog with stories • If on a team, hold a daily standup • Read one of the suggested books on Scrum/Agile practices © Matthew Salerno 2012
- 95. Call to Action •Create a product backlog with stories • If on a team, hold a daily standup • Read one of the suggested books on Scrum/Agile practices • Limit your WiP ( stop multi-tasking! ) © Matthew Salerno 2012
- 96. Call to Action •Create a product backlog with stories • If on a team, hold a daily standup • Read one of the suggested books on Scrum/Agile practices • Limit your WiP ( stop multi-tasking! ) • Try to identify and remove impediments to your workflow (be your own Scrum Master) © Matthew Salerno 2012
- 97. Call to Action •Create a product backlog with stories • If on a team, hold a daily standup • Read one of the suggested books on Scrum/Agile practices • Limit your WiP ( stop multi-tasking! ) • Try to identify and remove impediments to your workflow (be your own Scrum Master) • Think about doing any of the above! © Matthew Salerno 2012
Editor's Notes
- #7 Mention: have most of these in the room, human resources/accounting/etc.
- #9 Repeating Processes (Invoicing, Hours Tracking, Payroll Processing, Restocking, New Employee Training)
- #10 Requests(Supporting the rest of the organization, Logistics, HR Inquiries, Assistance when needed)
- #11 Scrum NOT intended for Operations (Request-based)/Intended for ‘PROJECTS’ (Development, Manufacturing), Processes with clear beginning and end – This is why most organizations believe there is some sort of ‘line in the sand’ between scrum teams and non-scrum teams
- #12 Scrum NOT intended for Operations (Request-based)/Intended for ‘PROJECTS’ (Development, Manufacturing), Processes with clear beginning and end – This is why most organizations believe there is some sort of ‘line in the sand’ between scrum teams and non-scrum teams
- #13 Impediments – (Pivot here from original point, which is counter to the thesis argument, and start to make consonant with thesis). Scrum is essentially a method for dealing with impediments or uncertainty. Much of the uncertainty faced by dev teams is mirrored on operations teams
- #14 Insert drawn icon
- #15 Insert drawn icon
- #16 Talk about the meaning of WIP. Means Work In Progress – i.e. work that is not completely finished. Work in progress is like excess inventory, in that it’s inefficient and wasteful. You want to be producing as quickly as you can sell goods, leading to holding minimum inventory. Similarly, you should only be creating new work as quickly as you can finish it, which will lead to a drop in Work in Progress. Scrum, specifically a practice called Scrum-Ban, is great for minimizing costly work in progress buildup.----- Meeting Notes (6/21/12 11:50) -----DESCRIBE WORK IN PROGRESS - BUILD UP OF WORK IN PROGRESS IS LIKE BUILD UP OF INVENTORY AT A MANUFACTURING PLANT. WANT TO DO JUST IN TIME PRODUCTION, RATE OF PRODUCTION IS PEGGED TO THE RATE OF CONSUMPTION
- #20 Insert graphic
- #21 Insert graphic
- #22 Insert graphic
- #23 Different product owners often are not aware of each other (use graphic to illustrate this). ‘It is the team’s job to prioritize, estimate capacity, and keep product owners apprised of the environment so they become aware of their own place in the ecosystem’ –
- #24 Different product owners often are not aware of each other (use graphic to illustrate this). ‘It is the team’s job to prioritize, estimate capacity, and keep product owners apprised of the environment so they become aware of their own place in the ecosystem’ –
- #25 Here, the Scrum Master (person with superman shirt) can be advantageous. Creates a single point of contact between multiple owners and the team. Funneling of requests into a unified product backlog. This may work slightly differently at a larger organization like Kaplan, at Cyrus, the various team members inform each other’s work, i.e. accounting can help make logistics decision, (choice of vendor), recruiting may have insights into personnel demos, informing hr decisions about benefits admin, etc. This kind of collaboration is possible, and highly functional, however this can also be implemented on homogenous or non-mixed teams----- Meeting Notes (6/21/12 11:50) -----SCRUM MASTER HELPS TO REMOVE IMPEDIMENTSPRODUCT OWNER ACTS AS THE VOICE OF THE STAKEHOLDERS/CUSTOMER. ACTS AS A SINGLE POINT OF CONTACT FOR THE TEAM (IN OUR EXAMPLE)
- #26 Explain backlog. Essentially, it is a list of the work to be completed. Backlog does not, as in some other uses, imply that something is late or that work is piling up due (that’s WIP!). It is a scrum term referring to the ‘work’! The unified product backlog is something manageable, measurable, must be unified to be managed. Something the team can mobilize around. Side note about certification, but the key is the knowledge, not the certificate----- Meeting Notes (6/21/12 11:50) -----DEFINE BACKLOG - NOT LATE! IT IS JUST ANOTHER TERM FOR THE WORK
- #27 With a unified product backlog, suddenly requests from un-related product owners, which are often in direct conflict, can be prioritized together, making for unified workflow. Scrum Master can ‘groom’ product backlog (graphic, combing and shaving the product backlog). Ensure stories don’t get lost in the ‘cross-fire’ or mulitiple product owners (graphic, cross-fire commercial?)----- Meeting Notes (6/21/12 11:50) -----DEFINE GROOM - PRIORITIZE ALL THE DIFFERENT COMPONENTS OF WORK, ACCORDING TO CUSTOMER/STAKEHOLDER NEEDS AND TEAM CAPACITY
- #28 With a unified product backlog, suddenly requests from un-related product owners, which are often in direct conflict, can be prioritized together, making for unified workflow. Scrum Master can ‘groom’ product backlog (graphic, combing and shaving the product backlog). Ensure stories don’t get lost in the ‘cross-fire’ or mulitiple product owners (graphic, cross-fire commercial?)----- Meeting Notes (6/21/12 11:50) -----SINGLE POINT OF CONTACT
- #29 Ultimately, the result of having a Scrum Master is that the team can be self-aware. The team knows it’s entire backlog (from multiple POs) and in such a way is able to act strategically and decisively. The team is also able to approach their work with a process improvement mindset. No longer in triage, or rote implementation, the team is now problem solving (source of all innovation). Can greatly improve involvement, investment. Don’t want to say motivation, as many teams not using Scrum don’t suffer from lack of motivation, but a different approach, fostering creativity and critical thinking, that can engage team members in a different kind of way----- Meeting Notes (6/21/12 11:50) -----TEAM SEES THEMSELVES AS A 'TEAM'. MORALE UP, MOTIVATION UP, SATISFACTION UP. MOBILIZING AROUND A DEFINABLE BODY OF WORK
- #36 Operations teams can thus clearly communicate their capacity to product owners, and how each PO’s requests are prioritized (including completion estimates) in the backlog
- #39 The best ‘requester/responder’ relationship is one of collaboration. Parallels with ‘servant leadership’ agile/scrum principles. Concept that the requester and responder in fact serve one another. Central to this is the ability to communicate clearly and accurately
- #44 Make this relevant, keep tying it back to Scrum teams, mention that Scrum enables an operations team to be a capable responder by giving them a language to communicate the ‘HOW’
- #45 EXHIBIT A – LATE NIGHT SNACK
- #47 Set the scene…Thursday night, just gotten home from my Scrum talk. GF and dog are lying on the couch comfortably, watching TV. and I say ‘I’m going to the store’. Then. The request…
- #48 ‘get me something GOOD. So I mosey on down to the store. I know she ate ‘Cherry Garcia’ a few months ago, and she always seems to be eating bagel chips, so I make a bunch of assumptions that she continues to like these two fine snacks, and buy them…
- #49 I say ‘OK, be back in a few’. Inevitably, I come back with cherry garcia and everything bagel chips, but she now HATES cherry garcia and only wants Peanut Butter Cup. and the bagel chips ‘hurt her mouth’. The requester/responder relationship has failed miserably.
- #50 In a successful r and r relationship, the responder might say. ‘Ok, I know the store has x,y, and z. If they don’t have x, I’ll get y, and if they don’t have x or y, I’ll get z. I should be back in five minutes… This enables the requester to clarify their request (knowing the ‘HOW’) and leads to a successful transaction.
- #51 Sprint Planning session – An operations team, by breaking time up into sprints and turning requests into stories, can manage ongoing processes (fielding HR requests, repeating processes like A/R and A/P tracking) as if they were a project. This allows for much more exact time estimating (‘your request will be handled in this sprint’ – short, 1,2 weeks). POs will get used to hearing completion estimates from Ops in this way, and once apprised of the estimates, can focus on better things than whether or not operations will get it done (answer: they WILL get it done). ----- Meeting Notes (6/21/12 11:50) -----SPRINT - TIMEBOXED PERIOD TO COMPLETE THE BACKLOGESTIMATING - TEAM ESTIMATES HOW MUCH EFFORT/TIME IS INVOLVED IN COMPLETING EACH TASK
- #53 Another important aspect of scrum workflow management is task estimating. Specifically, estimating tasks not based on hours but on relative difficulty. (Example of task that may seem easy, but relative to a competing task, is of greater value, allowing for work organization?) Also may want to touch on aspect of breaking down stories into tasks. For requests, often a portion of the work is dependent on others (will come back to this later). Breaking down stories into tasks can help ops isolate which steps will cut into their capacity and which will be spent ‘waiting’ ----- Meeting Notes (6/21/12 11:50) -----VISUALIZE THE WORKLOAD AND WORKFLOW - THIS IS A KANBAN PRACTICE - ALLOWS FOR CLEARER COMMUNICATION
- #54 Insert ‘workload’ blurry
- #55 Insert ‘workload’ clear. Sprint planning and the attendant story/task breakdown and estimating turn the ambiguous monolith of the operations team backlog and bring it into sharp relief/focus. Armed with this knowledge, the operations team can provide accurate and honest estimates to the rest of the organization. In so doing, they can fulfill their clarity obligation in the requester/responder collaborative space.
- #57 Set the stage for competing work, via Sprints (time constraint), Stories/Tasks (definition constraints)
- #58 Allowing the POs (requesters) to communicate more clearly and effectively, enabling a productive r and r relationship
- #62 Scrum meetings/estimating facilitate the clarity necessary for a productive dynamic within the organization (ability to make and respond to requests clearly). In such a way the operations team can become much more efficient (by avoiding mistakes, re-work, dragging timelines, etc.)
- #66 the operations team backlog is loaded with ‘dependencies’; HR requests often go to areas outside the organization (payroll admin, benefits). A/R is dependent on the team entering all billing info, clients payment schedules, etc.etc. This can lead to a lot of WiP(bad). With the team using scrum to be more productive than ever, WiP will go up.
- #67 the operations team backlog is loaded with ‘dependencies’; HR requests often go to areas outside the organization (payroll admin, benefits). A/R is dependent on the team entering all billing info, clients payment schedules, etc.etc. This can lead to a lot of WiP(bad). With the team using scrum to be more productive than ever, WiP will go up.
- #68 the operations team backlog is loaded with ‘dependencies’; HR requests often go to areas outside the organization (payroll admin, benefits). A/R is dependent on the team entering all billing info, clients payment schedules, etc.etc. This can lead to a lot of WiP(bad). With the team using scrum to be more productive than ever, WiP will go up.
- #69 the operations team backlog is loaded with ‘dependencies’; HR requests often go to areas outside the organization (payroll admin, benefits). A/R is dependent on the team entering all billing info, clients payment schedules, etc.etc. This can lead to a lot of WiP(bad). With the team using scrum to be more productive than ever, WiP will go up.
- #70 Insert GIF of growing storycard pile
- #71 Here, instituting Scrum-Ban, or setting up a ‘pull’ system for workflow, can be instrumental in helping the OPS team to manage WiP. On my team (anecdotal, introduce picture of the OPS team storyboard wall), we manage WiP in one of two ways.
- #72 The first is setting up WiP quotas. The team stipulates that there be no more than ‘1’ story, per team member, In Progress at any given time. (insert graphic with ‘whip’ sound for trying to have more than one thing in progress at a time).
- #73 Quotas, however, can pose an issue when dealing with dependencies. A Team member may start a story dependent on someone outside of the team (whose work is not calculated into capacity estimates). They are to the point where they can no longer work on the story without the outsider’s contribution, but it’s not yet ‘done, done’. In this case, we’ve created an ‘On Hold’ column. A story is placed ‘On Hold’ along with a marker indicating why it’s on hold and as of what date (or until a future date, if it’s known).
- #74 Quotas, however, can pose an issue when dealing with dependencies. A Team member may start a story dependent on someone outside of the team (whose work is not calculated into capacity estimates). They are to the point where they can no longer work on the story without the outsider’s contribution, but it’s not yet ‘done, done’. In this case, we’ve created an ‘On Hold’ column. A story is placed ‘On Hold’ along with a marker indicating why it’s on hold and as of what date (or until a future date, if it’s known).
- #76 As importantly, a believe the Scrum-Ban concept of WiP management help an operations team be cognizant of ‘dependencies’. In so doing, the team is able to pinpoint (quote: give me power to change things that I can change, accept those things I can’t, etc.) and to not think about those things they cannot impact, saving valuable energy (dr Strangelove, previous fluids) for other work.
- #82 INSERT PICTURE HERE. The Scrum operations team has become a trusted and accountable part of the organization. (graphic – placing medal on chest). This can be immensely powerful in aiding the development team (or core team), management, and other depts carry out their jobs.
- #83 INSERT PICTURE HERE. The Scrum operations team has become a trusted and accountable part of the organization. (graphic – placing medal on chest). This can be immensely powerful in aiding the development team (or core team), management, and other depts carry out their jobs.
- #84 Similarly, an operations team fluent in Scrum is able to ‘speak the same language’ as the rest of the organization. The value of having your whole organization speaking the same language CANNOT BE OVERSTATED
- #85 Denning: ‘When only part of a firm is Agile, the organization is at war itself.’ An organization that is not all agile will ‘break the chain’. Agile operations can add the missing link to establish a continuous feedback loop.
- #86 Denning: ‘When only part of a firm is Agile, the organization is at war itself.’ An organization that is not all agile will ‘break the chain’. Agile operations can add the missing link to establish a continuous feedback loop.