There are twelve principles in the Agile Manifesto. The fifth one says: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” I disagree. Strongly. This formula suggests treating people in a binary way: they are either motivated and trusted or … what? They have to be let go? This mindset is very typical, according to my observations, and leads to poor management and project failures. Instead, our people management must be more iterative and much less rigid.
Just a few days ago I posted a quote from Code Ahead, my recent book about software engineering, on Instagram. I’ve got an interesting and very typical response from one of my readers (polished a bit):
Why should I get punished in the first place; if my mistake is unforgiven they should fire me, and I believe this is less humiliating than getting punished and then staying with them.
This is what I hear almost always when I start talking about rewards and punishment in a software team. I hear that it is humiliating and programmers should never be punished. Instead, as Samir suggested, they should be fired when they make an unforgiven mistake. Thus, we either trust them 100% or, when a mistake happens, we … fire the bloody bastard, he was useless anyway!
Well, maybe this is part of human nature: First we love, then we hate, and the stronger we love, the stronger we hate. But what do these emotions have to do with professional project management?
As William Edwards Deming suggested many years ago, good management is always about a simple Plan-Do-Check-Act cycle. No matter what and who we manage, we have to plan first, let ourselves and our people do the work, then check what the results look like, comparing them with our plans, and finally act according to the findings, correcting the plans. Then, we go back to the planning part and the cycle starts over again:
We all know that this is how software has to be developed. Many years ago we all realized that a Waterfall model, where everything was planned upfront and then implemented according to the plans, which didn’t change during the course of the project, was a bad idea. A much better idea is to deliver the software incrementally, making changes to the plans and specifications after each iteration. This guarantees higher quality, faster reaction to mistakes, and a much better predictability. It’s obvious, right?
Why don’t we do the same with people? Why do we motivate them upfront and then trust them … until they turn out to be completely untrustworthy? Can’t we regularly check how they are performing and correct our trust accordingly? Why are they either “great” for us or “useless”? Why can’t we grade them after each iteration, according to both mistakes and achievements they make?
Let’s see how the formula that Agile suggests can be applied to the PDCA continuum:
- Plan: Find individuals and motivate them
- Do: Trust them and they get the job done
- Check: —
- Act: —
It seems that two important pieces are missing. We don’t check whether we can still trust them, whether they are still motivated, whether they are interested in getting the job done, and whether it’s time to replace some of them.
Why so? What are we afraid of?
Moreover, why do programmers find it humiliating when their results are being regularly checked, leading to micro rewards and penalties, while at the same time they find it totally OK to be fired for a single “unforgiven” mistake?
I have an answer.
Because their managers are weak and stupid, in most cases. They simply don’t know how to reward and penalize programmers incrementally. They don’t know how to measure the progress of people, incrementally. Their control instruments are based on guilt and fear: They put programmers together, brainwash motivate them, and then make them scared of making an unforgivable mistake.
What exactly that mistake is, nobody really knows—it’s a personal decision of a manager. It could be a broken unit test, a missed meeting, a rude email, or drinking in the office. The scale is very wide and at which point the programmer will be fired, nobody knows either. Even the manager can’t explain it. The decision in most cases is emotional and personal.
You know that a very typical mistake in scope management is treating large tasks with the 0/100 completeness rule: they are either “not even started” or “fully complete,” and nothing in the middle. You can do that with small tasks, but never with large ones, because it will lead to lack of control and much higher risk of more expensive failures. You must break your scope into smaller pieces and then apply the 0/100 rule.
The same is true about people. You can’t trust them 0/100: either you trust them fully or you fire them. This is too risky. You have to decompose their trustworthiness and their motivation into smaller pieces and deliver your satisfaction and frustration incrementally. How do you do that? Via micro-bonuses and micro-penalties.
How else?
Published on Java Code Geeks with permission by Yegor Bugayenko, partner at our JCG program. See the original article here: Trust Them to Get the Job Done, Not! Opinions expressed by Java Code Geeks contributors are their own. |
