Continuous Improvement

Transcription

1 PERSPECTIVES Continuous Improvement How Cycle time can help you deliver faster Share this ebook.

2 Contents Introduction 3 Cycle time 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 2

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

4 Cycle time 101 What is Cycle time? How does Cycle time help? 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. 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. 4

5 Cycle time in practice 5

6 Cycle time and Little's Law Applying Little's Law to track cycle time 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 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). Paulo, Agile Coach 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 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 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. (continued...) 6

7 Cycle time and Little's Law Applying Little's Law to track cycle time (...continued) 2. Pull System Pull 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

8 Using Cycle Time for Continuous Improvement A walk through of how cycle time helped us track our progress Kevin, Lead Consultant 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! (continued...) 8

9 Using Cycle Time for Continuous Improvement A walk through of how cycle time helped us track our progress (...continued) 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. Story Backlog None Huddle Prep Huddling Status in Days Ready to Play In Progres s Ready for QA Validatio n /QA Sign Off Cycle Time TBD TBD TBD TBD TBD Story Points (continued...) 9

10 Using Cycle Time for Continuous Improvement A walk through of how cycle time helped us track our progress (...continued) 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! 10

11 Whittling our Wall And how it helped improve cycle time 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. 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...) 11

12 Whittling our Wall And how it helped improve cycle time (...continued) 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 selfassessments 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. 12

13 Trailing indicators good. Leading indicators better? Insight into how both can help track progress and preempt bottlenecks 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. Over 20- day cycle time prior to making changes to our process Scott, Delivery Manager Reduction in cycle time corroborates the improvements in our process (continued...) 13

14 Trailing indicators good. Leading indicators better? Insight into how both can help track progress and preempt bottlenecks (...continued) 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. (continued...) 14

15 (...continued) Trailing indicators good. Leading indicators better? Insight into how both can help track progress and preempt bottlenecks 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. 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...) 15

16 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? us, or send your feedback to #tw_studios #ebook. We d love to hear your story. 16

17 In 140 characters: Lean- Kanban,- Scrum- XP- Agile Coach, Agile Developer, Agile Project Manager (Servant Leadership), Systems Thinker, ThoughtWorker Paulo Caroli 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 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 Kevin Kriner 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

18 Be in this ebook. Tell us your story. Agile Project Management Deliver faster with Mingle + We d love to hear it. us or tweet us your take 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 cycle time, as well as shows you trends, outliers and bottlenecks in your team s process. Us Start Now Share this ebook. 18