[gregmac]

Kanban does sound appropriate, but it seems like the biggest thing still missing is prioritization.

One team = one ordered list of priorities. Someone has to make the call.

It doesn't mean there aren't multiple things happening at the same time, but it does mean there's always one ranked above the other. This is the biggest thing I've struggled with when introducing kanban concepts to non-tech people: they will try to have several #1 priority items - sometimes by having several priority lists or categories that are all "equally important".

Prioritization doesn't have to be perfect, so long as it's continually refined and the priority of items in-progress (almost) never changes. It had to be recognized that stopping work adds several hours to the time it will ultimately take, and doing it more than extremely rarely is a great way to completely destroy your team's morale. Even if it's a "only a five minute task", you have to act like it's a 3 hour drive away (and back again).

[tetha]

>they will try to have several #1 priority items - sometimes by having several priority lists or categories that are all "equally important".

I'm currently struggling with exactly that. We're the ops-team, so the infrastructure itself as well as the upstream applications are capable of producing its own backlog of maintenance work very well (hello SACK). And then you have all kinds of technical tasks to optimize and maintain the infrastructure. On the other hand, Sales, dev and other teams are also throwing project work at us we have to deliver, sometimes on a communicated deadline, sometimes without.

It's a rough balancing act. By now I've split that into two queues, our internal and our external queue. Multiple stake holders can fight about priorities in their external queue, the internal queue is team-internal and backed by our head of IT as a stake holder. From there, we're trying to consume both queues in a fair fashion. It kind of works, but perfect it ain't.

[TravHatesMe]

I agree. In order to optimize efficiency, changing priorities (ie. interrupting work) should be avoided unless absolutely necessary.

A five minute task equates to: context switching, creating a branch in JIRA, checking out the branch, complete this small task with a few lines of code, debug and run tests, create the PR.. It is awfully distracting and I often lose focus on what I was previously working on. Great, I think I'll take a little break or go for lunch a bit early.

[levosmetalo]

Then it’s your process that makes all this overhead. Why not just commit those two lines of code to the main branch and continue?

[TravHatesMe]

Because the process pays off.

If you have a mature code base, all changes should be reviewed by at least one member of the team. Being consistent with your branching process is important. I favor squash-merging pull requests to keep a clean history of the target branch, it makes it easy to track down bugs.

In my mind, this development process, as tedious as it may be, is worthwhile. In my mind it is the proper way of managing a codebase, I consider it part of the job.

[wool_gather]

Because when the two lines of code are the wrong thing and nobody notices the problem with them for five weeks, you're going to spend much much more than that overhead tracking it back down and fixing the original issue properly.