Paulo, Agile Coach. âCycle time and ... While browsing around our agile project management tool's help, I .... We cont
PERSPECTIVES
Continuous Improvement How Cycle time can help you deliver faster
Share this ebook.
Contents Introduction
3
Cycle time 101
4
Cycle time in practice
5
Cycle time and Little's Law -- Paulo Caroli
6
Cycle time for Continuous Improvement -- Kevin Kriner
8
Whittling our wall to reduce cycle time -- Melissa Doerken
11
Trailing indicators good. Leading indicators better -- Scott Turnquest
13
In Summary
16
About the authors
17
Be in this ebook
18
© 2013
Share this ebook:
2
Cycle time as a catalyst for Continuous Improvement Great teams are constantly striving to improve the way they work in order to innovate and deliver faster. When teams reflect on their process today, their conversations are largely qualitative and rely heavily on intuition. While intuition is good, having meaningful, actionable data can help teams make better decisions about what and how they can improve than they would by intuition alone. Ethan Teng, Product Manager, ThoughtWorks
Cycle time is one of the most important and helpful metrics for teams who are striving to continuously improve. While cycle time has been used in traditional manufacturing industries for decades, software teams are now starting to use it to identify ways to improve their process and deliver faster. In this ebook, we will discuss what cycle time is and how it can help your team improve faster.
© 2013
Share this ebook:
3
Cycle time 101 What is Cycle time?
How does Cycle time help?
Cycle time is a simple but powerful metric. It
When looked at in aggregate and across time,
is the measure of the elapsed time from the
cycle time reveals how smoothly work is
moment you start working on an item (story,
flowing through your development process,
task, bug, feature, etc.) until it is done.
helps you spot bottlenecks and see the effects
Different teams will use different definitions for “start” and “done”. Teams often mark “start” as the time when the team starts
they have on your delivery. It provides the insight you need to make improvements and deliver faster.
working on an item including analysis and “done” when it is signed off by the stakeholder, or pushed to production.
© 2013
Share this ebook:
4
Cycle time in practice
© 2013
Share this ebook:
5
Little’s Law
“Cycle time and Little's Law” Applying Little's Law to track cycle time
constant: 12 bottles. Per year, I finish an average of
“The average number of work items in a stable system is equal to their average completion rate, multiplied by
6 whiskey bottles. So, what is the average time for a whiskey bottle in my bar?
their average time in the system.” - John Little, 1961
Let’s apply Little’s Law
By solving this simple first equation you are able to
Average number of work items in a stable system =
find out the average time for work items in your
Average completion rate X Average time in the system
system. My whiskey bar provides us a great stable system example to illustrate how you can apply Little’s law to track the average cycle time.
Using my bar terms: 12 bottles (number of whiskey bottles in my bar) = 6 bottles / year (average completion rate) X
My whiskey bar
Average time in my bar (cycle time) Therefore, the average time a whiskey bottle stays in my bar is 2 years. Give it a try! Go ahead and apply Little’s Law formula to your stable system. Given the average work items in the system (WIP) and the completion rate (throughput), you can derive the average time in the system (cycle time). So what makes my bar a stable system?
Paulo, Agile Coach
Basically two guiding rules make my bar a stable system: WIP limit and Pull System. As is apparent, I only drink whiskey (the left side of the bar is my wife’s). Whenever a bottle finishes, I remove it from the bar. Then I open a new one, and add it to the bar. My bar is a stable system: the rate at which whiskey bottles enter the bar is the rate at which they exit. Only 12 bottles can fit.
1. WIP limit WIP is the number of work items in my system. In my bar example it is the number of whiskey bottles on the bar. Bottles that have been opened, but are not finished yet. The WIP limit on my bar is 12 bottles because that's all I have space for.
The number of whiskey bottles at my bar is
© 2013
(continued...)
Share this ebook:
6
(...continued)
“Cycle time and Little's Law” Applying Little's Law to track cycle time
2. Pull System
Can I use Little's Law to determine how much WIP
Pull System describes the movement of work items
my team can handle, or what my average
driven by actual demand. In my bar example, a
throughput needs to be - if I know my average
bottle that is finished opens a spot on my bar,
cycle time?
thereby creating a demand for a new bottle to be
Sure thing. If you are on a stable system and you
opened and placed at the bar. Essentially, the
know your average cycle time, then you can
movement of work items (whiskey bottles) is driven
definitely play with Little’s law. You just have to be
by actual demand: a finished bottle is removed
careful not to overdo it, especially for software
from the bar, opening space for a new one that is
delivery systems. They are empirical and there are
promptly added to the bar, occupying the vacant
several other things to do in order to reduce
space.
variability in software delivery.
FAQs: What if I do not have a stable system? I would recommend trying and becoming a stable system. If the system is not stable, you will either starve for work, or have an overflow (with increasing cycle time).
© 2013
Share this ebook:
7
The Story
The chart generated showed the mean, standard
About 25 iterations ago (in our team’s 8th iteration
deviation, minimum, and maximum of the data set.
“Using Cycle Time for Continuous Improvement”
and about 4 iterations after we first started talking
Each point indicated the time that the card (story
A walk through of how cycle time helped us track our progress
delivery process, so I wanted to share them.
about capturing these metrics!), our team began
or defect) spends in each status as well as the cycle
capturing and using a couple metrics for our own
time.
continuous improvement. These metrics have
The visualization was not bad, but for our
proven to be very useful in helping us improve our
continuous improvement, I really wanted the data for each story or defect. Also, I was interested in tracking elapsed time in all states, so we could see
Our Goals 1. To capture actual data about how our process is running. 2. To provide a baseline for continuous improvement of our software development
bottlenecks, compare times across stories with the same points, and use that information to see if any of those times represent problems that we want to address.
process.
So, I used Microsoft Excel™ to track that data, and
3. To use this data to help find problems, find out
would also write it up on our physical board along
the root cause of those problems, and determine/
with a chart. We used this data as input into our
implement countermeasures so the problems
weekly retrospectives to help improve our
won't happen again.
process. I usually mark minimum / maximum times in each state, minimum / maximum cycle time, and
Kevin, Lead Consultant
Cycle time and time each story/defect spends
highlight anything else that looks odd, interesting
in each state
or worthy of the team’s discussion.
While browsing around our agile project management tool’s help, I chanced upon a chart for cycle time of our stories. The chart could be automatically generated from data captured about our stories and defects. The tool defined "cycle time" as the elapsed time (measured in days, including weekends) between the states of In
Note, the Ready for QA column is not yet used; as that is not yet a state in our tool. I'd like to have the state there so I can distinguish between In Progress and waiting to be tested to see if queuing happens, since our constraint right now is our number of Quality Analysts (QA) - we need more!
Progress and Done. (continued...)
© 2013
Share this ebook:
8
(...continued) So, we completed our iteration and captured cycle
a. Story #164 has 0 days In Progress, 5.1 days in
time (the duration of the elapsed time between
“Using Cycle Time for Continuous Improvement”
Validation/QA, and 3 days in Sign Off.
when a story is In Progress until that story is Done)
A walk through of how cycle time helped us track our progress
b. Story #173 has 1.1 days In Progress, 7 days in
metrics for all stories that we've completed (status
Validation, and 0 days in Sign Off.
= Done), and we looked at the results to see how we
i. Why did Validation take 7 days? In this case, not
did. Here's an example of how this cycle time data
only did it include a weekend, but the QA
could possibly be used for continuous
stories queued up as we had more stories in
improvement during a retrospective:
QA than we had QA capacity. We might consider setting Work In Process limits here,
Facilitator: “How did we do this iteration? Are there
and using our Developer for the QA pair to help
any problems? Are there any opportunities for
develop acceptance tests to get the stories
improvement?
done sooner.
I notice that stories #164 and #173 in the grid
ii. Why did Sign Off take 0 days (less than 1/10 of a
above have different elapsed times in different
day, about 2.5 hours)? Because we have a desk
states, but they have the same cycle time of 8.1
check with a QA, Developer, and the Product
days. Let's compare the stories:
Manager (PM) to get from Sign Off to
1. Both are sized at 4 story points.
Done. Most of our sign offs take less than 2.5
2. Both have a cycle time of 8.1 days.
hours; only a handful take more. If they do take
3. Each has different amounts of time in each state
more about a day, it usually indicates some
that add up to that same 8.1 days. I'd start here.
problem or perhaps a QA or PM is on vacation.”
4. What's different between the 2 stories? Status in Days
164
72
27.9
0
2
42.1
In Progres s 0
173
51.9
3.8
3.8
2.2
42
1.1
TBD
7
0
8.1
4
113
108.9
28.3
46.8
17.2
17.8
2.2
TBD
4.1
1
7.2
2
168
61.9
24
0.2
4.5
27
0.3
TBD
2
4
6.2
2
175
47.1
0
1.8
0
45
0
TBD
2.9
0
2.9
1
Story Backlog None
Huddle Ready Prep Huddling to Play
Ready for QA
Validatio n /QA
Sign Off
Cycle Time
Story Points
TBD
5.1
3
8.1
4
(continued...)
© 2013
Share this ebook:
9
(...continued)
“Using Cycle Time for Continuous Improvement” A walk through of how cycle time helped us track our progress
A common comment I hear from folks about this
new story huddle process). We are able to
time in the discussion is, “We don't really have
compare cycle time data collected from stories
enough data to start determining patterns or to be
before the change and after the change, and give
predictive”. We have found that we don't need
feedback to the folks who required us to use this
data that is statistically significant to do
new process.
continuous improvement. We're not trying to predict the future or forecast, we're just trying to see if we can improve our process. Benefits of the data above: 1. We can speak confidently about our process. When someone who is responsible for signing off on stories before they are done says, "It takes too long to develop these stories", we can respond
3. Also, since we have been taking care to use the scientific method, we find that we can try just about any change to our process within reason, even changes that are still not common practice in the organization because we can try them as an experiment for one iteration, then analyze what happened, and change back if needed. 4. When we have data to support what we see,
and say things like, "On average, it takes 5 days to
and the data indicates a problem, that problem is
develop our 4-point stories; however, we noticed
not just my problem as the Iteration Manager,
that it takes an average of 3 days for Sign Off -
but rather the whole team becomes engaged in
why is that?" It is amazing to me the statements
trying to solve the problem.
that are made with no data to support them, and we can quickly cut through statements like these with data.
This collaborative problem-solving and experimentation is the foundation of continuous improvement, and capturing cycle
2. If we take care to use the scientific method, using hypotheses from our retrospectives about
times is one of the most effective ways to get started!
what will happen if we change one thing, each iteration becomes an experiment. We gather the data, analyze the results, and draw conclusions about cause and effect, and see what happens. This allows us to determine the effect of changes we are required to make (such as a
© 2013
Share this ebook:
10
“Whittling our Wall” And how it helped improve cycle time
Continuous improvement is paramount to
However our Quality Analysts (QA) noticed a bit of a
consistently delivering real value to our customers.
bottleneck around them -- the sign-off lanes were
We invest in it heavily to minimize waste and always
increasing our cycle time.
look for opportunities--both large and small--to improve how we work.
Since the Business Analysts (BA) were responsible for signing off stories, but were often busy with
A recent example of how we’ve improved our
analysis, the QAs had to wait to test stories until the
process has been whittling and “WIP-ing” our wall.
BAs pushed them through. To remove this blocker,
And it all began with a call to action by what had
the QAs suggested removing the “formal” sign-off
become our “weighted” wall. A couple of months
lanes. After talking about the change, we decided to
ago, we had an impromptu conversation about our
couple sign-off with desk checks, which we were
card wall.
already doing, but were now held more
We had two lanes: Ready for Sign-Off and Sign-off in
accountable for.
Progress, which was one way we tried to reduce
Spurred by this whittling, we removed other
churn around development and testing, and to limit
unnecessary lanes and later increased our parking
the number of sign-off issues.
lot space to create a “poor man’s” WIP limit.
Melissa, Business Analyst
Developers would move stories to “Ready for Sign-‐off,” where they would sit until...
...BAs pulled them into “Sign-‐off in Progress” to make sure they were reviewed and in good shape for testing.
(continued...)
© 2013
Share this ebook:
11
(...continued)
“Whittling our Wall” And how it helped improve cycle time
Together, these trimmings helped us reduce cycle
We continue to review our process during bi-weekly
time by removing bottlenecks and focusing our
retrospectives, but believe that spontaneous self-
efforts on active work items only. It also allowed us
assessments are equally important and impactful in
to consolidate our wall from two boards to one
our efforts in continuous improvement. It helps us
(below), which effectively reduced the noise in our
build trust among our team and with our customers
workspace. Our previously “weighted” wall had
and are always looking to how we can bolster our
successfully signaled us to re-evaluate our process.
process and our product.
It prompted a conversation that narrowed our focus to more effectively--and efficiently--deliver value.
© 2013
Share this ebook:
12
Continuous improvement and product flow are
these changes helped improve our flow, but to be
popular themes on our product (Mingle, an agile
sure we took a look at our actual cycle time to see
“Trailing indicators good. Leading indicators better?”
project management tool) development team.
if what we felt was true. We used the new cycle
Both internally as we reflect on our own
time analysis feature in Mingle to confirm what we
development practices, and externally as we build
suspected: our cycle time did improve.
Insight into how both can help track progress and preempt bottlenecks
into ways we can improve, we’ve started to
an agile project management tool that helps teams collaborate and improve together. To help us better understand our flow and gain more insight
As the image below shows, in the period from October through November, our average cycle time crept above 20 days before we made changes to our process. After we streamlined our wall, our
incorporate cycle time into team conversations.
wait time was reduced and our cycle time fell
A few months ago, we rearranged our process and
below 10 days.
our card wall to improve our flow. We sensed that
Over 20-‐day cycle time prior to making changes to our process
Reduction in cycle time corroborates the improvements in our process
Scott, Delivery Manager
(continued...)
© 2013
Share this ebook:
13
(...continued) Of course to get a full picture to feel confident of
We can respond faster to events that will affect our
“Trailing indicators good. Leading indicators better?”
our changes we also verified that our throughput
flow by looking for those things that would affect
and work load remained about the same during
cycle time. Using a leading indicator in conjunction
the period over which our cycle time was
with cycle time would help us improve even faster.
Insight into how both can help track progress and preempt bottlenecks
we’re not looking for statistically significant results.
reduced. This wasn’t a rigorous scientific experiment as We’re only looking for a signal that the actions we’ve taken have helped us only looking for a signal that the actions we’ve taken have helped us improve and based on our needs we have enough evidence to justify making our process changes permanent. Understanding our cycle time is thus a useful method in our continuous improvement efforts.
Monitor your queue size A key leading indicator for flow is queue size, which provides early signs that we may have problems with the flow of work through our process. A queue size that’s growing is an indicator that we’ll have problems that will be revealed later through higher cycle time. Where the queues are Unlike manufacturing in the physical world, software doesn’t have physical inventory stacking
Trailing indicators good. Leading indicators better. We’ve seen how incredibly useful cycle time is when looking back to make observations about how past changes affected the flow of work through our development process.
up on palettes or clogging a conveyor belt, making it more difficult to see the “invisible” incomplete product inventory building up. Instead of physical products, we can use stories as evidence of our work in process (WIP) and we can look at the number of stories in a particular phase of development as the queue size.
However, since cycle time involves looking into past performance (trailing indicator), it doesn’t give us real-time feedback when we’re facing problems in our flow today. To identify and fix issues going on in the development process right now, we need a leading indicator. (continued...)
© 2013
Share this ebook:
14
(...continued) For example
Cycle time or queue size? Use both.
“Trailing indicators good. Leading indicators better?”
Consider the card wall below. Each column
It’s probably natural at this point to question
represents a queue and what we see is that the Do
whether we should bother with trailing indicators
queue is much larger than all other queues. If we
like cycle time at all. Monitoring cycle time and
know that our Do queue normally consists of only 3
queue size are both useful, just for different
stories, then the fact that the number of stories in
purposes. If you’re interested in learning how well
this queue has jumped to 7 may be a sign that we’re
work flows through your process so that you can
Insight into how both can help track progress and preempt bottlenecks
having a problem in our delivery process. There
provide forecasting or learn whether previous
could be any number of reasons for the increase in
improvement efforts have been successful, then
the queue but the main takeaway should be that
cycle time measurements are great. However, when
something may be wrong and we should look to
you’re interested in heading off potential issues
address it now rather than wait for the delay to
with your product flow you should consider using a
show up in our cycle time.
leading indicator like queue size. I recommend using them in conjunction with each other.
The growing queue size of the “Do” queue is a leading indicator of potential problems that would later be revealed through high cycle time (continued...)
© 2013
Share this ebook:
15
In summary Cycle time is a useful metric to provide informed insight into the progress of your development process. Use the cycle time data collected to trigger and inform conversations with the team and customer about improving and streamlining your process. Choose from various ways to calculate it, or integrate it in your development process with a tool that analyzes cycle time. Keep exploring ways to improve, as collaborative problem-solving and experimentation are key to continuous improvement.
How do you try to improve your process? Email us, or send your feedback to #tw_studios #ebook. We’d love to hear your story.
© 2013
Share this ebook:
16
In 140 characters: Lean-‐Kanban,-‐ Scrum-‐XP-‐Agile Coach, Agile Developer, Agile Project Manager (Servant Leadership), Systems Thinker, ThoughtWorker
Paulo Caroli Kevin Kriner
I’m a Business Analyst on ThoughtWorks’ Mingle product team where I help push forward smart ideas, improving how people collaborate with an eye towards both the present and future. I’m passionate about simplicity, innovation, and continuous improvement through exploration and experimentation.
Ethan Teng
Melissa Doerken
I am a Product Manager with ThoughtWorks Studios. My career path has included varied roles as a developer, project manager, and business analyst. I am passionate about product management, lean product development, and experience design.
© 2013
I’m a Lead Consultant at ThoughtWorks, working as a Project Manager and Business Analyst on software development projects and consulting on lean and agile transformation. In the past 18 years, I have worked in a variety of industries, including education, nonprofits, public sector, financial services, real estate, high-‐tech, and healthcare services. I am very passionate about continuous improvement..
I am a Delivery Manager with ThoughWorks Studios. I’ve spent the past 12 years building software products and believe that simplicity is one of the most important attributes in process, products and code. Scott Turnquest
Share this ebook:
Be in this ebook. Tell us your story. We’d love to hear it. Email us or tweet us your take Agile Project Management
Deliver faster with Mingle +
on continuous improvement and if it is interesting we’ll include it in this ebook
Cycle Time Analytics Mingle + Cycle Time Analytics automatically calculates your team's
Email Us
cycle time, as well as shows you trends, outliers and bottlenecks in your team’s process.
Start Now Share this ebook. 18
