Over at Reddit there is a discussion about my Stop Per-Person Swimlanes article at Industrial Logic.
This surfaced what seems to be a common misunderstanding.
Some people think that the board was designed to facilitate public shaming.
It's to motivate members in a team to work harder. When your personal progress and responsibilities are put on a clearly visible chart somewhere it's a bit different than a sea of todo's some of which are labeled with your name.There are a lot of answers, agreeing or disagreeing (mostly disagreeing). This one stands out:
It's different. Whether it's a good thing or a bad thing is EXTREMELY unclear.
My take is that in most corporate environments that is a BAD thing. Why? Because, rather than thinking about the overall health of the code, coder's main concern is getting that ticket closed [emphasis mine - tro].
Which is a very straight path to the quick codebase degradation.
Meanwhile, your velocity is high and management is happy while the project is quickly running into the ground.
This brings us to our topic of the day: Plate-Emptying.
 |
| Charlie developed a technique for getting the veggies off of his plate. |
Plate Emptying - However silly it sounds...
Plate-emptying describes any behaviors which aim to increase performance in the small by minimizing the touch-time for each subtask performed.
I have witnessed it wherever there is pressure put on people to "finish quickly," or to "increase velocity" without any sort of work off-loading. It's especially visible where issues of quality are downplayed compared to speed task completion.
A pathological made-up story:
Imagine your dentist's office is running behind. The oral hygienist skips cleaning your teeth, gives you the bill for work not done, and sends you home. Pretty soon the office is back on schedule and has more billed time on the books than usual!
Imagine that the dentist who heads the practice gives that hygienist a raise, and berates the others for being comparatively unproductive.
Yes, that's absurd. But stay with me here, because many software companies operate by rewarding those who give their work short shrift and declare early completion for work partly done. Often they drive out developers who are more complete and disciplined in their work.
But... this is SOFTWARE!!!
Yes, I know that software development is rumored to be a low-stress occupation, pleasant and quiet, with good rates and plentiful employment. That is not how many corporate programmers experience it. In fact, their lives seem to be full of death marches, which are causing mental health issues with plentiful stress.
Managers are in a horrible crunch most of the time. Big customers demand, and therefore are promised, a lot of work.
In software, everything is ASAP (or presented as if it is, to keep "motivation" high).
True Story:
Managers had a significant defect backlog (tens of thousands) and were talking about two teams.
One team is methodical, and sometimes could take a day or two to fix a defect, but they were always truly fixed and passed through testing and to deployment without any issues.
The other team emptied their plate quickly usually in less than a half-day, but often had to revisit the same bug several times because their fixes didn't always really work or sometimes had troubling side effects.
After deliberation, the managers decided to give the lion's share of bugs to the latter team because "they get things done faster."
I suppose "done" in this case refers to plate-emptying, not full completion and deployment. All the numbers showed that tasks given to the "fast" team took considerably longer to deliver due to the rework involved, once you count in the round-trips to QA and the rework. But they only looked at micro-efficiency, not at the throughput of the whole system.
Another true story, titled "Heisenberg Developers" was posted and came to my attention via twitter.
If we use an industrial era kind of thinking, then we are limited by the speed of the slowest component in the chain, and since apparently software is the work of people, it is obvious that we need all the people to do their work faster.
Surely, if everyone works faster, the whole line will be moving at maximum speed, and therefore the product will be done as soon as possible (in software, everything is ASAP!).
The clear, simple, obvious answer, then is to get each person to do their fastest work. We will hold them to a short turn-around and reward them for reducing their time budget for the work being done.
And since there is too much work, we need to start it as soon as possible by cramming it all into a queue until development staff (coders, testers, etc) are split between several (sometimes dozens) of tasks. They will "just have to multitask."
What could go wrong?
Note how this theory of "go faster by rushing everyone" avoids looking at workflow and queues and Little's law, and all the things we've learned about multitasking and cognitive function, and the basic principles of knowledge work and Lean management. This is conveniently, obviously, simply, horribly wrong thinking here.
Nobody was counting the system's time, only the worker's time.
Nobody is counting the wait states, only the touch-time.
Lean thinking teaches us to watch lead time, and to understand the system. That keeps our optimization processes focused on actual bottlenecks and constraints.
However, functional managers (over programming, over testing, over documentation, etc) don't have authority or influence over the entire system, and tend to focus on their realm of influence -- their specific function. I can hardly blame them.
So what happens?
When a designer has too much work on his plate, he can always "abandon as done" when he has a rough idea, a couple of sketches, a wireframe, a spreadsheet, or maybe a proof of concept in powerpoint or visual basic. That's close enough, and we need to get this off his plate (and onto someone else's). Sometimes it's "close enough" and developers will figure it out but if not, it will come back from UX or Acceptance testing and can be handled then. If it gets out the door and customers don't like it, we can handle it with customer service and fix it in next release (taking it off the designer's plate for weeks or maybe months).
An architect's best tool for plate-emptying is to just say "no," since it is faster than evaluating an alternative, and after all there is so much to do. Sadly, the architect is usually valued for how many things she has in process at once, rather than for her rate of completion or overall impact on the project. It hardly makes sense to defer, delegate, or refuse when one is being graded on how busy one is.
A developer will probably short quality and avoid deep thinking about side effects and consequences, and avoid meetings and discussions by making guesses. After all, it has to go through testing anyway and they'll send back any code that doesn't really work (well enough).
There isn't time to spend on this feature, so she should not bother with refactoring and test-driving and pairing or reviewing. Those things feel like "taking time for quality" and she is being rewarded (reputation-wise at least) for turning things around quickly; emptying her plate.
A tester will probably have to decide which tests he will not run this time, so that he can move forward quickly. Perhaps he can downgrade the severity of some bugs. Returning it to the developer will get it off his plate fastest, and is safer because testers tend to be blamed for every defect not caught.
Of course, there may be bug teams. My "true story" above describes how that works.
Let's not get into operations. There is no place that plate-emptying stress is higher, and tolerance for errors is lower. You've got to love ops people, because everything is an emergency and nothing is appreciated, and they still show up. In fact, they show up at insane hours and weekends and holidays and such. They miss the kids' little league games and family birthdays. They work Christmas eve. Give your operations team some love; do something to make their job easier.
Customer support is held to tight schedules. How can they empty their plate faster? What if they pass a client off to some other representative? What if they just give some stock advice and abandon the user? What if they just recommend "reboot and call back"? We have all seen instances of tech support people held to a standard of "45 seconds per call" so that they empty the queue rather than serving the customers.
Managers have to deal with plate emptying, too. They have to manage people less and shuffle lists and calendars more in order to keep up with the activity, all the while pushing to increase that very burden. Sometimes people-centric mentors who make it up the ranks are stuck being "meeting denizens" instead of really managing projects and people the way they always wanted to.
What About Agile?
When agile goes well, it makes good workmanship (craftsmanship) and good decision-making possible. It reduces stress and rework for everyone involved, and has a greater solidarity across roles due to the use of cross-functional teams.
Ideally, agile methods make it possible for teams to work at a sustainable pace, and focus on value rather than quantity. There is focus on economy of scope rather than economy of scale.
In particular, modern agile is built on safety, continuous definition and delivery of value, and continuous learning. Perhaps this is the way it was always supposed to be.
BUT, what we tend to see in many organizations is a fascination with velocity. When teams have pressure to not only take on the maximum workload but also to complete it within a too-short fixed period, they become exhausted and frustrated, and are driven to obsessive plate-emptying behaviors.
This is all about the stress-performance curve at that point. Developers are stressed and exhausted past the point where they have good cognitive function, and plate-emptying is all that is really left for them.
Isn't That A Good Thing?
Yes, I realize that "the perfect is the enemy of the good" and that people really don't have time for infinite gold-plating and "cadillac" answers. Who can afford perfect code?
But no legitimate business can survive, having adopted "quick and dirty" as its standard of excellence.
Adding sufficient design and reasonable automated tests, software is transformed until most changes become reasonably easy and quickly-performed. Not all changes become "easy" but they become easier than they would be had the code been allowed to decline into a comical and tragic mess.
Many times plate-emptying delays release of useful software by weeks or months.
And, thanks to Singh's Inevitable Avoidance, companies whose developers, testers, customer service, and operations have been playing "hot potato" with defects for months or years have developed much more efficient ways of playing hot potato, and have even come up with metrics to show how efficiently they are improving the speed of hand-offs.
Often focusing on "minimal touch time" creates unproductive (even counter-productive) pressures, which in turn result in release disasters, interpersonal conflict, and loss of staff.
Despite what you might read sometimes, being a software developer in some companies is disturbingly stressful to the point of causing stress-related illnesses and panic attacks up to six months later.
I suspect (and observe) that the reason behind poor craftsmanship, poor support, and poor service is often pressure for individual plate-emptying rather cooperative completion of tasks. This pressure often results in practices like "rank-and-yank" (AKA "hunger games") where staff are retained or released based on speed of "productivity" measured in speed of plate-emptying.
Should We Bust Those Lazy Plate-Emptiers?
Blaming and shaming is generally useless. In this case it is also unfair. It is wrong to demand people do a thing, reward them for it, and then blame them for not resisting the system and refusing the rewards.
When I toured around the US with the "perfect day" exercise, I found that knowledge workers are almost never slackers. Their ambition, almost universally is to take on a problem that is hard (for them) and to work it to completion. A perfect day isn't "goofing off and playing video games at work" for them. It's doing good work and being respected for it.
So what's with the plate-emptying? What does it mean?
People are doing what they are doing because the system demands it and because they are too fatigued to fight it.
If you don't want people to abandon work for others to deal with, you have to give them enough time to work something to completion instead of racing through it to "get it off their plate." In doing the work, they must be encouraged to find ways to make doing a complete job better, faster, and more consistent. There isn't always such a way, but help people build habits that take a lot of stress and decision-making out of the equation.
It is hard for some to believe, but if you want next month's work to be faster, you have to spend a bit of this month improving the code that the developers will start with next month.
Deming said long ago that all anyone wants is to take pride in their work. We need work systems that respect the human limits of the people who do the work, and we must not solve intellectual problems with brute force (more hours, more people, more typing).
Alternatively, most programmers I know have had a job in the past where pressure and plate-emptying were common practice, and sometimes these practices are carried into new job situations where plate-emptying behaviors are unnecessary and unwanted.
It's good to reflect on where you are, and what is most important to your customers.
No comments:
Post a Comment