1

Out team is transitioning to a "ScrumBan" way of working. We have set up WIP limits. We have two half-time student workers in our team. This won't change (plus we like them anyways).

The team has correctly stated that work is sitting in columns (eating up WIP limits) on the students' days off. I'm happy that they have noticed this, it shows that the board and WIP limits are helping them see waste.

My question is, what strategies could we employ so that we can reduce this waste of unfinished work sitting in "In Progress" for 2.5 days a week?

  • I'm hesitant to increase WIP, because we shouldn't be starting more work, when there is still unfinished work.
  • I believe there's a simple solution: All Part timers must pair program with full-time developers...all the time. But that seems heavy handed?

I'm looking forward to getting some advice here. Thank you!

Improve this question

3 Answers 3

Reset to default
1

I believe there's a simple solution: All Part timers must pair program with full-time developers...all the time. But that seems heavy handed?

I have worked with teams that pair on all work and it has been highly effective.

The developers will need to think carefully about how they pair to ensure they maximise the benefits of this approach.

There are lots of excellent books and articles that can help you with this, such as On Pair Programming on the ThoughtWorks blog.

Improve this answer
2
  • 1
    I've spoken with the team, and while they've tried this before, and it works to solve the system WIP/cycle time problem, the counter-effect is a poor learning experience for the student. Meaning, the students and the rest of the team believe it would suck if they could never see a task through to the end. Perhaps pairing Mon/Tue works, while shifting focus to doing some quick reviews for the half day Wednesday might work?
    – Aaron Wallace
    Commented Mar 18, 2020 at 12:20
  • Sounds like a sensible approach. As with most things, I would recommend trying it out and then reviewing it after a few weeks to see if it is working for you.
    – Barnaby Golden
    Commented Mar 18, 2020 at 14:12
1

I would like to challenge your assumption that this has anything to do with the WIP-Limit.

Lets say you have 5 full time developers and 2 part time developers. And for starters, you set the WIP limit to 7, so that each can concentrate fully on their one task until it's done.

Whether or not the part timers are there on any given day does not change anything about the fact that the remaining 5 people have a WIP limit of 5. If there is a problem with that limit, it has nothing to do with the part timers being there or not.

The only thing that happens is that the tasks of the part timers have a longer time until they are done.

Now when you tell me that you want the part timers to pair program with the full developers, so basically you want the full developers give a lengthy explanation of all they have done the previous day every other day and then work with a less experienced team member by their side, that looks like a great learning opportunity. But most likely your company does not pay you to teach, it pays you to get tasks done. And from my experience, this kind of pair programming does not get tasks done quickly. The collaboration and communication overhead to synchronize people who aren't there half the time is enormous. I think you should try (that's one point of being agile, right?), but don't be surprised when your full time developers come back and say "listen, we like the students, but we'd be faster if they were not involved at all."

And that would be the point where you return to the system you currently have, with part timers doing their best at their own speed.

Improve this answer
2
  • Good point, this shouldn't effect the rest of the available WIP. I will reflect that back to the group. However, with regard to cycle time for student work vs cycle time for full time work, how would you go about addressing this? There's an automatic 2.5 days added to cycle time of a story each time a student doesn't finish his work. Do we just accept that? Or is there perhaps another strategy lying around for dealing with that?
    – Aaron Wallace
    Commented Mar 18, 2020 at 12:11
  • Well, everything else requires extra communication aka extra work. So you need to decide if your priority is reaction time or throughput. Having tickets wait for days improves the number of tickets you get done because work is done efficiently on every ticket with no overhead, while having someone else pick them up is more work per ticket, but the ticket gets closed faster. There is no silver bullet here, no right or wrong. You need to prioritize one of them and it's up to your organisation which one it should be.
    – nvoigt
    Commented Mar 18, 2020 at 13:25
1

The existing Answers are good, I just wanted to add something on top of them. As you're doing Scrumban, I am assuming/hoping that you are performing the Scrum event known as the Retrospective (often considered to be the single most important part of Scrum).

Therefore, whatever you take away from this, other research, and your own internal musings, I suggest you bring it as a suggestion, not as a decision, to the Scrum Retrospective. Pose the problem to the Team, ask for their thoughts, pose your suggested solution, ask for alternatives, discuss, and then pick an approach that is agreed-upon and has the buy-in of everyone on the Team.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.