Putting the 'flow' back in workflow with WIP limits

進行中の作業 (WIP) の制限によって進捗が妨げられることはありません。むしろ、その逆です。

Dan Radigan Dan Radigan

What are WIP limits?

In agile development, work in progress (WIP) limits set the maximum amount of work that can exist in each status of a workflow. Limiting the amount of work in progress makes it easier to identify inefficiency in a team's workflow. Bottlenecks in a team's delivery pipeline are clearly visible before a situation becomes dire.

WIP 制限はなぜ重要なのか?

So now you're thinking, "Tell me more!" (Well, I hope you are.)

WIP limits improve throughput and reduce the amount of work "nearly done", by forcing the team to focus on a smaller set of tasks. At a fundamental level, WIP limits encourage a culture of "done." More important, WIP limits make blockers and bottlenecks visible. Teams can swarm around blocking issues to get them understood, implemented, and resolved when there is a clear indicator of what existing work is causing a bottleneck. Once blockages are removed, work across the team begins to flow again. These benefits guarantee that increments of value are delivered to customers sooner, making WIP limits a valuable tool in agile development.  

開発の途中で、こう考えがちです。「そうだ。この課題は一休みして、もう一つの課題に取りかかろう」と。2 つの課題をオープンすると、2 つの異なる事柄の間でコンテキストを切り替えたり、チームの仲間と作業をやりとりすることになります。1 つの課題から別の課題への切り替えは簡単にはできません。それには時間がかかり、集中力が低下します。ほとんどの場合、1 つの課題を開始し、完了しないまま、新しい課題を始めるより、初めの課題の作業を継続した方がよいのです。言い換えれば、WIP 制限は開発者自身がフローを妨げるのを阻止しているわけです。 

最後に、WIP 制限は慢性的な待機状態や過負荷になっている部分を指摘します。これによって、チームは作業を行っている特定の部分だけではなく、プロセス全体の中で効率が悪い部分を知ることができます。

Pro Tip:

For teams new to WIP limits, they will feel awkward. Take the time to discuss them in the first few iterations. Understand when and why the team hit the WIP limits. Resist the temptation to arbitrarily adjust them at first. If a breach becomes consistent, that's a sign that either the WIP limit is too restrictive or the team's process is inefficient. 

アジャイル チームで WIP 制限を使用する

WIP の価値に納得できたところで、具体的な話に入りましょう。

When rolling out a new workflow, make a team decision to determine the WIP limits for each status. We recommend setting WIP limits after monitoring the average number of work items in each status for a few sprints. Below is a sample agile board with WIP limits used by a typical software development team. 

WIP Limits | Atlassian agile coach

Above, a WIP limit has been set on code review. Since the column is exceeding its limit, the background has turned red.

Since there's nothing left to do once an issue reaches done, there is no need for a WIP limit there.In the board above, "Ready for dev" signifies that the story has been fully vetted by the product owner and team. The development team pulls work from "ready for dev" into "in progress" as they start on work items. As a best practice, it's important to keep enough work in the "ready for dev" status so that each member of the development team remains fully utilized. By keeping only just enough stories in the "ready for dev" state, the product owner doesn't get too far ahead of the game when it comes to fleshing out requirements, and the program becomes more responsive to change.

The "in progress" status lists work that's under active development. The goal of WIP limits in this case is to ensure that everyone has work to do, but no one is multitasking. In the board above, the limit for "in progress" items is 4, and there are currently 3 items in that state. This tells the team they've got capacity to take on more work. As a best practice, some teams set the maximum WIP limit below the number of team members. The idea is to bake in room for good agile practices. If a developer finishes an item, but the team is already at their WIP limit, they know it's time to knock out a few code reviews or join another developer for some pair programming.

The "code review" status indicates stories that have been fully written but need to be reviewed before merging into the code base. Timely code reviews are a best practice that establish quality, get new innovation out to market faster, make merges easier by reducing open branches, and spread knowledge across the engineering team. Items in this state should be acted on urgently, for a few reasons:

  • チームのメンバーが新しいコードにとりかかっている間に、コードが陳腐化しないため
  • 開発者が元のコードを書くことで得たコンテキストを失わないため
  • フィーチャーをリリース用のメインブランチにマージできる状態にするため

WIP 制限によって、未レビューのコードが山積みにならないよう保証されます。 

上のアジャイルボードでは、チームが抱えるコードレビュー多すぎるため、列の色がそれを示す赤に変わっていることにご注意ください。

Anti-patterns to watch for:
  • チームが今後 WIP 制限に達することがないように、制限を必要に応じて引き上げている。(「債務上限」ですね、何か他にいい表現は?)
  • 皆が膨大な「バックグラウンド業務」を抱え、仕事のない時間がなくなってしまう。
  • チームメンバーは、ボトルネックに対処せず、何もせずに仕事が入って来るのを待っている。
  • エンジニアリング方式やチームプロセスの改善よりも、いつまでも続くボトルネックにスタッフの時間を投入することが優先されている。 

WIP 制限を使用するアジャイルチームがめざす 4 つの目標

どの新しいアクティビティでも同じように、初めは WIP 制限に落ち着かない感じがするかもしれません。この場合のゴールは中期的にチームを最適化することであり、短期的に落ち着かないのは実際はよいことです。WIP 制限によって、チームはプロセスの間に痛みを感じます。数週間 WIP 制限を使用した後、必要に応じて調整をします。チームが継続的に制限に達しているために WIP 制限を上げたくなる気持ちを抑えてください。この機会をとらえて、作業能力を向上させます。理想的には、チームを教育し、各メンバーに新しいスキルを身につけさせるか、または開発プロセスのいずれかの側面を効率化します。

Goal 1: Size individual tasks consistently. When breaking down requirements and user stories, it's important to keep individual tasks to no more than 16 hours of work. Doing so increases the team's ability to estimate confidently, and it helps prevent bottlenecks. Nothing slows down a team and aggravates WIP limits like a big work item clogging up the pipeline. 

Pro Tip:

When work in progress limits are working for the team, an issue's cycle time will drop. Cycle time is the amount of time it takes to complete an issue. Check out our page on agile metrics to learn more. 

Goal 2: Map WIP limits to the team’s skills. The above example assumes team members have similar skill sets. If your team has specialists on it, work in progress limits may differ when the specialist is involved. Create a status specific for the specialist's work. If bottlenecks occur in that status, use the opportunity to educate other team members to add additional capacity for the specialist's skill sets and increase flow across the entire team.

Goal 3: Reduce idleness. When a team member has some downtime, encourage them to help an upstream or downstream team member. They'll contribute to the overall productivity of the team, and learn something along the way!

Goal 4: Protect a sustainable engineering culture. Work in progress limits do not mean developers need to rush through work to avoid work overload in a particular status. They are meant to support solid agile engineering practices that protect the quality of the product and health of the code base. 

次の記事
Kanban vs scrum