When I was a kid, back in the twilight between the late 70’s and early 80’s, a bunch of us neighborhood younglings used to meet up after dinnertime at a small field to play together. Not a lot of planning needed, a couple of us would just agree to meet and then the word spread. One of us brought a soccerball and someone else brought a tennis ball and a bat for rounders. Most of us knew each other to some degree but every now and then a new kid had moved in or someone would bring a friend from outside. We were usually about 5-15 kids and we used to decide there and then on what to do; soccer, rounders, hide and seek or some other game. If we decided on soccer a couple of us would take our sweaters off and then we used them as goal posts. Someone would volunteer to be goalie or we’d decide to take turns. And then we played until our parents called us in for bedtime.

Last night I got to experience something similar once again. My good friend Daniel called a couple of days ago asking if I wanted to come along for night caching with him and some other guys. I like geocaching but for me it’s mostly about getting to be outdoors with the kids every now and then whereas Daniel and the other guys have made this hobby into an artform and a gadget sport.

Night caching

Anyway, we met up after dinnertime, but this time it was initiated by an email and then someone called someone else and someone brought a friend and we finally ended up being seven men in the rough range of 35-50 years old. Some of us knew some others quite well, other’s had met briefly and for me this was a totally new crowd except for Daniel. But we had one common goal; to follow three reflective trails in the woods and solve puzzles along the way that noone had managed to solve before us. We would do this in order to find a fourth trail and the final prize; the FTF (being the First To Find the cache).

Armed with head lamps, UV-light, cameras, pens, paper, GPS’s, smartphones and some candy we set off into the rainy darkness to find the solution to this riddle somewhere in a forest west of Stockholm.

Since everyone else were a lot more experienced than me in this area, I decided to observe and learn about this type of geocaching more than I would contribute to the solution. I did learn a lot about night caching but the self-organization and the self-steering that I got to observe and be a part of was beyond what I could have imagined.

The level of problem solving and cooperation needed to succeed was definitely comparable to building quite a complex piece of software (though more limited in size and time). Without anyone being appointed manager of this group, everyone quickly found roles to fill where they could contribute to the team. Not a lot of words where spoken regarding what to do, it just happened. A couple of the guys took the lead and started looking for the next reflective marker, a couple of us walked in the middle marking the ones we had found and a couple of guys followed after looking for clues that could help us solve the puzzle. Someone called out an idea, someone else went online to look for information. Someone tried out an idea, someone else was already working on the next hypothesis. Not a minute was wasted, and in what I would say was the shortest timeframe possible, without hurrying, we solved the puzzle piece by piece. Reiterating pieces of the puzzle where the first idea didn’t pan out but never getting too far astray since we were quick to put our ideas into practice.

Three hours later, after being the first people ever to sign the log, the seven of us could pat each other on the backs and go back to our cars and drive home to our families for a good night’s sleep.

When we were kids, we were united by the common goal of having some fun between dinner and bedtime. Last night we were united by the common goal of being the first ones to solve a complex problem. In both cases we succeeded very well with our missions, we had fun doing it, noone needed to manage us and we all found ways to be useful.

Do you remember what this felt like when you were a kid? That feeling of being creative, contributing to the game and not wanting to go home when your parents came for you. Do you want to experience it again? We should all be able to have that same feeling that kids have between dinner and bedtime. Every day. From 9 to 5.

About 20+ years ago, I worked one summer pulling cables at a construction site for a newspaper printing company. I was part of a team of about 8 persons and a team leader. For me, this was an internship over the summer, but the other guys were doing this for a living.

The job was quite easy; the team leader looked at the blue prints and told the rest of us what kind of cable to use, where to start and where to stop. Not being too mentally challenged by the task of pulling a cable from A to B, I tried to learn more about other stuff. I asked the team leader how to read the blue prints, I tried to learn more about the equipment being used at the site and so on. Then one day when I came to work, the entire team was sitting in a semi-circle on the floor, smoking and chatting. Our team leader hadn’t shown up since he’d caught one of those nasty summer colds. Not knowing how these things worked, I sat down with the rest of the team waiting for the signal to start working. After about half an hour or so, I realized that nothing was going to happen. We had lost our team leader, so the day would be spent sitting on the floor in a semi-circle smoking and chatting. I figured that this was probably not in the best interest of anyone so I picked up the blue print, looked at what needed to be done and asked the others to join me in pulling a couple of 5 core cables from one end of the building to one of the printing presses. I think I managed to get a couple of guys to help me with a handful of cables before everyone were sitting on the floor again and I realized that this was the way that I was going to spend this summers day.

Part of this experience probably should be used to reflect on my leadership abilities at the time. However, the real learning for me, looking back at it today was that this was a very specialized team without the motivation to self organize. Anyone of the team members could probably have read that blue print, but it wasn’t in their job description to do that and they sure as hell was not going to let a kid still in school tell them what to do either. Today, I see the same pattern in new Scrum teams. They start out as highly specialized member of their teams and if one person gets sick, it’s semi-circle-time again.

