Can Scrum be used outside software development? Absolutely.
There's something very important though. In terms of credibility of you as a leader or as a coach or practitioner working with people in non-software, there is a brand that goes along with a lot of agile folks that they’re working software and they’re preaching to people outside software for ways of working that might not be suitable.
And there is merit in that argument. I’ve often worked in cases in non-software where I might have had 10 options that I would consider for the team. But actually, when I understood the work more, I reduced that down to maybe two or three options. And so it’s crucial that if you’re working in non-software and also I would argue in software you need to learn the business domain.
You need to learn the technical domain. You need to understand what’s going on. It just doesn’t lead to credibility when you don’t understand the work that people are doing when you don’t understand how the work flows and what problems people have with the work. Often we don’t know where the real wall is.
A lot of agile coaches, and scrum masters think when people are resisting some of the ideas that we’re presenting, they think that we’re presenting a fake wall that there really is no barrier that, the person they’re thinking hasn’t been opened or not. But often I find there actually is a wall and the sooner we find out where that wall is the better, and that wall can be discovered. If you understand more about the business domain and the technical domain, you understand what the team is doing. you can absolutely achieve that. You can achieve agility outside non-software but you need to understand the work.
And then you need to think about what would be the right strategies, frameworks, methods, or values and principles that you can use to demonstrate agility in that area. Scrum often struggles in this area because, in non-software in particular, work items tend to take longer than 30 days. And what I see happening a lot is people break down work items to fit within 30 days because they want to deliver something in 30 days.
But if you’re delivering something in 30 days that actually is invaluable and it’s not even contributing to value, not even enabling value, we lost the plot. Then I would prefer a team in that situation to use something like Kanban it takes two months to get the work done.
And then we look at how that value is being contributed. And you can also look at Kanban for complexity, for example, which allows you, to have, and encourages you to use reviews when you’re working in complex work retrospectives when you’re working in complicated work reviews also in positive chaos.
Daily Scrums also, when you’re doing complicated or complex work and you can have a rhythm, you can have cycles equivalent to the sprints. For example, don’t necessarily need to be restricted to four weeks. You could have longer than four weeks cycles for reviewing how things are going on in non-software.
But what I often find is once the agility improves in non-software, we do actually find ourselves in a space where we do get work items done in 30 days. It’s just initially we don’t have to be careful about trying to break work down to 30 days or less when maybe it doesn’t make sense. You’re not really delivering value at that point.
You have to weigh up what’s the right thing to do. Sometimes it’s good to bring in some frameworks like Scrum, for example, because people understand it, they can work with it, they can get trained and then commoditized way on it and so on. But if you’re using a framework or method or a strategy in a way that isn’t really suited to the way it was designed you could do more damage and you could lead to people getting into this plan versus the actual mindset where they think we’re gonna break down the work items to fit within a Sprint. And it just becomes breaking down the work like work breakdown structure, using Scrum, for example. And that’s not something that I recommend equally, by the way, you can do Kanban badly as well, visualizing rubbish on the wall and not even visualizing all the rubbish on the wall and not limiting work in progress.
Kanban done professionally is about limiting work in progress and having policies about how the work moves through your system. And there’s a lot of discipline involved in Kanban a lot of discipline as well in, design thinking, lean UX, lean startup, all these other approaches, and you can even make up your own approach.
In fact, in one of the first teams that I worked with was a non-software team, I did make an approach. That’s how Kanplexity™ got invented. It was because a team had a cycle time for the work items of four months or longer. And I felt we couldn’t use scrum. I also felt that the values of the team weren’t compliant with the scrum values.
So I came up with something different called Kanplexity™. So it is possible. And with other skilled practitioners as well, they could come up with their own approaches as well. However, I would say to you, if you just stick to values and principles, there are different schools of thought out there about this.
Some people can operate based on values and principles. I’ll find at very large companies, two-thirds of people need some rules. They need something to follow. Of course, if you can have less rules, that’s better. I find in practice that some kind of framework or strategy or method does help a team to make some progress.
It reduces the number of choices they have to make. If you can operate purely based on values and principles, all the better for you just be careful that it could lead to negative chaos. Just make sure that the people that you’re working with, they are in that space of where they can truly operate based on values and principles.
So can you be agile outside non-software? Absolutely. Just be careful.
Thank you.
https://linktr.ee/johncolemanxagility - social and podcast links
https://linkpop.com/orderlydisruption - order training from right here