I’m lifting off a new team this morning and going through a really quick overview of Scrum and Kanban. Most of the people are brand new to Agile and a couple have some experience, or at least know the terms and basics. As we progressed through the morning the term “ScrumBut” and “ScrumBan” came up in the context of applying some Scrum ceremonies (IE: retrospectives, demos) while using Kanban. After a brief introduction to both, including roles, ceremonies blah blah blah, I showed this video:
Then I asked the team, what did they notice about how this team worked, and here were their replies:
- they weren’t afraid to fail
- they had general specialists
- they did customer validation
- they have a clear goal
- they had “grown-ups” (IE: facilitators)
- time-boxes
- there was no hierarchy
- strong collaboration
Then I asked them: “How many times did you hear the ‘A’ word?”
Hmm.
None!
Bingo!
Instead of running a standard process, and since this is a non-software team, we are going to create our own process and proudly proclaim it ScrumBut!
But that’s not Scrum then! As far as I’m concerned, when a team claims their doing Scrum-But, they understand why they are doing what they are doing but they still need a label for it. My best guess is that’s because of human nature. It’s comforting to have a label on a thing to reduce the uncertainty and the validation that what your doing isn’t completely crazy. So in honour of teams who don’t blindly follow a process, here’s why ScrumBut is better than Scrum based on observations and feedback I’ve had from numerous teams: We’re Scrum…But:
- we don’t wait until the end of the Sprint to show the Product Owner because that’s too long to wait for feedback.
- we do ‘daily standups’ twice a week because we all sit together and talk when we need to.
- instead of a defined retrospective, we do a team lunch at the end of every sprint and talk about what we’d like to improve.
- we don’t use the chicken and pigs analogy because, well, it’s stupid and we’re grown ups. Anybody who needs to contribute at the standup does so.
- we limit the number of stories in progress to X, where X = (number of team members) X 2.
- Sometimes our potentially shippable increment is a strategy document
- we do hardening sprints because our team integrates with 8 other applications and there’s alway shit that just happens.
I think it’s ridiculous and hypocritical of the Scrum community anyone to say in one breath “there is no one-size fits all” process and then proclaims that ScrumBut or AgileBut is bad. So for all you horrible people who are learning from what you’re doing and customizing it to suite your needs, FOR SHAME!! Yes, that was laced with sarcasm. We’re all grown ups. Find what works and throw out what doesn’t, give your own label and then create certification program: “Certified Thinker“.