Agile Technical Support

Optimizing Across the Support Ticket Life Cycle

by Leo Ramos
August 2014

Agile Technical Support


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



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

go to English
Agile Technical Support

Executive Summary

Winged Victory

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
Agile Technical Support


Winged Victory

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

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

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
Agile Technical Support


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

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.

Faster, Better
Agile Technical Support


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

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

Faster, Better
Agile Technical Support

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)

Faster, Better
Agile Technical Support



Faster, Better
Agile Technical Support

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.

Agile Technical Support





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

Agile Technical Support

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.

Agile Technical Support



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


Agile Technical Support

Little's Law outline

Little's Equation

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

Agile Technical Support


Little's Equation

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

Agile Technical Support

Applying Little's Law

Agile Forces

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

Agile Technical Support


Agile Forces

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




WIP (work-in-progress)の削減

Agile Technical Support

Reducing WIP in Tech Support

Measurement and Control of WIP

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.

Agile Technical Support


Measurement and Control of WIP


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


Agile Technical Support

Little's Law Task Sequence

Sequence showing reduced WIP effects

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 ].

Agile Technical Support


Sequence showing reduced WIP effects

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

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

Agile Technical Support

Reduced WIP Summary

Agile Forces

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.
Agile Technical Support

WIP削減のケース : 解説

Agile Forces



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

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)

Agile Technical Support

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

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

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


Agile Technical Support

Context Switching Task Sequence

Sequence showing negative impact of context switching

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.

Agile Technical Support


Sequence showing negative impact of context switching

今度のシーケンスは、コンテキストスイッチも表しています。 実際には、ワークフローを測って、サイクルタイムと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.

Agile Technical Support

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


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


Agile Technical Support

Reducing Context-Switching Effects

Agile Forces

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.

Agile Technical Support


Agile Forces

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


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


Agile Technical Support

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.

Agile Teamwork

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)
Agile Technical Support



Agile Teamwork


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

Change is Constant

Our team was small and faced constantly changing requirements.

Agile for Change

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

Agile Technical Support



Agile for Change


Agile Technical Support

The Support Ticket Life Cycle

Agile Forces

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)

Agile Technical Support


Agile Forces

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

  • サポート前
  • サポート
  • サポート後
  • メタ-サポート
Agile Technical Support

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.

Agile Technical Support



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

Managing Life Cycle Complexity

Agile 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".

Agile Technical Support


Agile Complexity




Agile Technical Support

Little's Law at Different Levels

Faster, Better

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.

Agile Technical Support


Faster, Better


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


Agile Technical Support

Project Managers of Every Story

Faster, Better

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.

Agile Technical Support


Faster, Better




Agile Technical Support

Team Productivity

Teamwork in Progress

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.

Agile Technical Support


Teamwork in Progress

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

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

Agile Technical Support

Team Work in Progress - "TWIP"

Teamwork in Progress

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.

Agile Technical Support

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

Teamwork in Progress


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


Agile Technical Support

Project Managing Stories

Teamwork in Progress

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.
Agile Technical Support


Teamwork in Progress


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

Keys to Success

Agile Teamwork

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.
Agile Technical Support


Agile Teamwork


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


Winged Victory

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.
Agile Technical Support


Winged Victory


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


By Leo Ramos

leoramos, August 2014

Agile Technical Support is available as a 24-page White Paper, available here.

Return to Kimari web site here.