Comment by klik99 | Hacker News Reader

Comment by klik99 | Hacker News Reader

Beware blanket statements! I work with sound in games and have multiple times tried to do Kanban, both from an internal team and an outsourcing team, because of basically the same reasons mentioned in the article - it's agile and task based, and seems like a good fit to be a "factory" for sound assets.

However games are iterative by several orders of magnitude more than traditional tech (I've also been CTO at a more traditional design/consulting firm) and constantly evolving and audio team, both internal or external, end up tightly embedded over the course of 2-3 year long projects, and Kanban ALWAYS breaks down because the edges of tasks are fuzzier than you expect.

Scrum (real scrum, not the surface level dogmatism that passes for it in many places) does work better in this situation. I find myself saying this often "The best tool is the simplest one that does what you need it to". I really do prefer Kanban! It's far simpler. For projects that have clear needs and stakeholders it's great. For "factory" type set ups that provide tools to other internal stakeholders it also works great. But for places where the technical requirements are fuzzy the added complexity of Scrum is helpful, since it focuses on OUTCOMES rather than MEANS/tasks.

Don't be afraid to try different approaches for different sprints/releases and tweak formulas. You can normalize estimation by keeping it consistent while also changing methodologies. But just because Scrum is overused and misunderstood doesn't mean it's useless.

This is the real comment here. I've worked in all three, scrum, kanban and waterfall, and I know from personal experience that they all have their shortcomings and it really depends on what you are trying to deliver and how well your team responds. We've moved from waterfall to scrum to kanban and back and the one standout is clarity of minimum requirements and boy is that hard to get from the relevant people. If you don't get that then stick with waterfall because then no one is responsible!

Yeah, I didn't mention in my earlier comment but I've found that scrum does work better with larger teams because it adds ownership into the process. You can define ownership with Kanban (or any process) but it's not integrated into how it operates without some hacking.

edit I sometimes find myself in the position of apologist for Scrum, which is weird because I'm not that crazy about it, I'd almost always prefer to use something less heavyweight. But people are so quick to throw out the baby with the bathwater - there are a lot of great concepts in scrum, and it's quite interesting to see how all the parts interact when it's actually working.

I hate walking into organizations and they treat their style and acronyms like they’re sacrosanct

No idea what you mean with outcomes vs means/tasks. Just put outcomes as cards in your Kanban board, they don’t have to be tasks.

That's often to big to be single card.

I think they mean it from a softer perspective - Scrum encourages more time ensuring all the team and tasks are clearly directed towards an outcome for that sprint.

Just putting outcomes as cards on a kanban board will not have that same effect in all instances, as it's more about the soft points of engagement and teamwork driving towards that common goal.

Thank you for your answer. Actually it’s perfectly doable, just put an outcome swimlane in your kanban, with a rule that says there can only be one card in the « doing » column.

I’m starting to realize that most people don’t know how customizable Kanban is. You can put as many columns and swimlanes as you want, and then implement constraints in the system with rules around how cards move on the board.

I actually do agree with you that kanban is very flexible - and I have used plenty of additional swimlanes - for my original example we tried using "concepting" stage, multiple iterations, "mix" swimlanes for individual sound effects. These aren't "outcome" swimlanes, because I found that tracking an outcome becomes overly complex tracking subdependencies of the tasks of that outcome. At that point, Scrum becomes better at handling that complexity.

Which is why I always come back to "the best tool is the simplest that meets your need" - starting at Kanban is good, then you can add complexity. If that complexity starts to "outgrow" kanban (though it's a bit like comparing apples and oranges - it's not like scrum is just a more complex kanban, so I'm oversimplifying here) then you want to consider switching to another technique.

It's great that kanban has worked for all your projects and you haven't needed to use scrum!

Thank you for explaining, and it’s great that Scrum is working for you and your team! However, I have to admit I still don’t get it. How is Scrum better at handling outcomes? Are you talking about the sprint goal rallying all the team around a specific outcome, within a specific time frame? I gotta admit I am very suspicious of this way of working because it gets unsustainable pretty quickly, but I would like you to elaborate if you have the time.

It is kinda typical that management likes Scrum because it gives the illusion of control. How much insight into the every day work do you have?

Yeah scrum, or any process really, sucks when it's used like spyware. I've been lucky enough to be part of teams in companies that don't treat their employees like the enemy. So doing scrum the every day work aspect happens at the local level. What I like about scrum is being able to talk to other teams about higher level things while keeping the day to day tasks just within our team. It's similar in programming to the TDD approach of making a public interface and testing against the functionality, while the implementation details are kept internally.

Doing reports I find people care less about the day-to-day work and more about when it gets done, and this is where scrum in theory works well but breaks down in reality. In practice is estimation works when team members are kept consistent, because over time you can track historically "t-shirt size" complexity of task as estimated by the team translates to "x number of man-hours". However in game design we get a lot of major team shakeups pretty regularly with teams changing across different milestones. It's hard to fight against the instinct of "Oh this thing needs our a-team players for this release"

Reply on news.ycombinator.com