Requests(Supporting the rest of the organization, Logistics, HR Inquiries, Assistance when needed)
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
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
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
Insert drawn icon
Insert drawn icon
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
Insert graphic
Insert graphic
Insert graphic
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’ –
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’ –
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)
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
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
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
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
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
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
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’
EXHIBIT A – LATE NIGHT SNACK
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…
‘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…
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.
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.
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
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
Insert ‘workload’ blurry
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.
Set the stage for competing work, via Sprints (time constraint), Stories/Tasks (definition constraints)
Allowing the POs (requesters) to communicate more clearly and effectively, enabling a productive r and r relationship
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.)
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.
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.
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.
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.
Insert GIF of growing storycard pile
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.
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).
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).
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).
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.
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.
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.
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
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.
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.