Item — HN Reader

The problem with SCRUM is that it is not agile. That's why we see most of the pragmatic companies adopting a kanban or scrumban approach and they see good results.

I would argue that just having a kanban board during stand-up meetings and "walking the board" instead of interrogation-like status reporting is going to do wonders to team collaboration atmosphere, morale and actual productivity.

You start to see and talk about the flow of value, what's next, what's in the moment ("what can we do right now?). You see context. All of that is missing with SCRUM or only possible with a highly motivated and responsible team that communicates a lot automatically.

I'm not yet saying that kanban is solving the software crisis [1] but it turned around quite a few teams that I've seen and been part of.

DISCLAIMER: I'm working on https://www.blossom.io which is a lightweight kanban board.

1: http://en.wikipedia.org/wiki/Software_crisis

1 comments

Can you elaborate on why Scrum is not agile? You are the first I read claiming this.

Great question.

I might have a harsh tone in my previous comment but I've got really frustrated with scrum (or implementations of it) over the last few years.

Scrum in my eyes is a process and from what I've seen it makes teams very process oriented. The whole idea of scrum master certification and the success it had in enterprise adoption might have something to do with that.

It incentivises teams (at least all the teams I've seen) to work for the process as good as possible. They focus on complying to the process, getting estimates right (or working in a way that makes the estimates right), they focus on the backlog instead of throughput or frequent re-prioritization …

If you can free yourself from viewing the 'process' as fundamental religion it's easier to apply agile & lean principles like focusing on delivering value and improving the framework, changing things, changing the process so it fits your needs, etc.

In a nutshell: I see scrum incentivising people to work in a way that is not agile but pseudo-agile/feel-good-agile. I see no feedback loop for the process itself (at least I see no one doing that, except teams that adopt kanban and scrumban or do scrum but …).

But I'm interested in learning from people who've made other experiences. It's an exciting topic.

I see no feedback loop for the process itself...

If a team fails to deliver the functionality they committed to, there are consequences. Before the next sprint starts, they figure out what went wrong and incorporate that knowledge going forward. That's feedback on the process. And whether they have a green sprint or a red one, their velocity on the sprint is measured and used to project forward. Again, that's feedback on the process. Then there is a actually a dedicated retrospective phase at the sprint review where the team gives specific feedback on how the process went. The whole point of having sprints is to ensure that there's frequent feedback on the team's performance, distinct from any feedback they get on the product itself.

Disclaimer: I actually use a kanbanish leanish approach myself myself. It's my preferred process for my current working context. I'm also very much not a fan of the Scrum certification process and what that has tended to produce in the industry. However:

I see no feedback loop for the process itself

Is just nonsense :-)

Scrum has only five events - and two of those are retrospectives (one on the increment, one on the process used). If you aren't inspecting and adapting the process then you are not doing Scrum.

Now I freely admit that one of the most common ways that people don't do Scrum is by skipping those steps. Then again it's also the most common way I see people do kanban/lean badly as well.

Certification is a gimmick. Scrum guidebooks don't say you need to get certified. You can buy a degree in Kanban too if you want. Is programming worthless because Java certification exists?

I've heard this before. I think the most simple reasoning there is that the Agile manifesto says: Individuals and interactions over processes and tools. In Scrum it is process over individuals. The process is what is important, not the individuals.

That's certainly not the intent behind Scrum though. The intent behind Scrum is to let the team within the sprint be pretty much completely free to implement whatever process they like to deliver the sprint goal. It's whole focus is to remove management interference from the main body of work the team does. PO figures out what needs doing. Team figures out the best way of doing it. Scrum provides a framework for accountability on both sides.

Scrum - done well - should be a tool to let the team figure out the best way to deliver.

I know that. The historical motivator is the 1986 paper, "The new new product development game". I think the difference in what happens in Scrum is that the team gets further isolated from an organization through the ScrumMaster and Product Owner and therefore has less ability to influence and more process imposed (the various invariable rituals of Scrum and more). The teams are now viewed as units of production, stick story in, get implementation out. Almost never will the Product Owner be really a product owner within the intention of Scrum and the ScrumMaster will drift towards a semi-team-lead role and his incentives are not aligned with those of the company or the team.

Agreed. That sort of setup does suck. But then again that sort of team isn't really doing Scrum (they're certainly ignoring the way the roles should work, and they're certainly not using the sprint retrospective to improve).

This isn't Agile sucking, or Scrum sucking. This is folks not doing Scrum sucking.

The issues that caused the OP to move from Scrum to a Lean approach - I can go with most of those (indeed they match my observations of some other transitions)... but the delivery one doesn't ring true in my experience. I've seen a bunch of Scrum teams with a laser like focus on delivery.

tosh has replied already, but I'll offer my explanation as well: Scrum is not Agile because it's all about ceremonies (the planning meeting, the daily standup). The only ceremony that brings some value to the project is the retrospective.

Just because something happens routinely doesn't make it ceremonial. You turn on your computer every day as you begin work. Is that a ceremony? You eat a meal every day. Is that a ceremony? Pay rent or make a house payment every month? More ceremony?

What you mean, I think, is that you don't see the value in the activity, or have some other aversion to it, so it's purely ceremonial to you. I assume (maybe incorrectly) that you do see the value in planning your work and communicating with your teammates, you just prefer not to do it on a regular schedule. I'd prefer not to make my house payment on a regular schedule either, but doing it every month ensures that a) I'm always making steady progress on my mortgage, and b) I don't caught in a cash flow bind when I suddenly have 6 months' worth of payments to catch up on.

You have a good point in that I don't see the value of imposing communication and forcing people into meetings, however why the straw man? Eating and paying rent definitely have a value, so why bring up the comparison?

Because communication and planning also have value, even according to you, as long as they aren't 'imposed'. But what is really being imposed here? Simply the timing, the regularity of the events. Just like eating or paying the rent.