Note

This web presentation is localized to display Japanese and English in parallel. Use the flags to toggle between the two languages. It also supports touch-screen devices for navigation - try it out!

Agile Technical Support was originally published as a White Paper, available here.

備考

このプレゼンはバイリンガル・フォーマットでできています。旗マークのクリックで同じスライドの英語版が見れます。

プレゼンは[ Agile Technical Support ] という英語版の白書から取れています。全文をご覧になるには、このリンクでアクセスしてください。

Executive Summary

Businesses transform to become more Agile in software development. Here are some tips toward applying the learnings to a technical support / operations team. Emphasis points of this paper:

1. Demonstrate how Agile fundamentals can be used in a support team
2. Outline the Support Ticket Life Cycle, a useful framework for Agile, ITIL, and the support charter
3. Provide best practice recommendations

要約

ソフトウェア業界では、アジャイル手法を導入して、開発を磨き上げたい企業が多いです。 このプレゼンでは、テクニカルサポート/運用チームが適用できるノウハウを伝えます。 主な内容は次のようになります。

1. アジャイルの基礎がサポートチームに適用される例
2. アジャイルやITIL に便利な枠組みとして、"サポートチケットライフサイクル"を紹介します。
3. ベストプラクティスを紹介します。

Some Conclusions

1. Seeing and reducing work in progress (WIP) are keys
2. Outlining and understanding the Support Ticket Life Cycle in your organization helps focus
3. Quality isn't sacrificed
4. Every ticket is a story
5. Assign a project manager for each story across the full life cycle

主な結論

1. WIP(工程仕掛)の監視、削減がカギ
2. サポートチケットライフサイクルの把握が焦点を当てるに役立ちます
3. 品質を犠牲にすることになりません
4. サポートチケットがストーリーとして扱えます
5. ライフサイクル完結までチケット毎のプロジェクトマネジャー役割を任せます

Agile Throughput Improvement

We regularly recorded improvements exceeding 10x in this metric. Comparisons exceeding 50x were also not rare. Overall, the benchmark averaged about 16x - we were 16 times better on this metric after our process changes.

The definition and calculation of this metric can be found in the White Paper: available here.

アジャイルスループットの改善

"アジャイルスループット"という指標に10倍を超える大きな改善を記録しました。 時々50倍を超えるケースもありました。改善の結果は、合わせて16倍ぐらいスループットの改善ができました。

この指標についての詳細はWP全文に載っていますので このリンクでアクセスしてください。

Time to Resolve Improvement

The time to resolve tickets, or cycle time, was in aggregate almost twice as fast: improvement occurred in the ratio of 7 to 3.65 (avg. days to resolve a ticket)

TTRの改善

チケット解決までの時間=いわゆるサイクルタイムは合計二倍弱の速度が出せました。以前7日間だったサイクルタイムを3.65日間でできるところまで改善しました。

How we became Agile

As the company was rallying to become Agile in developer teams, there were resources available to learn.

Even as part of the support team in operations, outside the flurry of Agile transformation, it looked like there were practices we could apply.

The most significant of these was Little's Law.

Originally published by John D.C. Little (1961): “A Proof for the Queuing Formula: L = λ W”, Operations Research, Vol. 9, No. 3.

アジャイル手法への道

会社が開発チームの改革を計っている間、勉強できる教材がありました。

アジャイル改革の対象外でありながら私たち運用チームもベストプラクティスをいくつか探し出しました。

この中、最も重要なのはリトルの法則でした。

　John D.C. Little氏 (1961出版): "“A Proof for the Queuing Formula: L = λ W”", Operations Research, Vol. 9, No. 3.

Little's Law background

Little's Law states that

“The average number of customers in a system (over some interval) is equal to their average arrival rate, multiplied by their average time in the system.”

Also, for the law to hold, the values must represent long-term averages of a stable system.

リトルの法則・背景

リトルの法則によりますと

“待ち行列理論において 平均化した顧客数は、平均化した到着率と、平均化した顧客が系に費やす時間の積に等しい”

この法則に必須条件は安定な系と長時間平均化した統計です。

Little's Law outline

The equation, originally L equals lambda W, is also commonly rewritten in the form [ WIP = TH * CT ].

リトルの法則・公式

この方程式、L = λ W は WIP = TH * CT という表し方もあります。

Applying Little's Law

Over the years, it has been applied in operations management settings, including factory operations. And for software development in Agile "kanban" systems.

