Mistaking group thought for collective intelligence

Sometimes you become a part of tightly knit team. You seem to almost think the same things and solutions just comes flowing. What you probably have felt is something Daniel Goleman in his book Social Intelligence refer to as Rapport. It’s one of the most rewarding social connections and the ability to Rapport is a crucial part of social intelligence and well being. And often a team with Rapport can be very productive.

But there are also risks. As James Surowiecki points out in The Wisdom of Crowds, this forming of the tight, homogenous group gives ground to group thought in a negative sense. Surowiecki gives a lot of examples of when group thought stops innovative ideas from being realized or even thought or expressed. The fear of breaking the group thought is perhaps not obvious or even realized, but is there. If you break that precious bond, you lose that comfy feeling. We’ve all been in that situation too. We have that small, tight group and in comes the Outsider with the Outsidish idea. What an idiot. He knows Nothing. We’ve already tried that. But we are the experts. And so on. The outsider must in many cases chose between aligning and thereby just provide ideas which are in line with what is acceptable ideas within the group or stay an outsider.

What can be elusive is that the tight group might not be without conflicts or debates. The principle is that the alternatives are just within the acceptance range of the group. And thereby many great ideas are never explored.

According to Surowiecki, it is key to keep groups heterogeneous to harvest the collective intelligence instead of the narrow group thought.

These books really got me thinking about groups and teams. Agile software development is all about creating the most business value for the least effort and here is probably an important key factor. How to use the collective intelligence and still have the comfort and calm which Rapport brings. And how to minimize the negative effects of group thought. Working with the 7 Habits gives me a lot of tools but I will probably struggle with the Scrum team idea. Scrum teams are supposed to be cross border but how often are they really? And if they become true teams, how homogenous will they not become? Not that Kanban or other methods are better in this perspective.

Well, I have something to work with next year!

TFS 2010 for us product owners

I’m currently using a lot of Microsoft Project to keep my distributed stakeholders updated since the scrum dashboard just works for the current sprint and the 2008 web access isn’t very… accessible.  The stakeholders can’t get the overview they need. So, I spend time on separate Microsoft Project files with the long term plans (as described in a previous post) and I keep the product backlog in TFS.

So, I was just thrilled by the images on BHarry’s blog, describing the new features for us non programmers. Finally, I can really invite my stakeholders to keep themselves updated on the level they need.

The dashboard looks awesome! Here are two examples:

For me as a product owner, I of course long for the hierarchical work items:

If I still want to show Gantt charts, I can (if all goes well) use the upgraded Project Integration, since it conserves the hierarchy. This is the main reason I don’t use the integration today.

I’m also very curious about the Sprint planning functions

So, what more can I say: JUST BRING IT ON!

Integrated scrum projects

On Monday I’m starting a new project. This project has three objectives, you could say user stories, to be covered. But in our organization there is another project who are also touching the same story. In their case, it’s just a small part (1/6 of the project). And this is perhaps a common scenario in an enterprise environment with a project culture. Most systems and processes are connected and here we cross paths.

The first challenge is understanding where there is a connection. Here we need communication. You need to know which projects are going on and what they really mean. To meet this requirement, our company is currently mapping processes, concepts but still; there is nothing like verbal communication. So, scrum of scrums will be a necessity in the future. Right now, the scrum of scrums is more me unable to keep my nose away from other projects, so I keep myself posted. But yes, we need scrum of scrums. The whispering game is not a good and lean solution.

But now, to our challenge. The two teams are more than a one-pizza-group, so we’ll need two scrum teams, but the interaction need to be constant. We cannot afford doing stuff which does not take the other team into consideration. And we must work smart so that testing and deploying works smoothly. It’s a bit nervous but what makes it feel really good is the people on both teams. Really professional people, and that is the second most important challenge, find the right people for the challenge. It will be extra fun to finally work with one of our external project managers, Mats Wendelius from Alenio. He’s got experience from web projects from another leisure travel company and his experience is very welcome for a newbie like myself. Also, we’ve already had so many interesting discussions about how to cooperate between projects and it will be really interesting to see this in reality.

