Hacker News Reader

Comment by frandroid | Hacker News Reader

We now use Kanban on our team, after using Scrum for a couple years. Pointing is a process to discover unexpected hurdles or uncover hidden knowledge from coworkers, and as a guideline. By not having sprints, you just focus on your current ticket, and not artificial deadlines or points. Tickets will be done when they are done, and managers don't have expectations of completeness that as disconnected from reality. We've added priority swim lanes to our process. We have a prioritization meeting with PMs every week to assign priority to tickets, order items in the high and medium priority lanes, and review blocked items to see if anything can be nudged back to a working column. The process is clear, the expectations are fluid, the work gets done in the time it needs to get done.

View on HN

There's certainly a lot to like about that approach. But my experience is that it makes it very easy to end up with tickets that end up taking months (because there's no longer a natural point at which to stop and take stock), and/or accepting tickets that don't really have clearly defined acceptance criteria, which risks working on something that won't actually turn out to be useful. I don't like the artificial 2-week cadence of Scrum but I think I might still prefer it to not having one at all.

When I worked on a team like this, the rule was that when you came free and are looking for work, before you started any new stories you looked at the work in progress to see if you can help out to expedite any of it. The idea is that it's everyone's responsibility to try to minimize the work in progress (Lean).

We also had the general expectation that one story should generally take no more than about two weeks. Before starting a story, if you think going in that it will be too big, then you try to limit the scope or defer parts of it into new stories until you're confident it can be done in two weeks.

Once a week we tracked how long stories were in the "In progress" column, and once it'd been up there for three or four weeks, people started asking how they can help wrap it up. I think the longest I remember a story being in progress was about 6-7 weeks, and that was real uncomfortable for us. Typical times were 1-3 weeks.

So we had a weekly cadence for demos, and product owners liked that they would see steady, regular progress rather than being inundated with sudden large dumps at sprint boundaries.

Two weeks! Any story that takes more than 2 days is generally broken down into smaller stories. A two-week project is more like a small epic...

Lots of teams have different expectations about how granular a user story should be, and some of this has to do with the project. How fast can you design, develop, test and deploy a meaningful amount of new content?

One explanation for the longer time is that we had a process where for each user story we'd write a short, informal design document and send it to the team and stakeholders for review. For non-trivial stories we'd then meet to discuss them and come to a consensus about how to implement it. This probably added about a day or two to a story's duration, but it meant that we had a solid system at all time. It also often served a similar purpose to a retrospective, or produce topics for a retrospective, because these meetings would surface any technical debt and other impediments to progress. It also served as knowledge transfer and helped the team converge on design principles and expectations.

So these meetings had a cost, but we felt it was essential for practicing agile design. We didn't find this made us slow to react. On the contrary, because this kept our technical debt low, and our software well designed and well understood by the whole team, it meant we could pivot on a dime.

I think there's a real risk in going too fast. Maximum speed should not be the goal of a software development process, and I don't think any business really wants that. The two primary goals should be: 1) to make predictable, steady progress over long periods of time, and 2) the ability to change priorities as quickly as possible as new information emerges. If you have to sacrifice some speed to get there, it may be worthwhile.

It's up to ticket creators to pipe up if their request hasn't been worked on forever. But we recently reviewed the whole board with the PMs and that was pretty good for getting some things out of limbo, and closing others that never got that important.

Add WIP limits to your columns. That means no cases can be added without other ones been completed first.

That doesn't help. If you have n people you need to allow n tasks in progress. The problem is one person being on the same task for 6 months.

Honestly I don't think that's an issue, if you lead developer is keeping on top of the kanban board, he will notice it and address it.

Most Kanban boards allow you set to mark items if they go past a certain time.

Manage by exception. If most cases just take a few days, set up some kind of system to mark the outlining cases out. Then you can investigate and address these exceptional cases if required.

> if you lead developer is keeping on top of the kanban board, he will notice it and address it.

Do you have some extra process that makes this happen? I don't remember anything in the version of kanban I saw that implied the lead developer should be doing this.

> Manage by exception. If most cases just take a few days, set up some kind of system to mark the outlining cases out. Then you can investigate and address these exceptional cases if required.

In the project I'm thinking of it wasn't a single exception; rather the length of a typical task gradually crept up (from below 2 weeks at the point when we switched from scrum) until it was normal to have tasks lasting multiple months.

Then you leadership is not doing it right. Cases should take days at most, more then that they should be broken up.

The whole point of Kanban is to have everything visible and known. If your not looking at the Kanban board and taking action based things that look wrong whats the point?

> Then you leadership is not doing it right. Cases should take days at most, more then that they should be broken up.

It's easy - and useless - to make this about people. The point is, this is a problem that we didn't have under Scrum, with the same people.

> The whole point of Kanban is to have everything visible and known. If your not looking at the Kanban board and taking action based things that look wrong whats the point?

At what point does it look wrong? If the idea is to have everything visible why does Kanban generally include fewer stats than other processes? I was always told the "whole point" was limiting work in progress.

It's a problem under scrum as well. Just because the sprint is ending doesn't mean the case will finish. They just get dragged into the next sprint

That's not supposed to happen, and the process says that in that case you have to at the very least re-estimate. If a ticket is really taking forever, at some point the estimate for the time to finish it will be more than a sprint, at which point you're obliged to split it up.

I'm considering a similar approach with my team. Any specific resources or books or tips you found especially helpful?

We use a similar approach in my company and the key here is to borrow the parts that work for your organization from Scrum and blend them with a much simpler Kanban approach. Don't follow a methodology blindly just because someone wrote a book about it. Keep evaluating & tweaking the process until you think it's at a point where it's working well for your organization.

Reply on news.ycombinator.com