With technical support issues, reducing cycle time is what customers push for - resolving their tickets faster.

To improve cycle time, only two approaches can be taken:

to increase throughput

to reduce work in progress

リトルの法則の適用

長年にかけて運用管理や工場運用に適用されています。 ソフトウェア開発のKanbanシステムにも有名になって来ました。

テクニカルサポートの仕事では、サイクルタイムの削減、つまりチケットの迅速な解決、はお客様にとって大事な要求です。

サイクルタイムの改善方法として、ただ二つの選択肢があります

スループットの向上

WIP (work-in-progress)の削減

Reducing WIP in Tech Support

Even without Scrum or kanban, we can still do something: we can reduce WIP!

Something we borrow from Agile: visualization of work. We make sure we have tools to view our work and our WIP (how many tickets each of us owns at a time).

With multiple tickets owned, and only one being worked on at any time, work is inefficient: time owning tickets runs away from time working on tickets.

テクニカルサポートにおいてWIPの削減

スクラムやKanbanシステム以外にもWIPの削減は一つの手です。

アジャイルのベストプラクティスを取り入れて: 作業内容の見える化。見える化に便利なツールと習慣を確保しておきます。

チケット作業を一つずつしか進ませないので、WIPが高い限り、チケットの合計アイドルタイムが速い、効率が悪いです。

Little's Law Task Sequence

Top sequence = 3 tasks in process at any time, and the throughput is 1/3 of a task per hour. Per formula, WIP = TH * CT [ 3 = 1/3 * 9 ].

Bottom sequence has reduced WIP = 1 task in process, and the throughput is 1/3 of a task per hour (same as above). Per formula, WIP = TH * CT [ 1 = 1/3 * 3 ].

リトルの法則・タスクシーケンス

上のシーケンス: WIP = 3; スループット = 1/3 (タスク/時)。 方程式により、WIP = TH * CT [ 3 = 1/3 * 9 ]。

下のシーケンス: 　WIP = 1; スループット = 1/3 (タスク/時)。 方程式により、WIP = TH * CT [ 1 = 1/3 * 3 ]。

Reduced WIP Summary

As shown in the task sequence diagram, the same throughput yields widely different cycle times as Work in Progress varies.

To improve cycle time for technical support:

• increasing throughput may not be as viable in the near term.
• reducing work in progress is quick, reliable, and predictable.

WIP削減のケース : 解説

前ページのタスクシーケンスからわかる通り、スループットが同じ作業で、WIPの値がサイクルタイムを決めています。

テクニカルサポートにおけるサイクルタイムの改善方法として、

• スループットを向上させるは手近ではありません
• WIP の削減はすぐ予想通りの結果を出せます。

Waste in Workflow: Context Switching

Matt Stine gives an excellent description of context (or task) switching for Digital Zone:

“Of all of the wastes confronting us as software developers, this one is perhaps the deadliest. Deep concentrated thinking is required for even minimum effectiveness as a software developer. Interruptions are the ultimate enemy of deep concentrated thinking, and any task switch constitutes an interruption.”

Any opinions about how much context switching affects an operations team? (as opposed to developers)

業務での浪費 - コンテキストスイッチ

コンテキストスイッチについて、Digital ZoneにMatt Stine 氏がこう語りました。

“ ソフトウェア開発者にとって、いろいろな浪費の中で、これが一番痛いです。効率を維持するため、集中し続けることが必要です。集中の巨大な敵は邪魔されることだといえます。コンテキストスイッチは単なる邪魔されることです。”

運用チームの場合、コンテキストスイッチは同じような巨大な敵でしょうか。

Context Switching Task Sequence

Here are examples of workflow sequences where there is some context switching between tasks. This is just for illustration, but in practice we could usually measure the cycle times and use the data to determine the throughput.

コンテキストスイッチ・タスクシーケンス

今度のシーケンスは、コンテキストスイッチも表しています。 実際には、ワークフローを測って、サイクルタイムとWIPがわかって、スループットを計算することができます。

Context Switching Sequence Analysis

Referring to the sequence diagrams in the previous slide, we can apply Little's Equation and derive throughput.

• Top sequence (3 tasks in process).
  • [ TH = WIP / CT ] => [ TH = 3 / (~12) ].
  • Little's Equation gives throughput about 0.25.
• Bottom sequence (WIP 1).
  • [ TH = WIP / CT ] => [ TH = 1 / (~3.5) ].
  • Little's Equation gives throughput about 0.286.