Why the scrum team should be the time trial team

Being a Swede is incredible fun this year. Of course watching 25-year-old Thomas Lövkvist at least one day in pink is awesome but one can’t help being amazed by Fredrik Kessiakoff, not a year into the discipline and already among the greatest on a day like today.

OK, I’m bike stricken and that is kind of silly of a person who normally knows nothing about sports. Sweden won a World cup bronze medal in ice hockey, and I didn’t even know that was happening even if ice hockey is one of the biggest sports in Sweden.

But road cycling is something completely different. Why? For not interested it looks so boring. Those guys sitting on their bikes all day long. And they are all on drugs. Well, if just address the last item first: as a pragmatic I understand that athletes like all humans cheat and you’re pretty stupid if you think this is more common in sports where you perform more tests. Being on constant pain killers doesn’t seem to bother soccer here in Sweden. So, let’s move along to why road biking is so interesting and why I find it so inspiring as part of software development.

I find that the needed traits are so similar: you have the hard work, the need for good tools, the long hours, the constant improvement. You have the cheaters and you have the loyal guys. And if you want to see a successful team. follow a team trial (if you missed stage 1 of the Giro you can still catch the Tour of France) and see who wins.

A team time trial is when the whole team get on their bikes on the same time and try to move as fast as they can to the finish. Everyone puts in their best effort to make the whole team win. Yes, there are always the weak links and they don’t perhaps do as much time in the front, but they do what they can. The team effort is measured by the fifth guy crossing the finish line. This mean that you can drop off a number of guys on the way but if you’re less then five it won’t matter. They still measure the fifth guy. Also, one can often see that the teams who push too hard so they lose people don’t win anyway.

Also, the focus on deploy is so interesting. Barloworld this year. The finish line nears. So, some of the guys sprint and others stop bothering. The problem was that only four were sprinting. So, they still had to wait for a couple of seconds for that fifth guy. I don’t think that dinner was a happy session for that team.

In rugby, one guy scores after the scrum and the sprint but in a cycling team trial the whole team is the winner. And that how it’s supposed to feel after a software development iteration.

Is it a project, or a product, or both?

I guess it’s not an uncommon problem. You have a project with a fixed and very important deadline which you cannot miss. But the stuff you’re building, you really want this to work for the future so that you can re use the stuff for other projects.

Since this is a scrum project, we only have one product backlog and all the items have a unique priority. So, how do you prioritize the long term value? In agile and lean software development, you want to build stuff as simple and easy as possible. But in this not uncommon scenario, “simple as possible” is not only regarding the project vision but the future projects. And these are not in the far future; one of these projects are probably starting half way through this project. So, this is something we need to plan for and take into consideration.

The best way to view this is from a product company’s point of view. The same scenario is common if you have a company who sells products but also custom built applications.

Here goes. You work at company which have the product XCV:P. And in walks a customer who wants to buy a custom application; Alpha. As a product company you can see that the output of this project can be used for XCV:P. The investment is big, so you really want the customer to pay but he only wants to pay for the stuff he needs for Alpha. If you end the project and the requirements of Alpha isn’t met; the customer won’t pay. But it would be crazy of you as a customer not to adjust the content so that you can’t use it for XCV:P.

So, how do you do it?

First, you need a project manager who understands both the need from Alpha and the need from XCV:P. But he must never risk Alpha to meet XCV:P. This is very very hard and require constant discussions and feedback. Second, the developer’s must grasp these long term and short term needs. You’re in for chaos if some of the developers think the objective is Alpha and others XCV:P. They need to know where the cash come from but they should also understand how beneficial it would be for the company if we made things nice for XCV:P too. Don’t try to hide this complication; expose it and let the developers handle and discuss it. We will probably need a product vision and a project vision.

