Agile in non-software development teams

I’ve had some great opportunities working with teams applying lean and agile techniques to domains beyond software development. Along with other areas, I’m having lots of conversations around applying Scrum in HR teams.

This is fairly unique because the core usage model for Scrum is to apply it when the work is fairly unknown and complex, and the team is working together to create a shared product. Many knowledge worker teams simply aren’t like this. HR tends to be one of them.

It helps to identify the different types of work happening in each team. I delineate three types of work: project work, ad-hoc work, and repeating work. Here’s what I mean by each.

Repeating Work

This is work that happens on a schedule and happens often. For example, new employees may start on any given Monday in our organization, and processing the paperwork of adding those new employees is something that happens each week, regardless of other plans.

Ad-Hoc Work

Ad-hoc work is what happens when something out of the ordinary occurs and must be dealt with immediately. In IT this would be akin to, “the server is down.” In HR it might be something like, “someone just anger-quit” or some other circumstance that must be dealt with immediately.

Project Work

This is work that fits into a project (has a beginning and end) and has a clear deliverable. This work is planned and is often amendable to being managed with lightweight Scrum. Project work is often the work that motivates people and offers them opportunities to go beyond their traditional responsibilities.

An example of project work might be creating a newsletter for a company’s new wellness program, planning an event, or implementing a new benefit program.

Teams vs. Teams

In agile software development teams, we try and break down silos between individuals and encourage shared accountability for work and output. While this is a worthy goal, it is more difficult in teams like those we find in an HR department. In these teams, we really do find teams of individuals rather than a single cohesive unit focused on one deliverable. While one can argue that it would be an improvement to grow the team into one with shared accountability, this is far easier said than done. Teams of individuals are the norm.

We All Want More Project Work

Project work is typically what moves a team, department, and ultimately a company, forward. Yes, the repeating work must be done to maintain current levels of service and excellence. Yes, the ad-hoc work is often very important and cannot be deferred.

Yet, project work typically is where we get to add new value. We get to create something that didn’t exist before, whether it is software, an education curriculum, a new HR program, or perhaps revamping of an old system.

Project work (sometimes ad-hoc) is where we get to exercise autonomy, mastery, and purpose. Predictably, it is the work that most people find fulfilling. It also happens to be the work Scrum is most adept at managing. Repeating and ad-hoc work are typically things that take away from a Scrum team’s capacity (whether we track it in the Sprint or not).

Lightweight Scrum for Teams of Individuals

Scrum perfectionists beware, I am about to run an Extract Interface on Scrum, leaving a few bits behind for software teams to implement.

We’ve used a lightweight Scrum-like process for managing our family’s work for many years and I’ve found that applying similar practices to non-software teams tends to work well as a starting point. Here is my base formula for an agile practice in environments like these.

1. Plan work together no less often than every 3 weeks. Focus on project work first while doing so. Leave capacity for ad-hoc work.
2. Show your work to each other and stakeholders at a Sprint Review. Solicit feedback.
3. The team reflects on itself and how it does its work each Sprint.
4. The team keeps a visual representation of the Sprint Plan current at all times. This is typically a wall of cards, Trello, or some other lightweight approach.

Note this is a starting point and not an ending point. Over time, we hope to see more cross-training and generalization in the team. We hope to see fewer incidents of ad-hoc work. We hope the team will actually learn to self-organize. All of these things can indeed happen and more.

There are lots of places to go once you have these basic elements in place.