Both. And it's a sliding scale in real life - you might be completely Kanban, or completely Scrum, or somewhere between, where you're doing some Scrum ceremonies and processes but skipping the ones that don't help you .
I usually look at the processes the team want to do, and the main question is "how do you want to plan your work?"
If you want to be planning, estimating and agreeing fixed amounts of work to be delivered in specific time periods, Scrum. If you simply want to let things flow in ad-hoc and let your leads prioritise and the developers take things off a to-do list whenever they're ready, Kanban. Most people do something in-between.
If you try one and it doesn't work, it does not matter. You can swap to the other. Better, you can do both at the same time. There are plenty of places I know of that are doing Scrum pretty much full on. And while they're running Scrum "properly", they're using Kanban boards to visualise, focus and supplement their Scrum process.
@Nic Brough [Adaptavist] I don't agree that it doesn't matter.
Scrum is a leap forward from waterfall techniques, of course. And it was born at a time when companies would hire outside firms to write 500 page requirements which would then be handed over to IT teams with an already set deadline - or at best a request to make an unchangeable commitment. We all agree that was lunacy, especially for new product development and that Scrum was a great solution to bring sanity back.
However, I think Scrum is showing some signs of age. It is a framework that insists you follow all its rules to the letter or you're not doing Scrum. That feels counter to the agile mindset.
I've worked with teams that have moved away from Scrum and now practice Kanban, and by and large all of them feel better for it. I think Kanban is harder, because there's less ceremonies and rigidity to protect teams from unreasonable business owners - but if done right it's going to better represent the reality of all the work a team does and provide a framework to continously improve that's more grounded than Scrum.
Scrum's metrics are also limited. Teams focus almost exclusively on burn downs and velocity, which are powered by story points. Story points are a hard concept to grasp - I spent too much time trying to explain this magical concept to teams who almost inevitably converted them to actual times in their head.
Instead thinking of work in terms of throughput, time-in-process and wait times sidesteps all of that and focuses the conversation on more business-friendly metrics so teams can get down to the business of finding and removing bottlenecks.
Scrum is also all about the sprint - a batched set of work usually over a week or two or sometimes more. But in practice the teams I work with have spikey operational responsibilities - a support ticket from an important customer or a sudden problem in production - and in Scrum these just look like scope changes (which reminds me of the waterfall days) instead of a normal part of supporting a product in use by lots of people.
Better instead to know your team's capacity based on limiting the total amount of work in flight at any given time no matter what that work may be. Good teams will budget their time according to current business priorities - maybe in this quarter it's important to focus 50% feature work / 20% operational support / 20% house cleaning. Maybe next week there's a big release with a high potential of lots of support work so we adjust that for that week. I find it much easier to tune in a Kanban system.
So all that said if you are doing Scrum it's easy to layer in elements of Kanban. Setting work in progress limits for your 'to-do' columns is the obvious first step. Adding Kanban metrics in addition to the Scrum ones is the next one. You might just find after awhile that you can shed the extra Scrum overhead and speed along just fine.
You didn't read what I wrote after "it does not matter", where it makes the point that you can swap if you decide you've gone the wrong way.
Your essay is useful to know, but it's just about what worked for you. It won't work at all for some teams, they need Scrum. Or Kanban, or something in between, or something with other layers.
And it's quite interesting that you say "people are doing Kanban" and then go and add back a whole load of stufff Scrum does that you threw away before.
Hello Atlassian Community! My name is Ada , and I'm the Product Marketing Manager for Confluence Server at Atlassian. If you missed our last post, we're transitioning to quarterly updates&nb...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs