When we hired a new CTO at Valore, we rolled out agile/scrum with our product and engineering teams. We had been in the waterfall dark ages. We predictably experienced every bad outcomes one could expect from a misaligned development process. It took some time for the team to understand it, get comfortable with it, and realize the many benefits of it.
A sampling of the many benefits we have experienced from adopting scrum include:
- Increased transparency resulting in better stakeholder expectation setting and prioritization
- More engagement from the development team which translates into higher quality work
- Improved planning, both with accuracy of timing, as well as visibility
- Reduced churn on work. Better visibility and planning made moving to a just-in-time creation of user stories possible. That reduced wasteful cycles of requirements gathering
- More valuable output. Value measured as quicker time to market (time is money), higher ROI (by pushing MVP features/products), and higher quality software (from engaged teams)
Agile and scrum are often thought of as software-specific processes that ‘tech people’ do. I have never quite understood that perspective. Agile takes complex work, and breaks it into small, meaningful chunks to help teams execute better. It also helps set clear responsibility boundaries between people involved in the process.
Nothing (ok – well the manifest does state software in a couple cases) says non-software teams cannot use agile. I had been thinking about how it would work in a non-software world for a while. My internet research came up with few, if any, examples of scrum adoption for non-software teams. Nothing detailed out the experiences, do’s/don’ts or best practices of scrum for non-software teams.
As with everything, doing is better than thinking, so why not give it a shot? Try it in the real world and see what happens. So, I rolled scrum out to my operations team. Keep in mind, this is not an engineering ops team (DevOps/TechOps/etc). This team focuses on moving widgets, handling customer service, processing inventory, and combating fraud.
The results are not conclusive yet. We are only a couple months into the adoption, I do want to highlight some of the things we have learned in our adoption so far. share those with anyone who might be considering a similar move with a non-engineering team.
- Commit to full adoption
- Start formally and with the most basic, yet complete form of scrum. That means anointing a ‘product’ owner, determining what a point means, defining the ‘definition of done,’ two week sprint cycles (no shorter), retrospectives, stand-ups, and user stories in one (and only one) backlog. If you can invest in training, do it. The team must have a foundation and understand what they are getting into, if they are to be successful.
- Treat ‘ongoing work’ explicitly and try to kill it
- The operations team has a variety of things they do every day (i.e. answer customer support tickets). This work must still occur to keep our business running. Do not shy away from this work or including it in the sprint. The team should be explicit about what they must do and how much time it takes them to complete these tasks. Discuss that effort before every sprint commitment. This should give the team has a clear sense of how that will impact the rest of the stories that they commit to. If you do not make this clear, the team is not in a position to be successful. Over time, the product owner should think about these activities and how to kill them. This is no different than tech debt. Automate the work or at least figure out ways to cut the effort needed to complete it. This will allow the team to complete more valuable, strategic work.
- Dependencies on third parties (internal and external) are tricky
- Third party dependencies can kill any sprint, regardless of whether it’s software or not. A non-software team will be more dependent on third parties than others. This doesn’t change the fact that such dependencies are a challenge to the successful completion of the team. Putting your team into a scrum process will highlight dependencies exist, internal and external, that get in the way of progress.
- User stories are critical
- It will take time for the team to get a good feel for what is an appropriate acceptance criteria. The team needs to think of what the business-valuable deliverables would be for a particular story. It will not be production software, but it can still be well defined. Keep user stories focused on the “As a ____, I want to ____, so that I can _____.” Keeping the narrative focused on the expected user benefit (and why) will help the team deliver the right things.
- The team must iterate
- Empower the team to evolve the process, as with any other implementation of scrum. They must do retrospectives, and they must fully own whatever they adopt. The process is theirs now, as long as they stay true to the values and principles of agile.
Those are just a few of the early take-aways on the adoption of scrum by a non-software team. As this matures more, I will update everyone on how it’s going and what else we’ve learned along the way. Many of the results that I listed at the beginning of the post are also coming true for the operations team. Who would not want a team to experience those benefits? If you are on the fence about it, I say jump right in and go for it.
Have you used an agile process for a non-software team? What was your experience?
newmanea 