Responsibility in Command And Control vs Self Management

As a child, most of us are taught to respect authority whether directly or indirectly in school. We obey our parents, we obey teachers. If we don’t, out comes the wooden spoon.

This learning carries on throughout life, well for most people. We respect police, our managers etc. It gets so ingrained, that all it takes is for someone to be dressed in a manner that garners respect. A uniform, a suit, a lab coat, that we blindly follow.

In the 60’s, when ethical standards were more lax, Stanley Milgrim conducted an experiment. He wanted to know, after World War II, how people could do atrocities to other people. Was there something different about the Germans that made them more callus than everyone else? To test his theory, he conducted an experiment.

The experiment was simple, there were 2 subjects. A Teacher and a Learner and the technician in a lab coat who would conduct the experiment. The teacher and the technician were in one room, and the learner was in another room, strapped to a chair so they could not escape and hooked up with wires. The experiment was simple. The teacher would ask a question to the learner, specifically about word pairs. If the learner answered the question incorrectly, the teacher would press a button, administering an electric shock to the learner.  The premise being that the learner will learn the word pairs more quickly with a pain incentive. Did I mention that ethical standards were more lax in the 60’s.
Well, as the learner kept getting answers wrong, the electric shocks grew in intensity.  15 volt increments up to 450 volts. 30 incorrect answers.
At those voltages, the learner would scream, plead for the teacher to stop. Beg for the teacher to stop. The pain was so intense.
Now, if the teacher started refusing to participate, the lab technician would say “Please Continue”. If the teacher refused a second time, they were simply told “The experiment requires you to continue”. A third time, they were told “It is absolutely essential that you continue” and finally if a fourth time “You have no other choice, you must go on”. There was no coercion,  the teacher was just told in a calm voice.  If the Teacher refused to comply a fifth time, the experiment ended. How do you think you would go in this experiment?
Well, 65% of teachers participants reached the maximum of 450 Volts. Many teachers were uncomfortable doing so, but still continued eventually when asked to. It got to the point where the learner was in so much pain, they either passed out, or worse. This experiment wasn’t conducted in Nazi Germany, it was in Yale University United States.

If you are absolutely horrified by now, take comfort, the Learner wasn’t really under pain. They were an actor. There were no shocks given. The Teacher was the only subject of the experiment.

So why did the Teachers continue, well simply put, psychologically, they put the responsibility of their actions onto the Lab Technician. Any consequences of the teachers actions were considered borne by the Lab Technician. That is how that 65% of teachers administered a fatal electric shock to a learner.

So, what does this have to do with Agile? Well, with traditional management, you have a heavy Command And Control mentality. A person is in charge, the manager, direct their underlings towards what needs to be done, and the underlings blindly follow. The underlings may have some say, but ultimately responsibility lies with the manager. Whether in actuality, or psychologically. The underling relies on their direction.

Yes, they may speak up if they think something is wrong, but if told, “That is the way we are going to do it” will go along if told enough times. It takes a special person to give it their all and dissent when they feel they are right. Most people won’t speak up at all. They will just “switch off” and do what they are told.

In many Agile methodologies, especially Scrum, there is no real leader. With Scrum, there are 3 roles. The team, The Product Owner, who isn’t in charge of the team. They are only in charge of the what is made, the Scrum Master who is there to help and guide the team. They do not direct the team. They do not command the team. There are no leaders in the traditional Command and Control sense. The team needs to be self organized. Giving the team this responsibility means that there is no one to shirk responsibility to. You cannot say “Something went wrong because we followed the manager”. Everyone in the team has a say, everyone in the team is responsible. Everyone in the team needs to participate in the decision making process.  Everyone in the team needs to be at the same level. No hierarchy. The team itself is able to choose its own destiny on how it accomplishes the task. Not a “leader” within the team. In other words, they have created their own purpose.

I know what you are thinking, this can get into a Lord Of The Flies situation. The team goes off on a tangent, All hell breaks loose and you have complete Anarchy.  Nothing gets done.
Well, I doubt this will happen. Most people try to do the right thing. Even those in unskilled jobs try to do the right thing. Try to do an honest days work. If you still don’t think this will work, In scrum, there is the scrum master. The scrum master is there to guide the team back on target. In Toyota, from what I have read, there are traditional manager roles, but the managers there don’t manage in the traditional sense. They guide their workers rather than command their workers. Still not convinced, look up NUMMI.

Working this way can become very powerful for a company. Your workers are now no longer there to just complete tasks assigned. They are there to accomplish a goal in a manner that they chose. They are there to learn and grow. They have purpose and a level of dedication that you would not normally see.

Just remember,  don’t abuse it. This is a very delicate balance. Start bringing in command and control policies and people become disillusioned again. The whole thing can fall into a heap and you might be worse off.

