Over the past decade, I have been lucky enough to work for a number of high-profile companies in industries ranging from software development to higher education to manufacturing. At each of these companies, I have noticed common challenges that teams face when trying to apply Scrum (a popular Agile framework) to non-software projects. Grappling with these challenges has helped me learn some important lessons about how to leverage Scrum successfully — even in a non-software context.
The Challenges of Deploying Scrum in a Non-Software Context
First and foremost, it’s important to recognize that Scrum was designed to address some of the shortcomings of the traditional waterfall approach to software development (i.e. development teams go into a back room for over a year, and when everything is complete [or their time is up], they show what they have to business stakeholders). This approach often leads to business stakeholders saying, “This isn’t what we thought we were getting,” or, “The market has shifted and we no longer need this solution.” Sound familiar? Scrum reduces the risk of encountering this type of scenario by delivering incremental enhancements (features/functions) every two to four weeks and regularly soliciting and incorporating valuable feedback from key stakeholders.
When you’re designing/building software solutions where tangible, visible results can rapidly be achieved, this approach is highly effective. However, applying this framework at a company that develops physical products that can take months or years to design and build can be a struggle. It is even more complex for companies operating in highly regulated industries — imagine trying to deploy this framework in the automotive or medical device industry where teams typically follow a linear design/build/test/launch process.
In these instances, many elements of the work do not lend themselves to being demonstrated (e.g. regulatory activities, contracts, documentation), and it becomes a lot less interesting to present this type of deliverable for review. For example, manufacturing companies can show 3D models/prototypes as part of a demo, but once the design team gets to design freeze, the subsequent deliverables are less interesting to demo and the process is pretty much defined per regulatory requirements.
Additionally, teams in these environments can often be comprised of eight or more roles. In software development, there is typically (at a minimum) a UX Designer, Developer, Business Analyst, and Tester, which makes sharing the work and supporting each other easy. Conversely, sharing the work across a non-software team can be a challenge because a regulatory expert can’t be expected to execute design tasks. The allocation of work becomes more siloed when a company doesn’t need its full team to size the work but can rely on individual SMEs to size-specific tasks/stories.
Six Tips for Successful Scrum Deployment
So how can companies operating in non-software environments utilize Scrum successfully? Here are some practical ways to proceed:
- Foster leadership buy-in: Ensure leadership understands the benefits of applying Agile concepts, as well as the challenges that may occur when doing so. Have a plan to address these challenges to convey to project team members that you’re proactively anticipating and responding to them.
- Adjust the Scrum framework as necessary: Be open-minded about tweaking the process to accommodate the type of project and the dynamics of the team. The challenge here is not to tweak it so much that you’re no longer applying Scrum— there are rules and guardrails that you should follow to make sure your teams are benefiting from the framework’s core principals.
- Deal with specialized roles head-on: Recognize that some team members may have more work to do in one sprint than others do, and that not everyone has the skills to complete specialized tasks. While you should identify the critical items that need to get done and focus on completing them, you can also encourage other team members to help wherever they can. The ideal scenario here involves various team members stepping up and helping move the needle as much as they can when one of their fellow team members expresses that they are struggling to complete all their work. When your team starts doing this, you know they get it!
- Manage team capacity: Whether you use Scrum or not, increasing a team’s capacity will typically reduce a project’s cycle time. Scrum recommends that you create dedicated teams so that each team can focus on a specific project instead of struggling with “context switching” and misalignment of priorities. If the nature of your projects doesn’t require 100 percent dedicated roles, you can have teams work on multiple projects. That way, team dynamics and relationships remain consistent — as do the Scrum Master and Product Owner —eliminating opportunities for conflicting priorities.
- Train everyone: When looking to roll out the Scrum framework across an organization or within a group, be sure to train all those involved — including leadership. Ideally, you should meet with folks who thoroughly understand your new product development process and work with this group to tweak the Scrum framework to fit your needs.
- Be open and ready to change: The Scrum framework shows you what your problems are, but it’s up to you and your leadership team to fix them.
A Proven Approach to Scrum
At SEI, we’ve spent many years working on these types of initiatives and have developed a well-defined approach that helps organizations through the process. We recommend that organizations start small, establish credibility, try/fail fast, refine the process, and expand only once growing pains have been worked out on a pilot project. During the trial/implementation phase, it’s vital to have a Scrum coach support both the team and the rollout. After training, team members will require extra hands-on guidance on how to work effectively within the framework. Coaches also help teams stay within the framework’s guardrails and continue to refine their processes, even with mature teams.
It’s thoroughly rewarding to watch teams make this transition firsthand. People who are initially skeptical of the process typically change their minds after two or three months of practicing Scrum. The culture shift from being “voluntold” to do something to signing up for work and tasking out deliverables really gives team members a sense of ownership over their work. When teams have moved all their tasks to the “completed” column on the Scrum board at the end of a sprint, a sense of accomplishment really can be seen on each and every team member’s face.