In my non fictional project struggling with this complexity, I will use the allegory of the product company when presenting the project to the developers and I will keep the idea in my head when I work on the probably hardest task on any project: priorities. This is a project, and a product and we will need to handle that. But this is also what makes this a really fun and interesting project as well.

The Prisoner’s dilemma – The principle why agile works?

I just finished reading Richard Dawkins’ "The Selfish Gene". I didn’t read it to get an insight on agile software development. Being part of the skeptic movement, I read this of personal interest. But there it stared me right in the face; The prisoner’s dilemma.

You don’t have to believe in biologic evolution to understand Prisoner’s dilemma. You just have to have seen any police series on the tv.

Let’s say that two guys are caught for a crime. They are independent of each other questioned about a crime and given the option to tell on their partner to receive a lessened sentence. The police evidence is not that strong, so if none of you tell on your buddy, chances are that both guys get’s a small sentence. But if one tells on the other, that guy goes free and the other get a really hard sentence. You can see the result in the table below:

So, what should you do? If you tell on your buddy and he don’t, why then you are a real winner, but if you both betray each other, the collective loss is greater than if you stuck together.

Prisoner’s dilemma is a part of The Gaming Theory, and it can be applied on many situations handling human interaction. In many cases you can gain a lot by playing selfish, but if everyone plays the selfish card, everyone looses.

So, how does this apply to agile software development. Well, if you look at a more general picture of the dilemma you can see it with general values or with text (and observe that cooperate in this context refers to the two criminals and their behaviour towards each other, not the police):

    

If you on one hand have the product owner and the other hand have the scrum team, a product owner can gain from selfishly trying to gain maximum effort from the scrum team and thereby gaining maximum business value from a sprint. The scrum team on the other hand can selfishly try to do as little as possible.

If you look at individual team members you can see the same. A team member can selfishly try just to pick the fun tasks/do nothing and leave the rest to the other guys.

You get my point?

So how does Prisoner’s dilemma apply to evolution? The basic idea behind evolution is that something which gives a gene a slightly better chance of reproducing will become a little bit more common in the gene pool and thus; spread. In other words, there are two elements that are needed. There is competition (slightly better is in relation to another option/gene) and there is a repetitiveness (the game is played over and over again). And the later part is very important. There is a big difference if there is repetition.

Let’s say that you are one of the prisoners in the first example. If you look at that individual situation, what would you choose? Well, 10 years are a long time and perhaps that risk you’re not prepared to take. Yes, if you both tell on each other you can loose three years, but it can be a game you’re willing to pay. But that is given that you never turn to crime again. Who will gang up with you next time if you are known to tell on your buddies?

And here is where it gets real interesting when we talk about agile software development. If we have a non iterative process, more people tend to gamble on being the sole winner and less play the cooperation card. It’s when there is the chance of the game being played again cooperation becomes more interesting. The reason for this is that an issue we haven’t covered yet is retribution. If you tell on your buddies or play the selfish card, your buddies will retaliate. The product owner who betrays his team will probably have a more suspicious team after that, the team member who doesn’t do what he’s supposed to will probably hear about this afterwards. And a team with behaviour; how will they perform in relation with a team which cooperates all the time?

Having an iterative process clarifies that cooperation is the stable strategy of the team members and stakeholders. It will not make people cooperate. As Ken Schwaber puts it: Scrum does not bring excellence, it exposes incompetence.

Retaliation is a hard nut and according to Prisoner’s dilemma it must be there to make individuals understand the need for not playing the selfish card. But the retaliation must be swift and then it must be forgiveness. That is; if a team member betrays the team once, he must be "punished" just then and after that, the incident should be forgotten. Otherwise, too much energy is put into punishment. Dawkins points at a number of computer simulations which shows that the quick-retaliation-then-forget-strategy wins this game every time; a strategy which is called Tit for Tat.

I will leave you here to dwell on if Prisoner’s dilemma. If you’re interested in more on this dilemma, read The Selfish Gene or on Wikipedia:
http://en.wikipedia.org/wiki/Prisoner%27s_dilemma
http://en.wikipedia.org/wiki/Tit_for_tat

