Re:The Fast Pencil Fallacy in Software Development
by Jtsummers on Tuesday June 30, 2020 @03:45PM
(#23694005)
I think it's important to understand what the fast pencil might do for a business.
If a business presently has a slow process that they want you to accelerate, they probably also batch it. That is, they gather a lot of that same kind of work together and do it all at once (whether each task depends on any of the others or not).
By accelerating (giving them a fast pencil), you make it feasible to break this batch cycle up, distributing the work more evenly either across people (it's clearer what small units of work need to be done so other people can grab and do the work as needed) or time (even if it's still one person, if the work is now entering three items in a field and approving or disapproving then it's easier to do "on demand" versus waiting until the end of the month).
This doesn't mean they will switch to small batches, but it means they can. If they choose to do this, the business will almost always see improvements in overall performance (assuming that those processes were ones that blocked other critical activities). Consider the improvement if this is purchase orders: The company isn't in the business of purchasing things but of doing X. The purchases, though, permit X to happen. If all purchases orders are batched at the end of the week or month, then everything else is stuck on that same cycle. If the purchases can now be evaluated and approved/disapproved daily (say the approver checks at 12pm and 4pm) suddenly everything else runs much better. (This is the basis of Theory of Constraints, with the assumption that the purchase is the bottleneck in this scenario for many/most projects.)
This is the transformation that businesses need to get to, but they can't break these cycles until they get something faster. And once they have something faster, real automation and improvement because feasible. It was technically feasible before, but the customer didn't understand what they were doing or they felt overwhelmed by it ("It takes us 4 managers and 5 work days at the end of each month to do X right now"). This is the basis of process improvement. You start by accelerating (in a sane way) the things that can be accelerated and removing the unnecessary things, then you start real transformation because it becomes visible where things can or should be improved. You gain greater focus and clarity with the freed time and mental resources.
I faced this repeatedly over the last few years at my previous job. Everyone felt overwhelmed. The office was in a chronic state of panic. They batched all their work, and it led to lots of issues because it created artificial synchronization points and constraints. The only way to make improvements was not to reinvent everything, that would never sell (I tried). It had to be incremental with fast pencils. Automate this test suite, automate that build process, automate the deployment process to the extent possible (embedded, there are physical blockers here), convert a manual business process to a proper workflow, etc. Each one freed up personnel and time and let people start coming back from that panic state. After that, then you can focus on how to really change and improve the business because now you're making as much money for half the time, but if you're smart you keep all the people. You can move them around, or take on more work. Or let them run experiments to try and improve other areas or other projects, taking their lessons with them.
If a business presently has a slow process that they want you to accelerate, they probably also batch it. That is, they gather a lot of that same kind of work together and do it all at once (whether each task depends on any of the others or not).
By accelerating (giving them a fast pencil), you make it feasible to break this batch cycle up, distributing the work more evenly either across people (it's clearer what small units of work need to be done so other people can grab and do the work as needed) or time (even if it's still one person, if the work is now entering three items in a field and approving or disapproving then it's easier to do "on demand" versus waiting until the end of the month).
This doesn't mean they will switch to small batches, but it means they can. If they choose to do this, the business will almost always see improvements in overall performance (assuming that those processes were ones that blocked other critical activities). Consider the improvement if this is purchase orders: The company isn't in the business of purchasing things but of doing X. The purchases, though, permit X to happen. If all purchases orders are batched at the end of the week or month, then everything else is stuck on that same cycle. If the purchases can now be evaluated and approved/disapproved daily (say the approver checks at 12pm and 4pm) suddenly everything else runs much better. (This is the basis of Theory of Constraints, with the assumption that the purchase is the bottleneck in this scenario for many/most projects.)
This is the transformation that businesses need to get to, but they can't break these cycles until they get something faster. And once they have something faster, real automation and improvement because feasible. It was technically feasible before, but the customer didn't understand what they were doing or they felt overwhelmed by it ("It takes us 4 managers and 5 work days at the end of each month to do X right now"). This is the basis of process improvement. You start by accelerating (in a sane way) the things that can be accelerated and removing the unnecessary things, then you start real transformation because it becomes visible where things can or should be improved. You gain greater focus and clarity with the freed time and mental resources.
I faced this repeatedly over the last few years at my previous job. Everyone felt overwhelmed. The office was in a chronic state of panic. They batched all their work, and it led to lots of issues because it created artificial synchronization points and constraints. The only way to make improvements was not to reinvent everything, that would never sell (I tried). It had to be incremental with fast pencils. Automate this test suite, automate that build process, automate the deployment process to the extent possible (embedded, there are physical blockers here), convert a manual business process to a proper workflow, etc. Each one freed up personnel and time and let people start coming back from that panic state. After that, then you can focus on how to really change and improve the business because now you're making as much money for half the time, but if you're smart you keep all the people. You can move them around, or take on more work. Or let them run experiments to try and improve other areas or other projects, taking their lessons with them.