Reduce Lead Time

8/6/2019 Reduce Lead Time

1/18

h

Software ManagementCTO Series

12 Things to ShortenYour Lead TimeStephan Schmidt


2/18

Stephan Schmidt Page 2 of 18


You may distribute this eBook freely , and/or bundle it as a freebonus with other products, as long as it is left completely intact,unaltered and delivered via this PDF file. You may also republishexcerpts as long as they are accompanied by an attribution link backto

http://www.codemonkeyism.com
http://www.codemonkeyism.com/http://www.codemonkeyism.com/http://www.codemonkeyism.com/


3/18



This eBook will give you insights into how to reduce the lead time ofyour software development process . In many companies theperception is as follows: why are we so slow? Marketing probably asksyou why you have lead times of several months as an IT-department,from their ideas to seeing the feature live. Many companies have largelead times, often unnecessarily large. The good news is: You canshorten them, sometimes by several hundred percent!

Why shortening lead time?

Shortening lead time is possible, but not easy. So why should you do it? There are manyreasons to shorten your lead time. The sooner you get a feature live on your platform, thesooner it will generate money for you (see Table 1). Shortening the lead time from threemonths to one month means, the feature will earn two additional months of sales. This isthe case for every feature that goes live earlier. More money earlier means more moneyto invest -more investment means a larger market share sooner.

Short lead times might mean the difference between being a first mover or not. There arelots of first mover advantages, if you're faster than your competition, your customers willperceive you as the market and innovation leader, not the copy cat. Short lead timesdifferentiate the good from the great.

When going short, you will need a lot of discipline. As we'll see shortening lead timesmeans you need to solve many problems that will arise in your process. No more slack.Solving those problems will make you lean and give you cost advantages over your

4/4 2/0

Development [weeks] 4 2

Buffer [weeks] 4 0

Money/ Feature/ Week [EUR] $10.000,00 $10.000,00

Sum [EUR] / year $2.640.000,00 $6.500.000,00

100,00% 246,21%

Table 1 Comparing a 4 week development, 4 week buffer model with 2 week development, 2 week buffer model. The second makes 246% of the

money


4/18



competition.

What is lead time?

"A lead time is the period of time between the initiation of any process of production and the completion of that process. Thus the lead time for ordering a new car from a manufacturer may be anywhere from 2 weeks to 6 months. In industry, lead time reduction is an important part of lean manufacturing." Wikipedia

When measuring lead time, software development and IT departments often start theclock when they start to work on a feature. But this is much too late. Take the perspectiveof your customers. It's necessary to start the clock as soon as your customers inmarketing, sales, accounting, back-office have an idea and issue a request.

When does the clock stop? Many development processes stop with the last line of codewritten or the last feature tested. As before perceive the process the way your customersdo. The endpoint of feature development is when the idea generates money. This oftenmeans when it's deployed to the live system, not earlier.

To measure the process from the point of view of your customers, do not optimize locally,optimize the whole process. The process is done when the idea generates value for yourcustomer; it's not done at the end of development or the end of QA.

But how to shorten your lead time? This eBook is a step-by-step guide towardsshortening lead time. The internet is full with information, blog posts, articles or tweets.Many books exist on the topic of lean production and lean development and some good


5/18



ones are listed in the sources section. The problem is not to know how to do it, but whatto do when. With all this information, what shall I do?

The overall goal of all actions for reducing lead time is reducing waste. Your process isclogged with waste, called muda, mura and muri in the lean community. The mostcommon waste in software development is buffers. When features stay for a long time ina buffer before design, or before development, you are creating waste. Other mudawastes in software development are partially done work, extra features [1], relearning,handoffs, task switching, delays and bugs. Other waste is muri, which means overburden

and mura for inconsistencies or unnecessary variation. With removing waste, lead time isreduced substantially (see Figure 1).

1. Measure, measure, measure2. Increase quality3. Reduce rework4. Frequent releases5. Stop working in parallel6. Shorter stories7. Visualize and manage flow8. Rigorously cancel meetings

9. Continuous deployment10. Shorten product management11. No single point of failure or bottleneck12. Leveling work


6/18


7/18



11 Actions you can take now:

1. Measure, measure, measure

The very first thing is to start measuring your process if you don't already do so. Forstarters record the day when the idea was filed, when it was ready for development, whendevelopment started, when development ended, when it went into QA, and how long itwaited to be released (see Table 2). Armed with those numbers you can calculate your

lead time from idea to going live. You can calculate the duration of your buffers: how longa feature is waiting before going into development, before going into QA and waiting forbeing released. Without measuring, all other attempts to reduce time-to-market are futile.

Sprint Story Description SPFeatureIdea

DevReady

StartDev

EndDev

Pre-Dev

BufferBefore

TimeDev

BufferQA

Waitto REL

LeadTime

22.06.2009 03.07.2009 "Make things work" Release 42 20.07.2009

12 S1 Reimplement PayPal Provider 2 02.06.2009 10.06.2009 22.06.2009 29.06.2009 6 8 5 5 15 34

