Agile in IT operations
I have worked as Product owner for Application dev team where typical agile/scrum methodology can be easily implemented. My new role is to work with the IT OPS team - Network management and Infrastructure management etc. Here the day to day work involves no strictly defined stories but work that can easily span thru multiple stories. Eg. a team member could be working on 6 different stories a time and each story might extend upto 2 months - there is no easy way to dissect those to run for few days. A story might be to establish a new facility circuit connection for a new site - which consists of various checklists but not big enough to warrant a story of its own. So we do lose an agile practice in a typical sense, but we are determined to practice as much as we can.
Any of you had experienced similar setting in your work? What worked and what were the challenges? Do you think agile doesn't suit on those settings at all? What kind of stories makes sense on such settings?
I would be very interested to hear on your experiences.
> Eg. a team member could be working on 6 different stories a time and each story
> might extend upto 2 months - there is no easy way to dissect those to run for few days
Is it possible to foresee the points at which the implementation of these "stories" are likely to become impeded? Impediments can include dependencies on third parties, or on resources that are not yet available.
Broadly speaking, there are 3 buckets of work in IT Ops: projects/new initiatives (e.g. infrastructure upgrades, new installations), routine operations/production-support work and operational processes. The Scrum framework is applicable to the 1st one; Kanban is well-suited for the 2nd. Similar to app-development projects, projects in infrastructure also have scoping, design, build, test and deploy. Look up infrascrum (or scrum in infrastructure, or scrum in operations) on the web for discussions of how Scrum is being used in operations. http://theagileadmin.com/2013/07/19/scrum-for-operations-how-we-got-sta…
With respect to IT operational processes (incident management, change management, and the rest of ITIL processes): significant improvements can be accomplished in large enterprises by removing muda/waste (delays, large WIPs, etc) in many of these processes -- in addition to automation of routine, repititive, manual tasks.
A side note about "a team member could be working on 6 different stories a time".... A root cause of low performance in many teams (including Scrum teams) is the effect of multi-tasking. Significant increases in velocity can be achieved by removing/reducing multi-tasking. The stories could be spanning a long time ("sprints" if Scrum was being used) if they are too large (i.e. more like epics) -- or tightly coupled with interdependencies. There's no reason that Bill Wake's INVEST model cannot be applied to infrastructure stories ("customer" in infrastructure can be the entire organization, a business unit, etc).
Infrastructure organizations tend to be siloed in terms of skills and expertise - so they are ripe for cross-functional team formation for projects
John: If these stories are independent, a plausible reason for the long-duration stories and multi-tasking could be due to lack of value-based prioritization (which is the product owner's responsibility)
I beleive You will go first with Kanban. Make sure that you have everything (literally) on the kanban board, after you do a ruthless WIP tracking, which will inmediatly require a good PO(or highly tranparent tickets). Recommended book: https://www.amazon.com/Kanban-30-days-Tomas-Bj%C3%B6rkholm/dp/1783000902