Embed Size (px)
Citation preview
PERSPECTIVES
Share this ebook.
Continuous Improvement How Cycle time can help you deliver faster
Share this ebook:© 2013
Contents
2
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
Share this ebook:© 2013
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.
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.
3
Ethan Teng,Product Manager, ThoughtWorks
Cycle time as a catalyst for Continuous Improvement
Share this ebook:© 2013
Cycle time101
4
What is Cycle time?
Cycle time is a simple but powerful metric. It is the measure of the elapsed time from the moment you start working on an item (story, task, bug, feature, etc.) until it is done.
Different teams will use different definitions for “start” and “done”. Teams often mark “start” as the time when the team starts working on an item including analysis and “done” when it is signed off by the stakeholder, or pushed to production.
How does Cycle time help?
When looked at in aggregate and across time, cycle time reveals how smoothly work is flowing through your development process, helps you spot bottlenecks and see the effects they have on your delivery. It provides the insight you need to make improvements and deliver faster.
Share this ebook:© 2013
Cycle time in practice
5
Share this ebook:© 2013
Little’s Law
“The average number of work items in a stable system
is equal to their average completion rate, multiplied by their average time in the system.” - John Little, 1961
By solving this simple first equation you are able to
find out the average time for work items in your
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.
My whiskey bar
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.
The number of whiskey bottles at my bar is
constant: 12 bottles. Per year, I finish an average of
6 whiskey bottles. So, what is the average time for a
whiskey bottle in my bar?
Let’s apply Little’s Law
Average number of work items in a stable system = Average completion rate X Average time in the system
Using my bar terms:
12 bottles (number of whiskey bottles in my bar) = 6 bottles / year (average completion rate) X 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?
Basically two guiding rules make my bar a stable system: WIP limit and Pull System.
1. WIP limitWIP 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.
6
(continued...)
Paulo, Agile Coach
“Cycle time and Little's Law”Applying Little's Law to track cycle time
Share this ebook:© 2013
2. Pull SystemPull System describes the movement of work items
driven by actual demand. In my bar example, a bottle that is finished opens a spot on my bar,
thereby creating a demand for a new bottle to be
opened and placed at the bar. Essentially, the
movement of work items (whiskey bottles) is driven
by actual demand: a finished bottle is removed from the bar, opening space for a new one that is
promptly added to the bar, occupying the vacant
space.
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).
Can I use Little's Law to determine how much WIP my team can handle, or what my average throughput needs to be - if I know my average cycle time?
Sure thing. If you are on a stable system and you
know your average cycle time, then you can
definitely play with Little’s law. You just have to be
careful not to overdo it, especially for software delivery systems. They are empirical and there are
several other things to do in order to reduce
variability in software delivery.
7
“Cycle time and Little's Law”Applying Little's Law to track cycle time
(...continued)
Share this ebook:© 2013
The Story
About 25 iterations ago (in our team’s 8th iteration
and about 4 iterations after we first started talking about capturing these metrics!), our team began
capturing and using a couple metrics for our own
continuous improvement. These metrics have
proven to be very useful in helping us improve our
delivery process, so I wanted to share them.
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 process.
3. To use this data to help find problems, find out
the root cause of those problems, and determine/
implement countermeasures so the problems
won't happen again.
Cycle time and time each story/defect spends in each state
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
Progress and Done.
The chart generated showed the mean, standard
deviation, minimum, and maximum of the data set.
Each point indicated the time that the card (story or defect) spends in each status as well as the cycle
time.
The visualization was not bad, but for 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
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.
So, I used Microsoft Excel™ to track that data, and
would also write it up on our physical board along
with a chart. We used this data as input into our
weekly retrospectives to help improve our
process. I usually mark minimum / maximum times in each state, minimum / maximum cycle time, and
highlight anything else that looks odd, interesting
or worthy of the team’s discussion.
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!
“Using Cycle Time for Continuous Improvement”
Kevin, Lead Consultant
8
A walk through of how cycle time helped us track our progress
(continued...)
Share this ebook:© 2013
So, we completed our iteration and captured cycle
time (the duration of the elapsed time between
when a story is In Progress until that story is Done) metrics for all stories that we've completed (status
= Done), and we looked at the results to see how we
did. Here's an example of how this cycle time data
could possibly be used for continuous
improvement during a retrospective:
Facilitator: “How did we do this iteration? Are there
any problems? Are there any opportunities for
improvement?
I notice that stories #164 and #173 in the grid
above have different elapsed times in different states, but they have the same cycle time of 8.1
days. Let's compare the stories:
1. Both are sized at 4 story points.
2. Both have a cycle time of 8.1 days.
3. Each has different amounts of time in each state that add up to that same 8.1 days. I'd start here.
4. What's different between the 2 stories?
a. Story #164 has 0 days In Progress, 5.1 days in
Validation/QA, and 3 days in Sign Off.
b. Story #173 has 1.1 days In Progress, 7 days in Validation, and 0 days in Sign Off.
i. Why did Validation take 7 days? In this case, not
only did it include a weekend, but the QA
stories queued up as we had more stories in
QA than we had QA capacity. We might consider setting Work In Process limits here,
and using our Developer for the QA pair to help
develop acceptance tests to get the stories
done sooner.
ii. Why did Sign Off take 0 days (less than 1/10 of a day, about 2.5 hours)? Because we have a desk
check with a QA, Developer, and the Product
Manager (PM) to get from Sign Off to
Done. Most of our sign offs take less than 2.5
hours; only a handful take more. If they do take more about a day, it usually indicates some
problem or perhaps a QA or PM is on vacation.”
“Using Cycle Time for Continuous Improvement”
9
A walk through of how cycle time helped us track our progress
Story
Status in DaysStatus in DaysStatus in DaysStatus in DaysStatus in DaysStatus in DaysStatus in DaysStatus in DaysStatus in DaysStatus in Days
Story Backlog NoneHuddle
Prep HuddlingReady to Play
In Progres
s
Ready for QA
Validation /QA
Sign Off
Cycle Time
Story Points
164 72 27.9 0 2 42.1 0 TBD 5.1 3 8.1 4
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
(...continued)
(continued...)
Share this ebook:© 2013
A common comment I hear from folks about this
time in the discussion is, “We don't really have
enough data to start determining patterns or to be predictive”. We have found that we don't need data that is statistically significant to do 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 and say things like, "On average, it takes 5 days to
develop our 4-point stories; however, we noticed
that it takes an average of 3 days for Sign Off -
why is that?" It is amazing to me the statements
that are made with no data to support them, and we can quickly cut through statements like these
with data.
2. If we take care to use the scientific method,
using hypotheses from our retrospectives about
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
new story huddle process). We are able to
compare cycle time data collected from stories
before the change and after the change, and give feedback to the folks who required us to use this
new process.
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 the data indicates a problem, that problem is
not just my problem as the Iteration Manager,
but rather the whole team becomes engaged in
trying to solve the problem.
This collaborative problem-solving and experimentation is the foundation of continuous improvement, and capturing cycle times is one of the most effective ways to get started!
“Using Cycle Time for Continuous Improvement”
10
A walk through of how cycle time helped us track our progress
(...continued)
Share this ebook:© 2013
Continuous improvement is paramount to
consistently delivering real value to our customers.
We invest in it heavily to minimize waste and always look for opportunities--both large and small--to
improve how we work.
A recent example of how we’ve improved our
process has been whittling and “WIP-ing” our wall.
And it all began with a call to action by what had become our “weighted” wall. A couple of months
ago, we had an impromptu conversation about our
card wall.
We had two lanes: Ready for Sign-Off and Sign-off in
Progress, which was one way we tried to reduce churn around development and testing, and to limit
the number of sign-off issues.
However our Quality Analysts (QA) noticed a bit of a
bottleneck around them -- the sign-off lanes were
increasing our cycle time.
Since the Business Analysts (BA) were responsible
for signing off stories, but were often busy with
analysis, the QAs had to wait to test stories until the
BAs pushed them through. To remove this blocker,
the QAs suggested removing the “formal” sign-off lanes. After talking about the change, we decided to
couple sign-off with desk checks, which we were
already doing, but were now held more
accountable for.
Spurred by this whittling, we removed other unnecessary lanes and later increased our parking
lot space to create a “poor man’s” WIP limit.
“Whittling our Wall”
Melissa, Business Analyst
11
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.
And how it helped improve cycle time
(continued...)
Share this ebook:© 2013
Together, these trimmings helped us reduce cycle
time by removing bottlenecks and focusing our
efforts on active work items only. It also allowed us to consolidate our wall from two boards to one
(below), which effectively reduced the noise in our
workspace. Our previously “weighted” wall had
successfully signaled us to re-evaluate our process.
It prompted a conversation that narrowed our focus to more effectively--and efficiently--deliver value.
We continue to review our process during bi-weekly
retrospectives, but believe that spontaneous self-
assessments are equally important and impactful in our efforts in continuous improvement. It helps us
build trust among our team and with our customers
and are always looking to how we can bolster our
process and our product.
“Whittling our Wall”
12
And how it helped improve cycle time
(...continued)
Share this ebook:© 2013
Continuous improvement and product flow are
popular themes on our product (Mingle, an agile
project management tool) development team. Both internally as we reflect on our own
development practices, and externally as we build
an agile project management tool that helps teams
collaborate and improve together. To help us
better understand our flow and gain more insight into ways we can improve, we’ve started to
incorporate cycle time into team conversations.
A few months ago, we rearranged our process and
our card wall to improve our flow. We sensed that
these changes helped improve our flow, but to be
sure we took a look at our actual cycle time to see
if what we felt was true. We used the new cycle time analysis feature in Mingle to confirm what we
suspected: our cycle time did improve.
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
wait time was reduced and our cycle time fell
below 10 days.
Scott, Delivery Manager
13
Insight into how both can help track progress and preempt bottlenecks
Over 20-‐day cycle time prior to making changes to our process
Reduction in cycle time corroborates the improvements in our process
“Trailing indicators good. Leading indicators better?”
(continued...)
Share this ebook:© 2013
Of course to get a full picture to feel confident of
our changes we also verified that our throughput
and work load remained about the same during the period over which our cycle time was
reduced.
This wasn’t a rigorous scientific experiment as
we’re not looking for statistically significant results.
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.
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.
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.
We can respond faster to events that will affect our
flow by looking for those things that would affect
cycle time. Using a leading indicator in conjunction with cycle time would help us improve even faster.
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
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.
14
(...continued)
“Trailing indicators good. Leading indicators better?”Insight into how both can help track progress and preempt bottlenecks
(continued...)
Share this ebook:© 2013
For example
Consider the card wall below. Each column
represents a queue and what we see is that the Do queue is much larger than all other queues. If we
know that our Do queue normally consists of only 3
stories, then the fact that the number of stories in
this queue has jumped to 7 may be a sign that we’re
having a problem in our delivery process. There could be any number of reasons for the increase in
the queue but the main takeaway should be that
something may be wrong and we should look to
address it now rather than wait for the delay to
show up in our cycle time.
Cycle time or queue size? Use both.
It’s probably natural at this point to question
whether we should bother with trailing indicators like cycle time at all. Monitoring cycle time and
queue size are both useful, just for different
purposes. If you’re interested in learning how well
work flows through your process so that you can
provide forecasting or learn whether previous improvement efforts have been successful, then
cycle time measurements are great. However, when
you’re interested in heading off potential issues
with your product flow you should consider using a
leading indicator like queue size. I recommend using them in conjunction with each other.
15
(...continued)
“Trailing indicators good. Leading indicators better?”Insight into how both can help track progress and preempt bottlenecks
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...)
Share this ebook:© 2013
In summary
16
Cycle time is a useful metric to provide informed insight into the progress of your development process.
Choose from various ways to calculate it, or integrate it in your development process with a tool that analyzes cycle time.
Use the cycle time data collected to trigger and inform conversations with the team and customer about improving and streamlining your process.
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.
Share this ebook:© 2013
Paulo Caroli
In 140 characters: Lean-‐Kanban,-‐Scrum-‐XP-‐Agile Coach, Agile Developer, Agile Project Manager (Servant Leadership), Systems Thinker, ThoughtWorker
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.
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 an author, speaker… essentially a loud-‐mouthed pundit on the topic of software development. I’ve been working in the software industry since the mid-‐80’s. My main interest is to understand how to design software systems, so as to maximize the productivity of development teams.
I am an author, speaker… essentially a loud-‐mouthed pundit on the topic of software development. I’ve been working in the software industry since the mid-‐80’s. My main interest is to understand how to design software systems, so as to maximize the productivity of development teams.
Kevin Kriner
Scott Turnquest
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. 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.Ethan Teng
Be in this ebook.
Tell us your story.We’d love to hear it. Email us or tweet us your take on continuous improvement and if it is interesting we’ll include it in this ebook
Email Us
18
Share this ebook.
Agile Project Management
Deliver faster with Mingle + Cycle Time AnalyticsMingle + Cycle Time Analytics automatically calculates your team's cycle time, as well as shows you trends, outliers and bottlenecks in your team’s process.
Start Now
