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
Partho Ghosh - "Infrastructure organizations tend to be siloed in terms of skills and expertise - so they are ripe for cross-functional team formation for projects"
Yes, you nailed it! Our infrastructure teams are extremely siloed! Even within a silo, like our Network team, we have further silos as there are only certain people who can do firewalls, other people who can do routing and still others who do load balancing. I am trying to break the silos.
I have assembled cross-functional agile teams of database, network, middleware and server people. And I am trying to get them to cross-train within their domain (e.g. the database people should learn how to work on Oracle and SQL Server). This is working to some degree.
But my Agile Center lead is concerned that since they just have their siloed skill, and since many requests only need one or two of these things (e.g. network and database, or just a middleware change, or just a server change) that the team can't "swarm" to solve problems together. And without swarming she doesn't think that they are going to be able to become a high performing agile team.
So, on the one hand, I think that we are doing the right thing by forming cross-functional agile teams focus on their customers (which in this case are application teams), but on the other hand I think maybe Agile isn't a good fit for this situation.
What do you think ? Am I trying to put the Agile round peg into a square hole?
I worked in a cloud project that had %30 of the workload on operations teams. We had siloed teams such as, storage operations, application server operations, OS operations, security... What we did was to place one member from each of these operations teams to scrum teams with 2 hours per day dedication because we had to share the resources with other projects. During planning, we made sure that scrum team members joined from operations are capable to deliver their stories within this time limit. They also attended all scrum ceremonies as a member of the scrum team. This approach was successfull for that specific project but this was the only project I had that much operations work required. In the rest of the projects that I've been involved, operations work was minor compared to software development and the siloed teams of operations teams did not cause delays or risks.