Scrum Outside Technology Development

What Is Scrum and Why Does It Matter?

If the first thing you thought when seeing this article title is, “What is Scrum?” Be sure to check out this definition and accompanying videos. For those of you already in the know, you may have heard about a scrum framework being utilized in a technology development context. This agile framework is especially prevalent in software development, helping teams to deliver small, “shippable” increments over specified periods of time instead of developing everything in the project and betting on a single release or deliverable to the client or customer. But did you know that scrum can be leveraged for project management in fields outside of technology? It can, and below I will share an experience of one project where this framework has proved to be an indispensable component of the team’s success. If you are, or aspire to be, a leader of teams you will want to keep reading.

The Dilemma

I was working on a team with eight other team members, and we were wrapping up the first year of a two-year contract to reimagine and redesign the performance management, performance pay, and awards and recognition program at a large federal agency. The first year was a success, we delivered the products the client was looking for and they were thankful for our assistance, but within the consulting team there was a sense that we had been lucky that our final products met the needs of the client. Our client was not the sole decision-maker concerning the direction of the reimagining project, as decisions by a parent agency had dramatically reduced the scope of what could be redesigned earlier in the year. Luckily, these outside-agency decisions had been made early enough in the year that our team could shift its efforts and adjust its deliverables to meet the new constraints imposed upon our client, but we could not be sure we would get so lucky if a similar event happened in the future.

At the end of the first year, the team was split into small teams. Each team had its own focus area, such as policy, communications, and technology, and these individual teams rarely had insight into what the other teams were regularly working on, making it hard for team members to contribute to the wider project outside of their small team. This structure also caused the draft work products of the team to feel disjointed and require extra iterations when combining the efforts of one or more of the teams. Moving forward, the team did not want to leave it to chance that we would be able to adapt our work products to meet the demands that either our client, or their parent agency, may decide upon later in the process.

The Solution

The team needed a solution that would break down the internal silos and enable rapid adjustments when external decisions suddenly changed the requirements of the project. The answer was to adopt a scrum framework and begin to operate the team through sprints, each focused on delivering specific increments of deliverables to the client. Through FMP, I had already become a Certified Scrum Master (CSM), so I had a foundational understanding of how the team might accomplish the transition to this new structure. Moving into the scrum framework, the team reorganized itself with one team member taking on the role of Product Owner, me taking on the role of Scrum Master, and the rest of the team acting as Developers.

The team and I were originally most comfortable adopting month-long sprint increments, although in recent weeks we moved to two-week increments after becoming more comfortable with the structure. The next step in adopting this process was for the Product Owner to develop a Product Backlog. Placing all the, previously disparate, workstreams under a single backlog helped immediately to eliminate some of the silos that had developed within the team. The breaking down of these silos was further enabled through the monthly sprint planning meeting where each task in the backlog was discussed amongst the entire team. This planning process helped to highlight connection points between workstreams and underscore areas where team members could contribute to an area of the project they had previously been unaware of. The ability to share progress and get other team members involved is reinforced through daily scrum meetings, lasting no more than 15 minutes, where each team member shares what they worked on yesterday, what they are working on today, and any barriers they are facing.

At the end of each sprint, the results of the team’s work are shared with the client, offering an opportunity for collaboration, discussion, and approval on the direction and products of the project. Following the delivery of this incremental progress, the internal team meets again during a sprint retrospective to discuss what went well during the last sprint, what could be done better in future sprints, and what commitments they are making to improve their own process, tools, and relationships.

As Scrum Master I am responsible for scheduling and facilitating the planning, retrospective, and daily sprint meetings. I also meet with each team member, one-on-one, during each sprint to discuss what is going well, what concerns and questions they have, and what else I can do to help support them. This routine touchpoint offers the team an opportunity to communicate in a setting where they are not on-the-spot in front of the rest of the group and can comfortably voice an opinion that may differ from the rest of the team. These meetings have improved interpersonal relationship throughout the team by enabling me to coach and intervene with team members when there are disagreements within the internal team as well as to gather additional feedback to improve in my role and improve the overall team’s processes.

Delivering increments within a tighter timeline has provided the added benefit of enabling the team to change direction if the client would like to see something different or if an external source, such as a parent agency, hands down a new direction which requires the scope or requirements of the project to change. Since adopting this structure, the team has delivered consistently high-quality deliverables, earning regular kudos, and has built a stronger collaborative relationship with our client, while being able to quickly adapt to external pressures that have impacted the direction of the project. For the team and I, introducing scrum has enabled us to work more efficiently, improve our responsiveness to the client, and react more rapidly when a change in project scope or requirements arise.

Does Scrum Work On All Projects?

Using an agile framework, like scrum, doesn’t work for every project, but it can generally be applied to any project where deliverables can be released in versions and continually improved. There are examples of scrum being utilized in political campaigns, music album productions, and even running a family household. Even if your project is not a good fit for scrum, there are still helpful practices that can be adopted by teams or individuals to improve their process. For example, even before introducing scrum to my current team I was using a Kanban board to track my individual tasks.

Have you used scrum outside of a software development setting? Do you have an interest in introducing scrum to your team or project but you don’t know where to get started? Share your thoughts about scrum and other agile frameworks with us on LinkedIn!

Justin Fuhrmann joined FMP in April 2015 and works with the National Geospatial-Intelligence Agency on policy analysis and formulation, employee benefits, benchmarking and interviewing. Justin is from Bergen County, NJ and now lives in Arlington, VA with his wife and three daughters. Outside of work you can find him skiing, hiking, or exploring the DC monuments.