Posts Tagged ‘team’

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

2009/05/21 3 comments

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.

Categories: Agile Tags: , , ,

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.

Categories: Agile Tags: , , , ,

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.

Categories: Agile, Architecture, Business Tags: , ,

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:

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