The winner takes it all

How more likely is it that you lose if you’re convinced that you will lose? No, I don’t think the stuff in The Secret, but I believe in the power of the mind and beliefs. If you’re convinced that you will see Santa Claus you will probably see him, or at least; imagine that you saw him.

Success is no different. Successful athletes imagine themselves winning and those who from start are convinced that they will not succeed seldom finish on top. If you don’t count short track skaters from Australia, that is.

I think that one of the core concepts of agile software development and scrum is building in a faith in the own success. You leave the estimates and the commitment to the people who are going to do the actual work. You just plan as much as you need to be able to change the plan according to actual progress.

When you are successful, you get happy about it. You feel proud and you know you can be successful. Perhaps you also like the feeling of winning and want to feel that again.

We just finished a very successful sprint and I think we all felt happy to go home today. Not just because it’s finally spring here in Sweden, but that we can next week deliver som real and good customer value to our users and customers. And that what it’s all about. What else matters (in software development), really?

As ABBA put it in the good old days:

The winner takes it all

The loser standing small

Partly done – root of evil

Now, I’m not religious, but if I thought there would be a devil in software development his name would be Partley Don Woork. Do you know him? Shining on the surface? Nice smile? Cute outfit? But completely worthless when it comes to some serious work. And when there’s a problem, he just starts babbling and you have no idea of what he’s talking about. Don’t invite that S.O.B in your house!

A bad manager does not recognize Partley, or he think’s he’s a rather nice guy. Good to bring with him to customers for demonstrations and sales discussions. But all who have to work with the client after the sale is completed knows that the customers soon recognize Partley too. And they don’t like him either.

A good manager knows that Partley is not worth the applauds on a sales demonstration. He knows that even if he can get two Partley’s for the same price as one Completely Don Work, he knows there is a reason for Completely being so expensive in the beginning. He saves the cost by just cutting away all those expensive meetings where the behavior of all those Partley’s are being discussed.

The management for our software development department is now successfully working against all those Partley’s, and it shows. Not only does it show in the quality of the software, it shows in the actual value being produced. And perhaps most importantly; it shows in the pride of the people at the department. Having to work with Partley’s is bad for workman’s pride. And manager’s helping teams fight Partley boosts the productivity! Try it: there is a world with less Partley’s if we all work against him.

Product Owner part of the team?

During the previous week, there has been an emotional debate concerning if the product owner is part of the scrum team or if he’s not. These are examples of things that talk for viewing the product owner as part of the team and things that talk against that.

Why view the product owner as part of the team

• Answering questions concerning the stories and requirements are part of the sprint and those tasks should be a part of the work.
• If the product owner does not see himself as part of the team, he will not participate in team activities as daily scrum, etc, and will therefore not be an active part of the daily life. Which result in developers making decisions since the right person is not available to answer the questions.

Why not view the product owner as part of the team

• To be able to make priorities, the product owner must be out with customers and users. He therefore does not have time to be availble on site and in the daily activitites
• If the product owner is there constantly, he will micro manage the developers

I’ve not covered all the arguments in these views, but I think that this catches a bit of the problem: to be able to make the right decisions, the product owner must spend his time outside the team room but to make the decisions come true he must be on site so that the developers don’t make daily decisions which contradicts the objectives.

So, how do I think you should solve this? For myself, I solve the problem with sore arms. What? Well, we have three floors and on each floor we have these heavy doors. So, I try to move between the floors as much as I possibly can during the day. I come to the developer’s room every day, to chat, to look on progress and if it’s possible: I try to help out with what ever I can. It can be arranging a meeting with a technical guru from a supplier, it can be testing, fixing with the scrum dashboard or just hang out with the guys. I want the scrum team to view me as part of the crew. A part of the scrum team.