12 S7 Add customization 8 04.06.2009 15.06.2009 22.06.2009 01.07.2009 7 5 7 3 13 32

12 S12 Add REST Interface to API 40 15.06.2009 16.06.2009 23.06.2009 02.07.2009 1 5 7 2 12 2512 S10 Evaluate Cassandra 2 26.05.2009 20.06.2009 23.06.2009 24.06.2009 18 1 1 8 18 3912 S8 Migrate Backend to Scala 13 11.06.2009 23.06.2009 30.06.2009 03.07.2009 8 5 3 1 11 27

12 S4 Implement Password Reminder 13 16.04.2009 22.06.2009 22.06.2009 29.06.2009 47 0 5 5 15 67

Table 2 Example measuring feature metrics in Excel. This calculates the lead time, development time and several buffer times


8/18



2. Increase quality

Low quality is one of the biggest wastes in development. The goal with increasing qualityis to drop your QA phase altogether. In most companies there is a dedicated QA testdepartment and a test phase after development has f inished. Often it takes days or weeksbefore a feature goes through QA, increasing your lead time significantly. Moving thetesters to your developers, making them test each feature as soon as a developers saysshe's finished and before the code is stored into your source repository, reducesturnaround time for features and bugs dramatically and allows you to drop the QA phase.

To do this, you probably need to increase your quality a lot, which meansadding testers to teams,educate your developers,set a zero-bug policy,add automatic tests on unit level, on regression level, for functional testing andintegration testing.

Increasing quality dramatically will help you later on the road to continuous deployments(0 day release buffer), see below.

3. Reduce rework

The worst case are bugs detected by your customers. Not only will this tarnish yourimage, it will take a lot of time to fix.

1. The bug is filled with customer support,2. goes to your QA department,

Low quality is one of thebiggest wastes in software

development.


9/18


10/18



two weeks a feature release, in-between a bug and configuration release. This is easilymanageable. Going down to 1 week feature releases usually doesn't pay, especially ifyoure agile. Instead of reducing the release cycle below 2 weeks, better go forcontinuous deployments (see below). With agile development, align your iterations withyour release cycle to not artificially extend the release buffer. If you have 2 weekiterations in development - and not overlapping iterations between teams - use a 2 weekrelease cycle. The release buffer can then be shortened from a maximum 120 work daysto below 10.


11/18



5. Stop working in parallel

Often development teams work highly parallel, which means each developer works on hisown feature. Suppose it takes each developer 5 months to finish his feature, then the timeto market for every feature is 5 months (see figure 1). If instead all developers work on

one feature, and work can be parallelized 1, then the firstfeature will be finished in one month, the last will befinished after 5 months, reducing the average lead time to3 months.

With parallel development there are 5 unsatisfiedcustomers, each waiting five months for their feature. In the second case, only one customer will need to wait 5months, all others get their feature earlier online. As apositive side effect, because you only work on eachfeature one month instead of five, your customers willblame the waiting time on the lack of enough developers.They will blame their waiting time on slowdevelopment in the first case.

6. Shorter stories

As studies have shown, the 80/20 rule holds true for software development. With 20% ofdevelop ment you will satisfy 80% of your customer needs. Its important to identify the20% of your stories that provide 80% of the value. Shorten the features or stories to the

1 There are limits on how much a feature can be parallelized. With low developer numbers like 5 and big enough featureswork can be parallized enough to gain significant lead time.

1. Feature

3. Feature

2. Feature

4. Feature

5. Feature

Developer 1

Developer 2

Developer 3

Developer 4

Developer 5

1 2 3 4 5

Time to market = 5 months

Months

1. 3.2. 4. 5.

2 3 4 5 Month1

Shortest time to market = 1 month

D e v e l o

p e r 1 - 5

Figure 2 Parallel versus serial development


12/18



20% that provide most value and your lead time for features will be dramatically reduced(in an optimal case by 5 times).

Keep also in mind, studies have shown that 64% of features are never or rarely used.Those clog your development pipeline, increase lead time for all other features and arentused by your users!

7. Visualize and manage flow

Visualize your stages of development. As a visual tool in lean development people use aKanban board. In software development this board contains all features currently in thepipe. If a feature moves from one stage to the next, from Development to Test Ready,


13/18



the card is moved to the corresponding column. As an information radiator the board tellseveryone in the company in which stage a feature is. Based on that transparency, flowcan be managed. Its easy to see where congestion or a bottleneck is. More advancedtechniques of managing flow are work in progress (WIP) limits. Each stage limits thenumber of features it can contain ; understaffed and unbalanced stages will theneasily show by blocking flow.

8. Rigorously cancel meetings

Another big waste that prevents your developers from developing code are meetings. Youthought you did hire developers to develop code. But often they arent. Rigorously removemeetings from your corporate culture. If in doubt, do not meet. Let your developers writecode and work on customer value . Taking a look at Scrum will help. Scrum as an agilemethodology has a pre-defined set of meetings, all with actionable results and timeboxed . This minimizes the number of meetings without clear results that seem to go onendlessly.