There is some measurable throughput degradation associated with more context switching.

コンテキストスイッチのケース : 解説

前ページのタスクシーケンスとリトルの公式を使って、スループットを計算します。

• 上のシーケンス: 　WIP = 3;
  • [ TH = WIP / CT ] => [ TH = 3 / (~12) ]
  • スループット = ~0.25
• 下のシーケンス: 　WIP = 1;
  • [ TH = WIP / CT ] => [ TH = 1 / (~3.5) ]
  • スループット = ~0.286

コンテキストスイッチはスループットに悪影響を及ぼすことがわかります。

Reducing Context-Switching Effects

As shown in the combined task sequence diagram, throughput is impaired by task switching. Higher WIP not only increases cycle time directly as Little's Law describes, it also decreases throughput due to task switching waste.

To improve cycle time for technical support:

Reducing WIP improves cycle time directly as Little's Law describes.

It also improves cycle time indirectly - fewer task switches results in less waste, higher throughput.

コンテキストスイッチの影響を抑える

スループットはコンテキストスイッチにより阻まれます。リトルの法則が説明していることは高いWIPがサイクルタイムを悪化させます。しかし、もう一つの効果があります。 高いWIPに伴うマルチタスクワークフロー自体がコンテキストスイッチの浪費を増やしています。この浪費がさらにサイクルタイムをを悪化させます。

テクニカルサポートにおけるサイクルタイムの改善方法として、

WIP の削減は直接効果があります。

その上、コンテキストスイッチを減らすから間接効果もあります。

Other Agile Practices

It never made sense for us to fully adopt a Scrum or Kanban methodology, but still we were free to consider Agile practices to find those which worked best for us.

Here are some which we used:

• use case concept: incoming tickets are viewed as user “stories”
• standardized naming schemes
• standardized styles and formats of tickets
• shared efforts (a little in the direction of pair programming)
• customer proximity (included in communications)

他のアジャイルベストプラクティス

テクニカルサポートの立場には、スクラムやKanbanシステム全体の導入より、その中のベストプラクティスを一つ一つ試して、検討して、採用することにしました。

例として、使ったことは

• サポートチケットをストーリーとして扱います。
• 名づけルールの標準化
• チケットのフォーマット、内容の標準化
• ペアプログラミングのような協力
• 顧客との近接な関係

Change is Constant

Our team was small and faced constantly changing requirements.

Primarily, there were continuous changes in the volume and priority of tickets, to which we would regularly need to adjust.

変化が多いワークフロー

小さなチームで常時に要求が変わってきていました。

主には、チケット量とプライオリティの変化が多い状況でした。

The Support Ticket Life Cycle

The White Paper contains a full outline of the life cycle. It follows these main phases:

• Pre-support
• Support
• Post-support
• Meta-Support (includes actions occurring across phases)

サポートチケットライフサイクル

白書にはライフサイクルの詳細が書いてあります。 主な段階はこの四つあります

• サポート前
• サポート
• サポート後
• メタ-サポート

Complexity of the Life Cycle

The cycle of a technical support issue can often be more complex than factory production because the flow of any issue

• does not have a standard, consistent series of steps
• does not need to go the same direction – it can flow backwards
• may have numerous interruptions
• may be subject to time limits of a Service Level Agreement (SLA)

So the "production line" analogy does not hold.

ライフサイクルの複雑性

一つのチケットの流れは工場生産より複雑になることもあります。この流れは

• 決まった順番には必ずしも進みません。
• 決まった方向には必ずしも進みません(逆の可能性もあります)。
• 遮断されることもあります。
• SLA (サービス レベル契約)により時間が制限されることもあります。

Managing Life Cycle Complexity

How did we manage the complexity?

First, we did not set any hard limit to WIP.

We knew that a low WIP is ideal, but faced a reality check: we needed to be flexible to "pushed interruptions".

複雑性の管理

どうやって複雑性の管理ができましたかというと

まず、WIPの制限は設定しませんでした。

WIPの低いほうがいいと知りながら、急な要求を柔軟に対応できることが不可欠です。

Little's Law at Different Levels

From a customer's point of view, the most important level is the Life Cycle to the point "Release of the fix."

We instituted a project manager approach to every story because the customer's point of view was not getting enough traction. In "production line" mode, some support tickets would get ignored.

The tickets that flow into a backwater are essentially all additional WIP in the big picture.

段階別のリトルの法則

