In the last installment, we talked about reasons that velocity goes up without any more accomplishment by the team. This is a disturbing occurrence to many managers who want to use velocity as a measure of productivity, and their insistence on treating low velocity as a productivity measure.
We'll pick up the conversation from there.
There are a few ways of measuring efficiency. One of the least useful is output over time. If one team of people produce more in a week than another, isn't the one more efficient? It's not possible to say.
They may put out a disproportionate amount of effort in order to get a higher yield. That could be arguably more productive but it is not more efficient. If it's harder to get more work done, then you have a kind of productivity that won't scale and won't sustain.
People eventually get tired of working harder. They eventually come to resent longer hours. When the work doesn't get easier and there is always more of it, the team will lack profluence and will become demoralized.
Another way of seeing efficiency is energy used over output produced. There are some very easy ways to produce a lot of output. Almost all of these are horrible ideas. A copy-paste artist on the team can produce hundreds or thousands more lines of code than an experienced programmer who understands the system. It seems like "more output" but it's mostly waste -- a copy-paste artist will use 1000 lines of code where an expert needs maybe three. The copy-paste artist will create rampant duplication in the codebase which makes the code harder to maintain, slower to compile, and larger in-memory footprint. That's before we talk about the quality and safety of their approaches.
My favorite is effort over outcome. If I can get just as good a result with 15 minutes today or by putting in four days of hard work then it's more efficient to do it in 15 minutes. This is a flexible idea, because one can define the result they wish to see. There is always quality to consider in choosing an outcome. If my 15 minutes is a dirty hack that degrades the design of the code so people cannot make changes without causing defects, then it's probably an outcome we can't afford.
Luckily, there are techniques and skills involved here. If we do a good job of code craft, we can make a system easy to change safely. These are skills that Josh Kerievsky has called "tech safety." I like the term. To move safely and efficiently sounds like programming nirvana.
One of the more frustrating problems of being a boss is that people are afraid to tell you things and they're afraid to ask you things. It's quite annoying. Concerns of role success tend to taint everyday events. Even though it should be part of the job to keep one's managers informed, more employees tend to keep the managers away instead.
Especially if the managers are scary; if they make demands, if they insist on results the team doesn't know how to provide. If they cancel vacations or demand long hours, then they'll likely be seen as tyrants; this shuts down communication.
People will tend to avoid having unpleasant and unsupportive interactions. As a result they won't come to managers to ask for support and they won't bring bad news to the manager. They will hide. They will go dark.
Avoid this problem.
There are few things more powerful and rich in learning than to get involved with a team that is doing the work. You can learn how much of a struggle the daily tasks are, or how dull. You can see how much the team is impeded by interruption, risk, and uncertainty.
One can establish a relationship of honest feedback with others regardless of position in a hierarchy. It has to do with respect and straightforward communication, but also with support and relationship.
We can often assume that "working harder" is the answer. There is a disconcerting belief that workers are withholding their effort and only a stern word or motivational speech from their manager will get them to actually make an effort. This is a wrong and dangerous idea. Even when it seems true it is the wrong dangerous idea to have.
Peter Scholtes said this:
Join us for Part X when we talk about learning, experimenting, and accelerating processes.
We'll pick up the conversation from there.
A: I don't like the "estimating in larger numbers" explanation. What is an alternative explanation?
B: Perhaps they've developed skills, knowledge, and/or techniques that make it easier to get more work done.
There are a few ways of measuring efficiency. One of the least useful is output over time. If one team of people produce more in a week than another, isn't the one more efficient? It's not possible to say.
They may put out a disproportionate amount of effort in order to get a higher yield. That could be arguably more productive but it is not more efficient. If it's harder to get more work done, then you have a kind of productivity that won't scale and won't sustain.
People eventually get tired of working harder. They eventually come to resent longer hours. When the work doesn't get easier and there is always more of it, the team will lack profluence and will become demoralized.
Another way of seeing efficiency is energy used over output produced. There are some very easy ways to produce a lot of output. Almost all of these are horrible ideas. A copy-paste artist on the team can produce hundreds or thousands more lines of code than an experienced programmer who understands the system. It seems like "more output" but it's mostly waste -- a copy-paste artist will use 1000 lines of code where an expert needs maybe three. The copy-paste artist will create rampant duplication in the codebase which makes the code harder to maintain, slower to compile, and larger in-memory footprint. That's before we talk about the quality and safety of their approaches.
My favorite is effort over outcome. If I can get just as good a result with 15 minutes today or by putting in four days of hard work then it's more efficient to do it in 15 minutes. This is a flexible idea, because one can define the result they wish to see. There is always quality to consider in choosing an outcome. If my 15 minutes is a dirty hack that degrades the design of the code so people cannot make changes without causing defects, then it's probably an outcome we can't afford.
Luckily, there are techniques and skills involved here. If we do a good job of code craft, we can make a system easy to change safely. These are skills that Josh Kerievsky has called "tech safety." I like the term. To move safely and efficiently sounds like programming nirvana.
A: How do I know if that's the case?
B: Have you spoken with them?
A: I've told them how important it is that they go faster. What else do you want me to tell them?
B: Have you asked them, and listened?
A: If it is important, shouldn't they just tell me?
One of the more frustrating problems of being a boss is that people are afraid to tell you things and they're afraid to ask you things. It's quite annoying. Concerns of role success tend to taint everyday events. Even though it should be part of the job to keep one's managers informed, more employees tend to keep the managers away instead.
Especially if the managers are scary; if they make demands, if they insist on results the team doesn't know how to provide. If they cancel vacations or demand long hours, then they'll likely be seen as tyrants; this shuts down communication.
People will tend to avoid having unpleasant and unsupportive interactions. As a result they won't come to managers to ask for support and they won't bring bad news to the manager. They will hide. They will go dark.
Avoid this problem.
There are few things more powerful and rich in learning than to get involved with a team that is doing the work. You can learn how much of a struggle the daily tasks are, or how dull. You can see how much the team is impeded by interruption, risk, and uncertainty.
One can establish a relationship of honest feedback with others regardless of position in a hierarchy. It has to do with respect and straightforward communication, but also with support and relationship.
B: Notice that they've gone from 19 to 23 points & you don't know how they did it.
A: I assumed that they went from 19 to 23 because they're working harder.
B: Yes, you did.
We can often assume that "working harder" is the answer. There is a disconcerting belief that workers are withholding their effort and only a stern word or motivational speech from their manager will get them to actually make an effort. This is a wrong and dangerous idea. Even when it seems true it is the wrong dangerous idea to have.
Peter Scholtes said this:
The greatest managerial cynicism is that workers are withholding a certain amount of effort that must be bribed from them by means of various incentives, rewards, contests, or merit pay programs. Most managers are not conscious of such a pessimistic belief, but many of their "motivational programs" are conducted as though this cynical premise were true.We don't want our people to be working harder. We want them to be more accomplished. If we conflate the goals then we are in the kinds of problems we discussed in Part V when we said "take away their tools." Making their lives hard does nothing useful for the bottom line.
Join us for Part X when we talk about learning, experimenting, and accelerating processes.
No comments:
Post a Comment