I believe in giving positive feedback. While doing research for a big post that explains how to use these positive educational techniques with your (agile) team, I encountered this scientific fact:
Giving constant positive feedback works less good as positive feedback given at variable ratio or with a variable interval.
In fact people that are giving constant positive feedback, have a hard time when things go not as they want. Their frustration level is much lower.
Aggggh my eldest boy frustration level is not as high as we want. So this tells me we have stimulated it.
When I think about it,I should have known as the opposite I know:
The consistency of the “punishment” is very important.If you are not consistent with a punishment it will not work. A lot of parents (and team leaders) have a problem doing this. What they forget is that every time they don’t punish the children (Team members) get a negative ratification when the punishment does not follow the behavior. These people are then surprised they don’t get the desired effect.
Let’s look at a few examples:
When you put money in a candy machine and you get no candy.==> you stop immediately . You know that this is not normal.
When the candy machine works:
Put in money ==> action
you get candy. ==> constant positive feedback
When this does not happen: we stop immediately.
Now look at this gambling machine:
Imagine it is broken. You put money in it. You get nothing back. What will you do?
When the 1 arm bandit works:
Put in money ==> action
you win or not ==> positive feedback is given at a variable ratio. So we don’t give in that fast.
Source:Psychology Marc Brysbaert
Last week I used the old building a house metaphor again during interview when I was asked to explain agile in 3 minutes to people who never heard of agile.
3 minutes is of course not enough so I will take some more time here.
- Have you ever (re) build a house? Did you know up front what you (and your partner) wanted?
Think about this. We all live in houses for at least 20 years before we build our own house. We have seen at least 50 different houses from the inside. And yet no-body I know, knows upfront what they want. We need an expert (architect) to ask the right question to figure that out. Then that person comes up with a plan. A plan most of us don’t understand. My father-in-law is such an architect. For 11 years I have been looking at his plans. I can say that now I understand them. Yet, from time to time I see a house that looks different from what I would have understood from the plans. And I have seen lot’s of plans in these 11 years.
So do you expect your end users to know what they want for software. Software that is more abstract then a house. Software that most people only work with a few years (instead of at least 20years)
- How many times did you visit the house they were building?
In the non agile world, the team delivers the software at the end. Can you imagine to go and look at the house only when it is finished? Nah no me, I go and look at it every month, every week, sometimes even every day to see how it is going. It’s not that I don’t trust them, it’s more that I don’t trust my own opinion about the plans. I want to test the house to see if it is really what I want.
- How about changing idea’s?
I still remember a story from my father-in-law about a customer that had most parts of the house build. That is the structure was there. The electricity, the water etc still had to be done. The customer walked in the house and decided the bathroom was on the wrong floor. So he asked Jean-Pierre to re-design the house, during the construction. It costed that customer a fortune. So what? It’s his money, and no he is happy for the rest of his life. Oh yes they had a big contract etc, but who cares, he realized that the bathroom was in the wrong place and it would make his life miserable when it stayed there. And don’t take this for a one-time event, this happens all the time in construction. Check out the article on lean construction from the Poppendiecks.
When I bought my old house, we did not start rebuilding it. We first wanted to see the advantages and dis-advantages of the current state. Now we lived in it for 5 years we know better what we want to change and how. The same can be told about software. When you build version 2.0 software, make sure you have an end-user that you have direct access to.
People who care about refactoring and changing old programs should read the book: How Buildings learn, what happens after they are build
Did you know in some countries you don’t need a blueprint to build a house? Did you know in some countries you are allowed to design your own plan(just once) Did you know in some countries people first build the main floor and then a few years later (when the kids arrive?) they add a second floor. And a third even later. And yes they have to rearrange the first floor to add the stairs. Big deal they lived in the house without the stairs for a couple of years
Technorati Tags: Agile