What is it to “produce”, specifically in the domain of software?
We speak of productivity in business all the time, so let’s start by linking productivity with “producing” and “production”.
The Theory of Constraints, a production system most often linked to manufacturing, uses three metrics – inventory, operating expense and “throughput”.
Though the first two are not as obvious as they may sound (and are topics for other posts in the future), “throughput” is the rate at which a system produces “money” (or products we can sell, or software we can ship to a customer).
Now, you may remember I am a proponent of agile software development.
There are some great philosophical parallels between ToC and tenets of agile, but one thing I want to focus on is what helps us move toward our Goals and what shows up as constraints from reaching them.
Shipping quality software, fast
What does it take to focus on the prize and ship valuable and high quality software as fast as possible?
Without writing out another agile manifesto, here are some fundamentals (in “Faw’s Laws” format, and not necessarily in order):
- Coordinate, communicate and collaborate with your teammates and customers recurrently
- K.I.S.S. – “steer the ship” in small increments with your eyes on your end goals (shipping quality software, fast… remember?)
- Give your team and your customer plenty of feedback on your progress in as low-cost a way as you can
- Don’t pretend to know everything up front, or that things won’t change along the way
- Team trust – you have to know your teammates have your back, and you’ve got theirs
- Avoid, minimize and/or eliminate rework – let’s not waste the precious hours of our lives
- Automate tedious tasks (testing, build, etc.) to remove manual errors/omissions and cut overhead time
- If you want to reduce the need for brittle documentation, draw pictures and don’t forget to write logs
- “Those who say it is impossible should get out of the way of those doing it” – a favorite quote (not sure where it originated)
- Umm… and a pet peeve – be suspicious of null pointers and poor exception handling (I couldn’t leave these out)
My primary concern in writing these out is to maximize throughput while simultaneously minimizing “inventory” and “operating expense”. Again, we may talk about those two later on.
Whichever development method you embrace, your tactics are likely to be oriented around achieving more fundamental interim goals like these.
What others would you add to the list? How would you frame your objectives differently?