Inventory as Waste

My coworker Paul was telling me today about some of the presentations he attended at the Agile conference earlier this month, and one of the things he mentioned was the idea that inventory is a kind of waste.

It took me a little while to grasp this concept, but I think of it this way:

Imagine a mechanic's shop. There is a team of mechanics, and they all work together to fix cars (or whatever). They have an inventory of wrenches, and each wrench has a certain cost associated with it, based on the initial cost of the wrench, the cost of storing it, degradation of the wrench over time, etc. The wrench's purpose is to be used to fix cars. When used for its purpose, the wrench is not wasted; it is contributing to the goals of the team. Whenever the wrench is in storage instead of being used for its purpose, it is wasted; it costs the team to store it, track it, put it away, etc. So, ideally, every wrench should be used (appropriately; misuse of a tool is another topic!) as much as possible.

Now, of course, some waste might be necessary. Perhaps certain tasks require the use of multiple wrenches, or when the team is at capacity all the wrenches are in use (but this doesn't happen all the time, nice as that would be). So you have to find the appropriate balance of waste vs efficiency.

Brief, Random Thoughts on Agile

I like Agile.

Business people have trouble with agile. Consider this recently-overheard exchange:

Business: It seems like [the project architect] just wants to do the bare-bones necessary.

IT Guy: That's his job.

A valid point that was brought up was that this sometimes results in delivering functionality later than originally planned. But I'd point out that 1) this happens all the time in software anyway and 2) the functionality is often prioritized below bug fixes (sometimes rightly, sometimes wrongly).

Something I like about agile is that you only write the functionality that's needed, as it's needed (and ideally you've written previous functionality well enough that it's not very hard to refactor).

Another thing I like is that it recognizes that there's only so much time to spend on anything, and the business has to be frugal about what's needed, or the project will run out of money before finishing basic functionality. This can, however, be difficult for business people.

On the other hand, developers used to the waterfall approach (or other non-agile methodologies) tend to over-develop out of habit. (Sometimes I even find myself doing this.)

Production-ready code at the end of each iteration is good.

Good merge tools are worth it. (Not agile-specific...)

QA and UAT should be integrated ASAP (how else will you have production-ready code at the end of the iteration?).

Despite what Dilbert's Pointy-Haired Boss says, it's not "start coding and complaining" (though we do code a lot, of course, and complaining is the developer's past time).

I'm going to try to apply some of the agile/scrum practices to other areas, like DPO (though I'm not going to tell them that's what I'm doing).

Code Criticism

If you're a professional programmer, expect your code to be criticized.

Expect it on your worst code (because everyone writes crappy code sometimes).

Expect it on your best code (because there's almost always room for improvement).

Expect it to be helpful (because everyone brings a different perspective, talent and experience to the team).

Expect it to be worthless (because some people will want to bring you down or will just plain be wrong).

You should be worried if your code isn't criticized, because it means that either no one cares or no one is brave enough. Neither situation is good for the project.