But now for something completely different …

Do you remember that scene with the black knight from “Monty Python And The Holy Grail”?

Whether you do or don’t, here it is:

I’d like to see that perseverance and problem solving in every team. “We’re here to solve a task and by God, we will do it … no matter what.”

The team loses a business analyst.

– Tis but a scratch.

The team loses a tester.

– Just a flesh wound.

The team loses it’s ScrumMaster.

– Come ‘ere. We’re invincible.

The team loses it’s back-end developer.

– We’ll bite your legs off!

The self organizing team must be able to heal itself, to lose a leg and still yell “Have at you! Come on then!”.

“Semi-circle” or “Just a flesh wound”?

Tester/developer/ScrumMaster or Team Member?

On a roll without a role

December 9, 2010

Like actors we all play several different roles in our lives because the roles help ourselves and others in our interactions. The roles set the expectations for how we should behave and interact.

At work we assume roles such as tester, developer, project manager etc. These roles also set the expectations for what we should do and know, with whom we should interact and how we should do it.

According to Merriam-Webster a role is “a socially expected behavior pattern usually determined by an individual’s status in a particular society.

Did you notice the word “status” in the previous paragraph? We tend to; implicitly or explicitly, associate our roles with some sort of status. Senior developers are better than their junior peers. Architects are better than developers of any rank. A test lead has to be better than a tester. A developer is either better or worse than a tester depending on if you’re a tester or a developer. A project manager outranks pretty much everyone.

For managers, these roles are a great way to put people in a box; to categorize people by the knowledge and experiences they are supposed to hold. Assigning someone a role also means that we can assign them responsibility, we know that the tester should do the testing, that the developer should do the developing and that the executive should do the executing (or whatever).

The concept of roles gives us predictability about people. And predictability is a good thing isn’t it?

Encyclopedia Britannica puts this predictability as: “… An individual may have a unique style, but this is exhibited within the boundaries of the expected behaviour.

But what if we act in a complex environment and want our teams to self-organize in order to cope with variability and complexity? Are the traits that I described above helpful in any way or would we be better off without the roles? My answer is that the traditional roles that we meet in our organizations are limiting our ability to self-organize.

Team members comfortable in a role usually won’t hesitate to assume the responsibilities associated with the role but … they also know where their responsibilities end. It is not when the problem is solved; it’s at the boundary with the next role. People who identify themselves with a role are often comfortable speaking with their peers but less so when it comes to communicating with other roles. If we have a perceived difference in status or rank it will drive the wedge even deeper.

A self-organizing team needs a number of different competencies to solve problems but it does not need these competencies to be locked inside roles. Communication among team members is the single most important factor for successful self-organization, but having preconceived expectations on who should communicate with whom is a limitation that we can do without.

Many organizations have templates for the parts needed in a project team. “We need one architect, two programmers, two testers, one test lead, a project manager and one project coordinator.” Really? Are you really sure that you need these roles? Could it be that you need a number of competencies that will ensure the structural integrity and the quality of the product. Perhaps you also need people who understand the importance of communicating with stakeholders and other teams.

I do believe that a team without assigned roles will become more fractal in the sense that each competence will be found in each of the team members (higher truck numbers). The team will be able to communicate between competencies. The team will share responsibility for delivering a high quality product without throwing work over the fence.

Doing away with roles also means that some managers will have to learn how to treat employees as individuals instead of as typecasted resources and throw away their old models for seniority and wage ladders and … and nevermind, I guess this might have been a naive daydream after all.

Ok, why wasn’t I told about this before? I was probably one of the last people in the world to find out about it. But what an epiphany when I did find out about Ashby’s law of requisite variety. It seems so intuitive that it bothers me it’s not called Morgan’s law of requisite variety.

“If a system is to be stable the number of states of its control mechanism must be greater than or equal to the number of states in the system being controlled.”
or
“The larger the variety of actions available to a control system, the larger the variety of perturbations it is able to compensate.”

Of course! If we want to control something we need at least as many degrees of freedom as the system under consideration. Why on earth didn’t I see that. Well now that it has been brought to my attention it makes several things so much clearer. One of the most important implications that comes to mind is self organization. If we want to handle a complex problem, we’ll need to be able parry it’s possible moves. Giving one manager the responsibility to handle a complex project leaves us to the mercy of his/her limited model of the world. Giving an entire team the responsibility to handle the same project gives us an almost infinite number of possible combinations of experiences more fit to handle the whims of a chaotic world.

The agile movement helped me realize the benefits of self organization several years ago but Ashby just recently gave me the actual proof for why it’s working.

So to paraphrase that old t-shirt slogan:
Self organization – it’s not just a good idea; it’s the law.