顧客の立場から見たライフサイクルの最も重要な段階は修正リリースまでの分です。

ただ、この立場は十分に注目されていませんでした。 チケット毎のプロジェクトマネジャー役割を取る制度はこれの対策でした。 以前のプロジェクトマネジャー無しワークフローでは、チケットが無視されてしまうことがありました。

無視されてしまうチケットがすべて無駄なライフサイクル規模のWIPになるのです。

Project Managers of Every Story

Agile Technical Support becomes more than just a step on a production line.

In addition to keeping low WIP at the team level, the expanded role that our team took on was to manage tickets across the entire Life Cycle. We wouldn't let them be ignored.

This helps keep WIP low at the full Life Cycle level, and improves cycle time.

チケット毎にプロジェクトマネジャー役割

アジャイルテクニカルサポートは役割が広がります。

小規模のWIPによって効率維持しながら、ライフサイクル規模でプロジェクトマネジャーの役割もしました。浪費を防ぐよう気を付けていました。

これにより、ライフサイクル全体規模のWIPも低く維持できて、全体のサイクルタイムも改善できました。

Team Productivity

We measured cycle time at the story level, at the individual level, and at the team level.

Previously, "greedy multitasking" was the norm. When too much attention is given to individual work loads (by managers evaluating performance, for example), or in times when support capacity doesn't meet the customer demand for support services, team throughput can suffer. For us it took this form I called greedy multitasking.

チームの生産性

サイクルタイムをいくつかの単位で測っていました: ストーリー、個人とチーム単位。

以前のパターンは貪欲にマルチタスクしていました。 個人の作業量が重視され過ぎている時や顧客からのサポート需要がキャパシティを超える時、チームのスループットは低下しがちでした。 このことを"貪欲にマルチタスクする"と名づけました。

Team Work in Progress - "TWIP"

There are three reasons why greedy multitasking is not Agile:

1. Little's Law applies and multitasking equates to higher WIP.
2. Context switching costs apply whenever there is multitasking.
3. Team throughput may also be impacted.

Team Work in Progress means neither greedy nor multitasking. And it brings other benefits to managers, including resource scaling and better decision metrics.

TWIP - チーム・ワーク・イン・プログレス

"貪欲にマルチタスクする"ことはアジャイルではない理由は三つあげられます。

1. リトルの法則によるとマルチタスク自体が高いWIP という意味です。
2. コンテキストスイッチの浪費が増えます。
3. チームのスループットは低下してしまいます。

チーム・ワーク・イン・プログレスというのは貪欲ではなくて、マルチタスクもしません。逆に、マネジャーには数値の見える化などの価値をもたらしています。

Project Managing Stories

Some suggestions for project managing in the Agile Tech Support way (each ticket / story is a project):

• When possible, do not push interruptions. It can cause high context switching costs to engineers.
• Walk a fine line in managing stories.
• Avoid pushing interruptions, while on the other hand do not let stories stagnate.

チケットのプロジェクトマネジャーにヒント

アジャイルテクニカルサポートのヒントは次のようです。

• 開発者に邪魔しないように気を付けましょう。コンテキストスイッチのコストが掛ります。
• 無視されてしまったチケットを片付けて、きちんと進ませましょう。

Keys to Success

The following are some of the lessons learned from experience:

• Kaizen / Continuous improvement. Innovate over the process, keep what works.
• Customer feedback
• KPIs. If the value of some data outweighs the cost, then make the effort to get it.
• Rewards. To motivate and guide, avoid inconsistencies between the team charter and the individual reward structure.

成功へのカギ

経験から得られた知識を共有すると

• 改善、試行錯誤の繰り返し
• 顧客からのフィードバックを聞いて
• KPIs : データの価値が十分ある場合、手に入れるコストがある程度あっても、取った方がいい
• 報酬 : 動機と方向を上手くつけるため、個人の報酬基準とチームのワークフローに矛盾がないように

Conclusions

Agile transformation continues to improve development in the software industry.

1. But Agile practices have apparently not influenced technical support organizations much yet.
2. Agile practices should improve throughput and cycle time without affecting quality.
3. The end result is increased value to customers.

結論

ソフトウェア業界では、アジャイル改革で、開発が改善され続けています。

1. しかし、テクニカルサポート/運用チームはそのほど改革の対象ではないようです。
2. 品質を維持しながら、スループットとサイクルタイムの改善方法があります。
3. 顧客へ付加価値に提供できます。