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 ---------------------~-->
Turn flat surfaces into speakers with the Soundbug.
http://us.click.yahoo.com/QWAVSC/onCFAA/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/