So, why are there no new productions? Where are the victories in competitions? What do you mean two months running and collecting papers? What other creativity? And why don't you have time for it? What other secretary should you hire? What do you mean "I'm leaving"? Do you seriously think you can handle it without us? Well, good luck.
Something like this described a very good leader of a very good dance group life "under the wing" of a state institution, when he explained why he left "from under the wing."
The case sunk into the soul, tk. I was just conducting an experiment (once again) to rid other creative people - programmers - from non-core, but "such an important, necessary and obligatory work" - being in time.
What happens if?
I have conducted this experiment several times, in different companies - both on projects, and on development, and on factory programmers, and on the provision of revision services. Believe it or not, the result is always the same.
If programmers stop worrying about deadlines and just solve problems, one after another, without any distraction, then productivity will double. Accordingly, if you turn on the "catching on time" mode back, then the coefficient is exactly the same - twice, only this time productivity is divided by it.
Well, and most importantly: the programmer still does not hit the deadline, for the life of me. And if it does, then only sometimes, by accident. Or at the cost of reduced productivity.
Everything is very simple here. I will not prove the axiom that a programmer never knows exactly how long it will take to solve a problem - there are a lot of articles and books on this topic. If you worked as a programmer, then proof is not required. There are, of course, exceptions - similar, repetitive tasks - but these are the exceptions.
Most of our work contains so many constantly changing unknowns, constant flashbacks of old tasks, surprises from subcontractors and updates to dependencies, design errors, etc.
How do you plan to do this work? Fundamentally there are four approaches - fantasy, reserve, volume and flow.
Methods of "planning"
Fantasy is the application of batch production planning methods to the work of programmers. For example, Lean or MRP. This approach is used by all "classical managers", especially their separate caste - "managers". You just need to squeeze the planned labor costs out of the programmer, ignoring all his cries like "Damn it, I don't even close what I will face there," and draw a beautiful sausage on the Gantt chart. And redraw every day.
The reserve is approaches such as the theory of constraints, when a horse's share is simply added to the planned labor costs, just in case. The resulting figure is also drawn as a sausage on the Gantt chart. Redrawn less often, but almost always.
Volume is when it is not the time frame for solving problems that is planned, but productivity. For example, this approach is used in Scrum - knowing the approximate speed of the team's work (in story points), you can plan the amount of work per sprint (in the same SP). Accordingly, all sprint tasks have the same due date.
Flow is when there is only speed. Tasks are lined up, the programmer sits down and solves one by one. The dates are not known, but they can be calculated - knowing the speed and number of the task in the queue. The main thing is not to puzzle the programmer himself with the calculation of the term.
Pros and cons
There is no point in even discussing a fantasy approach - it does not work. Not only that - it also creates constant, wild stress and idiotic rescheduling work. You can live if someone else is not involved in replanning, but this rarely happens. Usually the programmer is just hammered every day with questions like "tell me the deadline", "when will you finish this task?" or "all the deadlines have passed, will you work or not?" In a natural, harmonious way, the programmer comes to reserves of time, even if he does not know anything about any fashionable techniques.
Reserves of time save you from hassle, but reduce productivity, due to the action of Parkinson's law - work takes all the time allotted for it. In some circumstances, this approach suits everyone - for example, for factory programmers. True, until the programmer resigns, then, as a rule, he realizes that his work speed is lower than market requirements.
The deadlines are met, since time reserves can be thousands of percent of real labor costs. If the business or process is structured in such a way that the key indicator is precisely hitting the deadline, then the time reservation method is very suitable.
Bulk methods like Scrum can roughly double your productivity because reduce the influence of Parkinson's law and focus on more or less real productivity, not fantasies and reserves of time. However, a sprint is still a deadline, so Parkinson's law continues to operate, as do time reservations and attempts to manipulate story points. People are people - both programmers and managers. Programmers want to be good employees. And managers are so accustomed to considering good employees only those who “meet the deadline” that at least a count is on their heads. All this will simply be called differently - like "all backlog tasks must be performed within the sprint, and there is nothing to facilitate here." And they will come up with some other KPI for this business, because the imagination is not rich.
There are no such problems in the stream, since there is no reason for them - the planning of the programmer's work and attempts, one way or another, to estimate the timing of work. The flow protects the essence of the programmer's work - creativity. I would like, of course, to say that flow is pure creativity, but this does not happen. However, the purity is much higher. And productivity is doubled more than Scrum.
What's interesting: the protection of the programmer, or any performer of the work, is incorporated in any of the above methods. But when applied to programmers, protection is always forgotten.
What is the basis of any method
For example, Lean, oddly enough, is also based on the idea of flow, since invented on the assembly line. The idea is to arrange the work as evenly and harmoniously as possible. So that each performer in the chain, on the one hand, always has something to do, and on the other, so that there is no queue in front of him. Only the minimum required headroom. For a programmer, this is one task. Try to give this idea to a manager who is a Lean expert - he won't even understand what it is about, because Skipped the section on protecting performers when I read the Wikipedia article on Lean Manufacturing.
In the Theory of Constraints, which is about reserves, protection of the executing link is generally a basic postulate. Where programmers sit, they are almost always a bottleneck. What does the CBT say about the bottleneck? That's right - he must be protected. Remove all non-core workload (including scheduling your own work), avoid downtime, and don't caulk your brains with stupid questions and meetings. Organize the flow of work at the speed at which the bottleneck works. Well, managers-experts in TOC, admit it - have you been thinking for a long time about how to protect programmers from any stupidity?
Well, Scrum is all about flow. There, the principle "do not interfere with people to work" is elevated to an absolute, and is expressed in the requirement for maximum team autonomy during the sprint. After - please come, see what happened, choose tasks for the next race, poke around in the shower. During the sprint, don't even breathe nearby. Who works in Scrum - what do you say? Nobody touches you during the sprint, huh?
Total
Wherever you spit, everywhere you need a flow. For the programmer to sit down and just program. I didn't calculate deadlines, didn't fantasize about labor costs, didn't rearrange priorities a hundred times, didn't attend meetings, didn't participate in idiotic correspondence and chats.
However, wherever you spit, there is no flow anywhere. Whichever approach is used, the manager, or the client, or some idiot will find a reason to wrest the programmer from the harmonious creative flow for some insanely important nonsense.
You can always return to the stream. Or return. Need, however, will - and to return, and to maintain. The itch of constant monitoring of the programmer's work does not give rest. Especially those who do not understand anything in the work of a programmer.