Scrum is big in software and it’s slowly creeping into hardware development. To me this is good news because Scrum would be a transformative for hardware teams. In an industry that relies heavily on the big bang, iteratively coming to potentially shippable checkpoints, as a team would do with Scrum, would be a welcome change. It would give users and customers early access to product (or some version of a product depending on the technology involved), there’d be increased opportunities for feedback and the narrowed sprint-to-sprint focus on feature subsets would propel a significant improvement in quality.
Yes, Scrum would be great for hardware teams… unless, of course, we strip out the practices and objectives that make it effective and bend the rest around practices we already use without actually changing much. That would be less great.
In software development, Scrum with all the difficult bits (aka: the effective bits) removed is being called ScrumBut, as in…
“We’re using ScrumBut <insert reason to avoid some aspect of Scrum here> so we <insert short-cut alternative here>”
Because Scrum can be a huge leap for teams, ScrumBut is pretty common. If you’re not used to it, coming to a truly shippable checkpoint every 30 days is a feat. Constraining yourself to a subset of features during a sprint and staying focused without being consumed by the big picture takes a lot of courage. Iterative planning when you’re used to big-up-front-design will feel like a leap of faith. Even finding 10 minutes a day for a standup is no small task when you’re used to weekly 2 hour status meetings. Scrum is hard so I don’t blame teams for falling into ScrumBut… as long as they recognize what they’ve done.
Some ScrumBut teams don’t acknowledge the difference between Scrum and what they’re doing. That’s a problem. In some crowds, the various interpretations and hearsay have perpetuated a view that Scrum is a pick-n-choose collage of exceptions.
But that’s software. What about hardware?
Well, unfortunate for the hardware crowd is that it seems we’re taking our initial cue from ScrumBut. I’ve had that feeling for a long time and it comes from stories and the various interpretations I’ve heard since getting involved with agile hardware development. The monkey wrench that makes it worse for us is that we’re already a giant side-step removed from software development. We’ve not only started on shaky footing, but knee-jerk reaction is to assume Scrum should be modified to fit our domain. That’s how we get to the hardware version of ScrumBut, which I like to call ScrumUm, as in…
“Ummmm… I’m not sure this is actually Scrum”
Disclaimer: Before I go on, I’ll clarify that I would never suggest hardware teams avoid Scrum because it’s probably worth a shot regardless of how it turns out. I would, however, suggest teams put some serious time into researching Scrum and deciding collectively whether or not it’s the right way to get started with agile development. Specifically, it’s important to understand the technical practices required to make Scrum effective. If the answer is ‘yes’ at that point, then my hope is teams start with Scrum by the book, moulding the details to their circumstances through their own experience just as the authors of Scrum intended. If the answer is ‘no’ – which in all honestly is what I would hope for from most hardware teams – then I’d suggest a different direction starting with primary practices from XP. Anyway, back to ScrumUm…
I see jumping into ScrumUm as buying a new gym membership. It’s January 1st (i.e. you’ve just taped out a chip) and you’re not exactly happy with what you see in the mirror. You reckon it’s time to get in shape and think shelling out cash for a gym membership will be the motivation you need to get moving. Spend the money – make the commitment – and you’ll have no choice but to pound out a few reps on the squat rack after 45 minutes on the treadmill 5 times a week. February rolls around and you find out paying for a gym membership is not the same as committing to a healthy lifestyle. Sure you go once in a while, but it’s getting easier to cut corners and the results have fallen short of expectations. Instead of investing in a trainer you tried to learn exercises by watching others. That worked until you overdid it and couldn’t move for a week. You didn’t start with a program or a tangible goal either (other than the ubiquitous “get in shape”) so it’s hard to measure any improvement anyway. But hey, at least you can tell people you’re there and you’re putting in the time… kind of. Now it’s September and you realize it’s been a few weeks since your last visit. You quit going. When your friends ask, you tell them about the time you hurt your shoulder. The gym just didn’t work out.
Being at a gym and changing your life at a gym are not the same thing. Likewise for ScrumUm and Scrum. Jumping head first into Scrum to fix broken development process without a true commitment to the transformation will mean there is no transformation. You’ll be left with ScrumUm… which is kind of, sort of like Scrum but not really. After a time you’ll end up wondering what’s the point and slide back to whatever you did before. When your friends ask you’ll tell them Scrum just didn’t work out.
Wrapping up, I’ll repeat that my intention is not to deter teams from giving Scrum a shot. But unless you’re really invested in Scrum, as defined, complete with tangible/shippable delivery objectives and all the rest, I hope you’ll consider hacking off the ‘um’ and calling what you end up with something different altogether. It’ll limit the confusion for the people around you and help to preserve the transformative potential of what is a clearly defined framework.
-neil