RE: Another value stream map

It is interesting to look at this map in terms of what might be achieved.

Let's assume that the constraint of exhaustive final testing does hold (perhaps
the best way of eliminating that constraint is to ensure that it never
discovers anything). The optimal "concurrent engineering" loop is the 3-4 weeks
of concurrent analyze/design/build/test and the 3-4 weeks of final testing.
That would leave a SIP of 40-60 vs. 180. Even that might eliminate the
expediting problem.

Or perhaps the optimal window feeds into the performance testing environment
continuously? Perhaps one could imagine two weeks analyze/design/build/test and
two weeks final testing?

Arien

--- Kent Beck <[email protected]> wrote:
> The Goal talks about how proud a crummy manufacturing line was of their
> ability to expedite orders. In fact, they would routinely expedite 40%
> of all orders. This makes me wonder if the SWAT team approach is
> actually going in the wrong direction. If you got SIP from 180 to 30,
> the need for expediting would disappear. If you start expediting,
> average SIP will probably rise, creating the need for more expediting.
>  
> Kent
> 
> -----Original Message-----
> From:
> sentto-8007113-331-1041625157-kent=threeriversinstitute.org@returns.grou
> ps.yahoo.com
> [mailto:sentto-8007113-331-1041625157-kent=threeriversinstitute.org@retu
> rns.groups.yahoo.com] On Behalf Of Bill Wake <[email protected]>
> Sent: Friday, January 03, 2003 12:19 PM
> To: [email protected]
> Subject: [SIP] Another value stream map
> 
> 
> I scheduled time with a technical manager from an IT shop (for a 
> team of about 40 developers). They support a high-volume, 
> transaction-oriented web site (300K transactions/day). 
> 
> We took a stab at creating a value stream map. 
> 
> In reverse order: 
> 
> Deployment (1 day) <- Go/No-Go Decision (1 hour) 
> 
> This was fed by four streams: 
> 1. Change Control Board (10 days before deployment, and must be on 
> their calendar a week before that). 
> 2. Final Functional Testing (3 weeks plus) 
> 3. Performance Testing (3-4 weeks) 
> 4. Stability Testing (3-4 weeks) 
> 
> Final testing is preceded by a review. 
> 
> Before the review come 
>           Preliminary Functional Testing (weeks) 
>        <- Design/code reviews 
>        <- Construction (say 3-4 weeks) 
>        <- Analysis reviews 
>        <- Requirements/Analysis (3-4 weeks) 
>        <- Feasibility review & prioritization 
>        <- Feasibility (1-n weeks) 
> 
> For construction vs. testing, there is overlap as testing can start 
> as various things are built. 
> 
> ---- 
> I don't think the process of building the map was as smooth as it 
> could be. A thing I found very hard to get over is the tendency to 
> talk about a phase in general. It became clear to me that you really 
> have to focus on one request moving through the entire system. 
> 
> ---- 
> A request dropped into the stream today would be in production in 
> about 6 months. (That doesn't quite jibe with the numbers above, I 
> know.) The team releases monthly. 
> 
> Our analysis of this took several directions. 
> * The main prioritization takes place after feasibility assessment, 
> when the schedule is created. The client could adjust priorities at 
> other times but doesn't tend to now. 
> 
> * The heavy testing time at the end is important to the client. 
> 
> * The testing environment is used by other projects too. This team 
> could only expect to use it 1/3 of the time. This makes for a 
> bottleneck. 
> 
> * Shortened development times could be appealing to the client; an 
> NPV will be improved if payback starts months sooner. 
> 
> * There are requests that could be handled very quickly. We talked 
> about the feasibility of creating a team of 
> analyst+programmer+tester that would turn something around in a week 
> or two, and squeeze it into the next testing window. (I didn't get a 
> sense of what proportion of requests this might cover.) 
> 
> * Currently, all requests are treated as if they're risky from a 
> system performance point of view. It might be possible to split the 
> stream of requests into "expected to impact performance" and "not 
> expected to impact performance." The latter could get an abbreviated 
> performance test. (This idea could be combined with the previous 
> idea too.) 
> 
> The latter two things might produce some movement towards "flow" and 
> are possible politically. 
> 
> I got a sense from this exercise that they don't have much sense of 
> the cost of delay or the cost of their "inventory." We didn't try to 
> put dollars on it but that would have been my next step. 
> 
> --Bill Wake  [email protected] 
> 
> 
> 
> 
> Yahoo! Groups Sponsor	
> 
> ADVERTISEMENT
>  
> <http://rd.yahoo.com/M=241773.2725424.4169802.1925585/D=egroupweb/S=1705
> 007181:HM/A=1394045/R=0/*http://www.hgtv.com/hgtv/pac_ctnt/text/0,,HGTV_
> 3936_5802,FF.html> HGTV Dream Home Giveaway	
>  
> <http://us.adserver.yahoo.com/l?M=241773.2725424.4169802.1925585/D=egrou
> pmail/S=:HM/A=1394045/rand=641483320> 	
> 
> To unsubscribe from this group, send an email to:
> [email protected]
> 
> 
> 
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/> . 
> 
> 
> 


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Flexible Keyboard is the ideal accessory for PDA users that are on the move.
http://us.click.yahoo.com/dCBVZC/WnCFAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/