Scrum Teams with Operational Responsibilities
How we incorporated Scrum into our operational teams
24 October 2016
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
In our organization we have been using Scrum in small pockets, mostly for software development, for about three years. I was unaware of this until about a year ago, when we had a reorganization in which I was asked (due to my expertise and institutional knowledge in networking and network management) to become a product owner for some in-house network-tool development efforts.
I was put in touch with our resident ScrumMaster, who began mentoring me to be a product owner and helped me understand Scrum and, more important, how he had instantiated Scrum practices within our organization. I was quickly installed as the product owner of what has become our script-writing team for in-house network tools. My interest in Scrum was piqued by how quickly and often feedback is reinserted into the development cycle of a product.
After much reading of authors such as Ken Rubin, Mike Cohn, Ilan Goldstein, Roman Pichler, Kent Beck, Lynn Miller, and others, I felt I was ready for some formal training. Mike Cohn proved to be a very engaging and informative teacher. I am now our newest Certified ScrumMaster and a true advocate for using the Agile Scrum framework. My interest in Scrum translated into our organization being able to use operational staff and their expertise in network tool development and old tool refactoring. This is greatly helping the organization, both in network troubleshooting efforts and in rebuilding trust among groups.
The script team that I became the product owner for is an operational team with other daily operational duties. After some discussion, it was decided that their supervisor, also a very technically savvy network person, would become their product owner, and I would become the ScrumMaster for this team. This allowed the team to negotiate with the product owner to determine how much time could be devoted to a sprint on a per-day basis and still perform their normal operational tasks. The team came to a consensus that four hours of their day could be devoted to script sprint work, unless emergency operational issues arose that required immediate attention. Once the team understood that the product owner (also their supervisor now) was on board with them working half their time on two-week sprints pertaining to building network tools, they were much more at ease and settled into a nice, sustainable sprint pace.
Some of the team members added to the script team have different supervisors, and I, as the ScrumMaster, asked our product owner to negotiate the half-day sprint duties with those other supervisors as well. Since he was already on board and understood the timeboxed efforts around his team's sprint duties, it made negotiating with other supervisors a less daunting task. Once all the parties involved were on the same page and understood the new ways of performing, with daily Scrums and two-week sprints, we were able to increase progress toward lacking and lagging network tool development. This has improved the department’s view of how work gets done using Agile, particularly Scrum.
An important thing to remember when using operational staff on Scrum teams is to keep all meetings and stand-ups timeboxed to the allotted time. The last thing an operational supervisor wants to see is their valuable staff sitting in unproductive meetings. Helping them gain confidence in Scrum is part of my effort as a ScrumMaster, and a big part of that is making sure that we stick to the Scrum practices and Agile principles. After as few as two sprints, supervisors can be convinced that positive progress is being made and they can become confident that time is not being wasted in meetings.
Another important thing to consider when estimating tasks for an operational team backlog is to leave room for some number of operational interruptions during each sprint. Estimating too tightly causes the team to feel unnecessary pressure to finish tasks at the last minute because they were pulled away for operational functions. After a few sprints, estimating will become more accurate for your operational teams involved in Scrum. Keeping a sustainable pace is important to prevent team burnout and/or failure to produce working tools and software.
A new interest has emerged from the network engineer group, which is the main consumer of the tools being developed as a direct result of the progress being made from the script Scrum team. The network engineers had previously been at a point of serious distrust with the developers and with the organization as a whole, due to what seemed to them to be the lack of concern about their needs for managing a large heterogeneous network and the necessary tools to do it. Many times they had heard promises such as, "Yes, we are working on it, and that is the next thing on our list," and other words to that effect. After literally years of not getting any satisfactory output due to developer priorities being changed by upper management, and not enough developer resources, the network engineers decided they were never going to get any new tools from in-house. Scrum helped us change that attitude and restore some of the trust with existing resources within operations.
Scrum in our organization has help revive an old interest and spark some new interest in what is going on with tool development that supports our network operations teams. Not only have people noticed some of the more ceremonious events, like daily stand-ups or sticky note boards; they are beginning to see results that they can put to daily use ,which has really made a difference in how they relate to the developer teams. It is beneficial that I, as a former network manager, am now ScrumMaster for the new teams that interact with the network engineers; it is of course also beneficial that they have seen results. Having a credible ScrumMaster and an engaged, decisive product owner helps the new Scrum Team succeed and helps the network-engineer team feel confidence that their needs are being considered and served. Working software helps that more than anything else!
A new trust between the groups has developed, and there is a more upbeat attitude overall. Progress seems to beget progress in multiple ways. Team effort is beginning to be realized as a better way to work, compared to holding all the information close and working in a private silo. When everyone works as a team, the team reaps benefits and that reinforces the team. Overall, we have all learned that there are ways to incorporate operational staff into Scrum, making the organization more Agile and ready to respond in the ever-changing IT environment here at Virginia Tech.
Current rating: 4.8 (4 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.