This post originated from an RSS feed registered with Agile Buzz
by Kevin Rutherford.
Original Post: inventory in software development
Feed Title: silk and spinach
Feed URL: http://silkandspinach.net/blog/index.xml
Feed Description: kevin rutherford on agile software development and life in macclesfield
One of the central tenets of lean (and TOC, for that matter) is that inventory is not an asset, but is waste. In particular, carrying inventory incurs storage costs. David Carlton is reading up on lean manufacturing, particularly in relation to applying its techniques to softare development. This week David asks a deceptively simple question about inventory:
"... itâs not clear to me exactly what lesson [the carrying cost of inventory] has for software development"
While neither David nor I would claim that software development is similar to manufacturing, it can be edifying to map the themes, principles and practices of the one onto the other. I think the answer to this particular question lies in looking at the various kinds of inventory we have in software development, and examining the carrying costs of each in turn. Off the top of my head:
unreachable code
Still gets built, thus contributing to slower build times, and hence to reduction of flow and feedback during coding. It may also need to be read (or worse - understood) whenever we're debugging or designing an extension in that area. We have to keep it compiling successfully, which means it could actually prevent design changes and cause inertia. And if it has tests, we have to keep them building successfully and passing - another potential cause of reduced speed, frustration and ultimately design intertia. (All of this because our codebase is part of gemba.)
unused features
Same as unreachable code, plus: Features we ship get in the way of our users, which will either confuse them, slow them down, or otherwise generally leave them feeling slightly uneasy about our product. And presumably our testers still have to ensure that the features do work as intended, so there's extra pointless work to do for each release. And if these features have bugs, we have to carry the support cost when a user stumbles upon one.
items in the product backlog
Have to be reviewed whenever stories are prioritised. And if we have too many, they may contribute to a sense that the product is a Death March.
artifacts that don't ship
By which I mean documents, plans and models that must be kept up-to-date as the fuzzy future comes into focus, and as the product evolves. None of these artifacts is directly a part of the product, and yet we spend time and money fiddling with them (while Rome burns).
(And we haven't even mentioned the time and money invested in creating these things in the first place!)
What other inventory and carrying costs does your project have?
Previous Topic
One of the central tenets of lean (and TOC, for that matter) is that inventory is not an asset, but is waste. In particular, carrying inventory incurs storage costs. David Carlton is reading up on lean manufacturing, particularly in relation to applying its techniques to softare development. This week David asks a deceptively simple