And it’s the same with our users and customers: I try to take part of their every day activities. Just listen in on their discussions, frustration and happiness. And to help out in their daily work when it’s possible. Help out with small tasks, find out what is possible to accomplish, formulate a change request or something like that. To make the business people understand that I’m part of their team as well.

And what a joy it is to transfer experiences between these groups! How rewarding it is for a developer to learn that Robert can work more effective now with the new release. And how rewarding it is for a user to hear that Lisa could fix that problem so easily thanks to that really good formulated change request.

So, my answer to the question is yes and no. You should as a product owner have the mind set that you’re always part of the team. But you work on all the teams.

So, what do I cut? I try to work my own product backlog and try to do what brings the most business value to the product: in this case my work. Which means that what is most often cut is those long off site meetings which are probably very nice but which in reality brings very little value to my actual work. Which is to make sure that we do the right stuff in our projects. This can also mean that I don’t participate in whole meetings. People don’t have a problems if I from the beginning say that I actually don’t have the time but I can be there for 30 minutes or an hour. OK, I probably miss out a lot of nice trips and lunches but what is that really worth. Really?

Was it a successful meeting?

Why did you feel that a certain meeting was "successful"? Did you leave the meeting without long debates or did you finally win over the team from The Other Guy, that bastard who always gets his way? Or did you feel confident that the right decision was taken, even if you really thought that another solution is better from your point of view?

In most leadership courses, time is spent on getting the participants to understand who they are. Myers-Briggs is a scale many of you are most certain familiar with. Dave Nicolette writes on his blog about a simpler classification which can be used when describing meeting strategies among team members. In a very interesting blog post, he sees three strategies:

1. The ones who’s highest priority is "To win"
2. The ones who’s highest priority is "To find the best solution"
3. The ones who’s highest priority is "To avoid conflict"

Be sure to read the example in the blog post. We’ve all been there. Heard the discussion. Met the types.

And as Nicolette writes, you need all these traits in a team and a discussion! What if no one cares enough to win the discussion? What if no one cares if the best solution is selected? What if everyone is so involved in the discussion that they don’t care if the time spent and the risen conflict is really worth the trouble?

But it is also interesting to see which traits are dominant in a person in a specific context. A person can feel very strongly about an area and even if he’s the guy who always avoid a conflict in other cases suddenly becomes the guy who have to win since the area of discussion is a treasured and soft spot. And if there is a personal strain between two individuals, two who in other instances are the ones who try to find the best solution turns has to win the debate since the other guy is presenting another suggestion.

How can you use this classification? Well, I really hate classification of individuals into one, single package. What I like about Nicolette’s classification is that it’s context based: you don’t classify a person. Instead you classify how a person works in a specific discussion, where the context is a function of area of discussion, other team members and situation. You can therefore use the classification to analyze the discussion as such: if we spent 12 man hours on a discussion and the end result was still poor, could it have something to do with how the discussion worked?

So, what do you do if your discussions are not productive? Nicolette points at the possibility to remove a team member. Since this changes the context, everything can become better. I believe this can be a good solution if there are personal strains between people, turning them into must-wins or avoid-conflicts or if someone is incompetent without realizing or caring about it and still use the must-win strategy. Both these scenarios are sad and leads to a spiral of death to the team. Either you handle the personal conflicts, increase the competence (the problem here is if the incompetent person does not want to admit to lacking competence) or you make changes to the team structure. But one should not fall into the pointing of fingers: it’s HIS fault that the system is built this way. That is truly unproductive.

Agile teams are self organizing but that does not make them free of unproductive discussions and here I think we need great leaders and involved leadership. A great leader handles a personal conflict before it gets out of hand. A true leader handles a team member with lacking competence, whether or not that person admits to it or not. An agile leader evaluate meetings and make sure that they are productive, and that does not mean that "a solution was decided on" but also evaluates the long term effects. You cannot place this burden on individual team members. It’s great if the teams can solve these problems themselves but we all know that handling personal conflicts, consistent flow of bad decisions and lacking competence is a harder apple to bite.