Let me know what you think in the comments. If you work in a Command Control situation, do you “switch off” and do what you are told or are you actively involved?

If you work in a team that has more control of their destiny, do you find you are more involved in reaching the goal or has things degraded so much it feels like a “Lord Of The Flies” situation.

The Cube of Rubik

Its been a while since I did my last major post. Actually, before Christmas. So what happened. I got myself a Rubik’s cube (Well, a cheap knock off from eBay) and learned how to solve it.

My Solved Cube

I watched YouTube videos and learned the beginners methods. I can now after 30 years of getting my first cube, solve it.

I got lots of practice at solving. I get my 5 yo son to mix it up. He loves doing that, and now the quickest I can solve the cube is about 1 minute 37 seconds. Most of the time its around 2-3 minutes.

Sounds impressive, but its actually pretty pathetic. The world record for a solve is under 5 seconds. Yes, 4.73 seconds to be exact.

Now, the method that I’m using, if I didn’t know any better could get me down to around a minute if I get more practice and get better. If I didn’t know any better about the world record, I would think that that would be impressive. But, in order to get faster, I need to change the way I solve the cube.

So how is this related to Agile, well, a lot of people think that getting a task done quicker means you just need to work quicker. Cracking the whip, giving carrots etc will get things done quicker. In my above example with the Rubik’s cube, that will only reduce my time by about 33%. Still an impressive number, but sometimes, if you try to do things differently, if I learn the expert method of solving the cube, which by the way is a lot harder to learn than the beginners method, I might, just might get faster. If I learn the expert method of solving the cube, which by the way is a lot harder to learn than the beginners method. In fact, when I start trying the expert method, my solving time will get significantly worse before it gets better.  I have read that I can reduce my time comfortably down to 30 seconds. That is a 60% reduction of my current best. The same thing can be done potentially with any task up to a limit.

So, if you are trying to increase your personal or team velocity, but remember you are trying to keep quality at a high level, not skimp on any value, then think about trying something differently. If the method has been tried and tested by someone else. Stick with it. Your velocity might suffer in the short term as you get use to the new way of doing things. That’s OK. You’re learning. Stick with it and you may find that as you get better, you will get significantly faster.

Failure Is Not An Option, It is a Requirement

Hope you had a good Christmas and Happy New Year!

This post is for an idea I have for a retrospective. It is not something I have tried yet. Hoping to do so at some point.

Here is the gist of it.

At the end of the previous retrospective, outline the goals for the next sprint for the next retrospective. The goal is… to fail.

I know, insane, but I am insane, so lets move on and let me explain myself.

Each time something does something wrong during the sprint, record the following.

  • The failure.
  • What caused the failure
  • What can be done to fix the failure

Points are awarded based on the the following.

For the failure – 1 point.

For What caused the failure, for immediate cause, 1 point. For root cause 3 points.

For What can be done to fix the failure, 1 point for a work around. 1 point for a manual process. 2 points for an automated process or documenting a way to remove it permanently . 3 points for making the failure never happen again. Now, for everyone involved in the solution, they all get the points. Not just the person who came up with the solution, nor the person who failed in the first place. This is to try to promote co-operation in solving problems.

Here is the kicker, everyone must have at least one failure. The way we do that is that everyone must fail at least once on purpose. That is right, I want everyone to have one failure on purpose. The more exotic the better. (For a really good one, award 2 points for the failure). Hopefully killing the system isn’t their on purpose failure.

Points can be placed on a board so that throughout the sprint, everyone knows the tally, the scrum master awards points and their say is final.

So, why do this?

Well, firstly, as I mentioned previously, I’m insane. So again, accept that and move on.

Secondly, I work in a place where failure has a stigma against it. There is finger pointing within the team. By making failure as part of the game, hopefully this removes the finger pointing. The focus then goes onto solving the problem rather than finger pointing.

Thirdly, by making failure open, you get to see where your weaknesses are, and ways to solve those weaknesses. This is the opposite of current culture where successes are focused on and celebrated, failures are hidden so you never know when problems occur.

Finally, by making failure a requirement, it removes the fear of failure. Hopefully you get to the point where people fight to take ownership of a failure.

Now, at the end of the sprint, during the retrospective. Go through the results.  For those results that have workarounds, or manual processes, try to improve them. Tease out what lessons have been learned during the sprint from failing. Any permanent solutions documented, decide whether to add them to the backlog.

Now, for the person who gets the most points, award them with a token prize. For example a block of chocolate. For second and/or third, a chocolate bar.

Finally, see if the team enjoyed this method of Retrospective, if it was valuable and if they want to do it at another point in time.

Please let me know in the comments if you tried this and how it worked. If I ever get a chance to try this out, I’ll be creating a new post.