I've been hinting that software development and physical manufacturing processes are more closely related than we may have realized. To help illustrate this I'll describe a simplified cupcakes boutique and attempt to map that process to a software development shop.
In the cupcakes shop a customer such as say an accounting firm calls in with an order for a batch of custom cupcakes. They may order 20 or 60 or whatever. The customer chooses from a selection of icing colours and optional sprinkles topping. In this simplified shop orders come in complete and correct.
The order appears on the shop floor behind the walk in counter. A baker mixes the batch of batter into the cupcake trays and puts it in the oven. After it bakes the trays are moved to the icing station. For quality purposes a different baker checks the batch, then adds the icing and sprinkles. Every baker is trained on both the mixing and icing phases and works interchangeably on both.
From there the cupcakes go to the wrap station where another quality check is done on the work. the cellophane wrap is added and from there onto the pick up area. the customer is phoned to alert them their order is ready to be picked up.
at any stage if a quality error is detected then the batch is sent back to the previous station, or the batch may need to be discarded and redone if the error is found late and not easily fixed.
--
This maps to my development site as follows. customer orders represent change requests from product management and the executive, as well as defects found by testers.
The mixing phase represents design and coding. The icing station is code review. The wrapping is testing by the test team.
So far so good. Now with this physical model we can hopefully better analyze the more virtual world of software, identify waste and expose the real value stream.
Suppose work comes into development from a triage process. Suppose triage is only done once a day at 10 AM. hmmm that means that from the time a customer calls in the order, up to 23 hours may go by with no progress and nobody even looking at or starting on the order. Perhaps the team should move closer to continuous triage using the 80/20 rule as most of triage is routine and can be done by a senior developer. only a fraction of the issues would need the daily conference call among several principles
The baking and icing. Suppose for whatever reason the bakers in the kitchen enjoy the mixing and baking part, while they enjoy the icing station less. perhaps it's about what they see as "their" work vs. "others" work. perhaps management is much more diligent about monitoring and measuring and rewarding batches baked, while the icing phase is watched far less closely.
now in the bakery we have "visual tools" in that a foreman can see if things are getting messy and backed up at the icing station and cupcakes are going stale. he can order bakers to stop baking new batches until the situation in the icing is cleaned up.
in software over the years I've observed a tendency to really focus on coding and the assignment and delivery of code, while code review is generally tackled reluctantly, at the end, until ordered by management. I've never met a developer who had to be ordered to write code. so in software the "neglected code review" anti patten can be addressed by the use of visual tools, as well as management placing equal emphasis and attention on code review as they do on the writing of code.
onto the wrapping. suppose the baking and icing phase tends to send the batches through based on each order. now in wrapping they prefer to let a few baked orders accumulate and do a big batch wrap as that is more efficient for them. so again the work is done and just stalled in some queue making no progress and getting staler. from the value stream perspective the company only gets paid when the work completes and is delivered. so having cupcakes stuck in wrap and not moving is costing the company money in the short term and customers in the long term.
to the software developer, once the code is checked in they want it tested as soon as possible. that way if there is testing feedback the developer gets it while the matter is still fresh in his mind. also again the dev team as a whole including test only gets credit for delivery when it's all done. so in software there's an opportunity to again use visual tools to see if there are a large number of items stuck in test awaiting verification. also to measure the takt time from when some item is available from development into test, and when the testing completes. this takt time analysis is a powerful tool as it can also be used in code review to measure how long in clock time from when the review was created to when it completed.
Pulling it together, suppose your software development shop was instead a cupcakes boutique. A customer calls at 11 AM on a Monday with an order for 36 cupcakes with powder blue icing and red sprinkles. How long would it take your shop to call the customer to come pick up his finished order. later that same day? the next day? a week, usually stale, with 20% deviation rate from the order instructions? at least a month? would your software shop be able to survive in a type of business where swift delivery with high quality is required?
No comments:
Post a Comment