9. Continuous deployment

With the goal to remove all buffers, set your release buffer to 0 days. This is calledcontinuous deployment. A feature is developed, checked into your source repository,automatically tested, automatically deployed to one server, checked again and deployedto the next server - or in case of a failure the version is rolled back to the last version ofyour platform that worked. Continuous deployment - versionless software - reduces yourrelease buffer to 0. Every feature is live minutes after development has finished. Thisneeds a lot of discipline though.


14/18



You need a high degree of automatic testing and a high coverage for unit testing,regression testing, integration testing and functional testing. It helps to have first masteredtip 2 "Increase Quality" and tip 4 "Frequent releases". Those should have teached youmost of the discipline that is needed. They should also have teached you to make yourdeployments as easy as possible and mostly automatic. Because continuousdeployments need to be automatic in order to work.

10. Shorten product management

Many companies measure productivity and time to market from the start of developmentto the point when a feature went live. But often a lot of time is wasted before developmentstarts. Ideas are thrown around, discussed, refined, changed and when finally after weeksor even months the feature goes into development, the customer asks "why doesdevelopment take so long?" The key is to reduce the time a feature stays in productdevelopment: Stop Talking. Start Doing . This can either be accomplished with settingtime goals and time boxes for each feature or with running iterations just like yourdevelopers do. Prevent analysis paralysis. Set a time box of one week per feature, afterone week it should be ready for development. You can always improve your ideas later:

During development when youre agile, with a new feature if youre not.Product management is often prone to the same errors that plague development: workingon too many features at the same time in parallel. Stop working on many features at thesame time now , start working only on a limited set of features (called work in progress orWIP). Push a feature through product management and requirement gathering. Don'tprocrastinate. Have a list of items for level of done. When are you done with product


15/18



management and the feature is development ready? A concrete list will give you goals(SMART) you can achieve.

11. No single point of failure or bottleneck

With a single point of failure (SPOF), your lead time becomes unpredictable. Should thesingle point of failure break, your lead times will go up dramatically. In softwaredevelopment SPOFs can be all involved where there are not enough of:

Perhaps you only have one designerOr a single product manager who can use a wire frame toolThe only developer who knows how to write that special backend codeA system operator who is the only one who can deploy certain servicesThe single database guru for your legacy system

Single points of failure are not only a risk for increasing your lead time, but often they arebottlenecks who increase the lead time of all your features. Bottlenecks can also be foundin support teams, design teams, database teams who are understaffed. Whenmeasuring buffers and lead times, its easy to detect where youre understaffed andtake measures.

12. Leveling work

Unnecessary variation or unevenness in an operation is called mura in Japanese.Together with muri which means overburden. In software development you often havevery stressful phases alternating with phases where there is a low amount of work. This


16/18



not ideal, because it will burn out your developers when they are overburdened, and youpay too much for developers when there is only a low amount of work. Lead time isbecoming erratic . The key is to leveling your work. In Japanese lean terms this is calledheijunka. Leveling the work level reduces lead times for all features and makes lead timemuch more predictable. The best way to level work is to introduce a pull process. Laterstages in the process (development) are pulling work from earlier stages of development(product management or business analysts). Contrary to pushing work downstream, thiswill create a leveled work load with optimal developer utilization. Otherwise you havepeaks, so you need to hire for peaks.


17/18



Web Sources

The 7 Software Development Wastes - Part 1, Jack Milunksy

The Three M's - The Lean Triad, InfoQ, Roman Pichler

Books to Read

Implementing Lean Software Development, Mary and Tom Poppendieck

The Toyota Way, Jeffrey Liker

Lean Thinking, James P. Womack and Daniel T. Jones


18/18



About the author

Stephan Schmidt is head of development at brands4friends, a large eCommerceshopping club for brands. He has over 25 years of programming experience and morethan 15 years of internet technology experience. He was head of development, teammanager, CTO and consultant in different companies and is a speaker, author and blogwriter. He specializes in organizing and optimizing software development helping mediumcompanies and startups by increasing productivity with lean software development and

agile methodologies.BLOG : Codemonkeyism ( http://www.codemonkeyism.com )

TWITTER : Codemonkeyism (http://www.twitter.com/codemonkeyism )

Download this

This eBook is available from http://www.codemonkeyism.com/ebooks

Credits : Creative Commons image by laihiu used under a Creative Commons license from Flickr, Las Vegas coverimage by Roadsidepictures under a Creative Commons license on Flickr. Thanks to Copyblogger for the idea of freedistribution .
http://www.codemonkeyism.com/http://www.codemonkeyism.com/http://www.codemonkeyism.com/http://www.twitter.com/codemonkeyismhttp://www.twitter.com/codemonkeyismhttp://www.twitter.com/codemonkeyismhttp://www.twitter.com/codemonkeyismhttp://www.codemonkeyism.com/

Documents

Reduce Lead Time