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.
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:
We are in the resource planning phase of an upcoming project and I asked one of the guys to be the scrum master. He’s a really nice person and didn’t say no, but he wasn’t too thrilled about it. I was a bit curious and after some talking about it, I understood that he didn’t like to be a cleaning lady. In previous projects were he was said to be the "scrum master" it meant that he was assigned the stuff no one else wanted. I begged to differ but I understand the point. It’s easy to mistake the responsibility for handling impediments with fixing all the stuff which people feel is in the way of what they perceive as "real work".
So, how does one avoid making the scrum master into a cleaning up job? Well, first it’s understanding as I mentioned that just because you’re responsible does not mean that you have to fix it yourself. A good scrum master should be able to see who is best fit to fix an impediment. It can be that the person reporting the impediment should fix it himself. For me as a product owner, I find impediments a good way to become an active member of the scrum team. By volunteering to take care of an impediment, I can do real and important work to my team. Many impediments are lack of information from outsiders and as a project manager and product owner, I can help get that information.
This blog might seem a little bit schizophrenic: on one side I’m talking all go for agile software development. And on the other hand, I’m giving a Microsoft Project tutorial.
I know that Microsoft Project for many agile people is the devil in software. So, why do I teach it?
I started giving Microsoft Project classes in 1997. If you think Project is a horrible program now, you should have known it back then. It was more like riding a crazed horse than using computer software. You never knew what the thing would do. What happened is that I didn’t understand how I was supposed to really use the program in my work. Yes, after a lot of hands-on testing I started to understand the basic thought. But I realized that you shouldn’t teach specific features, you needed to make people understand the flow: how you could use the program during different phases of the project.
During a couple of years, I gave loads of Project classes and I also helped a lot of customers during implementation. I wrote two books for teaching Project. But there was one problem: I’m not that kind of project manager who likes keeping tabs on that Gantt chart. I prefer working and communicating with people, not using charts and diagrams but in dialogue. I stopped using the program myself. People around me couldn’t understand it. But I had no use for it in my projects then. Now things are different. I’m handling different types of projects and the resource planning works differently. And then an individual sent out a question on LinkedIn about how one got to learn to use Microsoft Project. I thought it would be really interesting if I could teach someone I knew nothing about a program which is perhaps the worst used on ordinary computers.
I think that the program can be really powerful in two ways. Used correctly for the right type of project, it can help project participants understand the boundaries of the project. Today, for example, I could use Microsoft Project to show our managers that their schedule for releases does not work with the tasks ahead of us. There is simply not enough duration.
But most of the time Microsoft Project is used wrongly. Without understanding how it works people make plans which looks accurate but are flawed just because the settings were wrong or the field was misunderstood. You could also be dealing with a Project champion, who can dupe anyone. A former boss of mine knew my skills and could order a Gantt chart which collapsed when we included a feature he didn’t wanted. Instead if him telling the CEO that the feature could not be implemented, he made Project say it.
Many of these problems can be solved by educating people about Project. Some might realize that the program does not work for them. And they might stop using it. Good! Others might realize that they were using it wrongly and change something and things work better. Also good! Even others start to understand how the program works so they can question the Gantt charts and the plans. And here lies my main motive in posting this on my agile blog. If we in the agile community understand Microsoft Project, we can question the plans.
So, even if you hate Microsoft Project but there are persons in your surrounding which are using the program, do try to understand so you can be a skeptic instead of just a critic.
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:
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.
The last couple of days have been spent in the developers’ room, helping out with the validating of our releases. Validating for me is about 30% testing and 60% communicating with developers and business people. The last 10% is reflecting on found defects. Validating (or testing as you might put it) is not one of my tasks in my work description but as I put it to our CIO when I discussing the option of working at TUI Nordic, I specifically asked to take part in testing/validating. Why? Some might see testing as a lower level of work but as all people into agile values: this is not the case.
For me, validating is about learning the system, being part of the team, getting to know people and also to reflect on previous work. If the quality is poor in current work: how well have I performed as a leader during the current sprint?
Eat your own dog food!
Can now be made more easily thanks to Franco Martinig at
Before I read Made To Stick, I prepared a presentation for a strategic group within my company. I was rather satisfied with content but after having read Made To Stick I realized that I needed to focus on my main objective. Directly, I cut 2/3 of the slides and then I shifted the order so you could really follow the red thread. Yes, I missed out on some important findings but if these were not coming through: what would be the point of spending time on them.
The inspiration for the new flow revolved around a specific concept and I was so happy about this: it really made sense to me. But I wasn’t pleased. I went through the presentation with my husband and he didn’t think the part surrounding the concept made sense.
Giving it some more thought I realized that presenting the actual concept which inspired me to make the presentation was clogging it: since the content now covered the concept it was just unnecessary cosmetics. The message came through anyway. So, I cut my baby loose and there I has one of the shortest presentations I’ve ever made. Few words and few slides.
The result was staggering: we spent 1,5 hours discussing 5 slides. One of the participants said that they were spoiling the presentation. I countered and said I was not giving a presentation, I was participating in a discussion. One of the most giving discussions in my professional career. Simple magic.
So, now I’m going to take the Easter off, thinking about these findings. I’ve even done all my exercise for this week, so the running gear will stay at home for the weekend. The computer will remain turned off and since my phone is still broken, I’ll be really off line.
So, happy Easter, and think about hosting discussions instead of giving presentations…
Yesterday, I replied on Lasse’s weblog concerning Ken Schwaber, perhaps not on purpose, differentiate between managers and professionals by stating:
"I expect 20% turnover in professionals and 40% turnover in management as Scrum gets implemented"
I guess that even if Schwaber didn’t mean to say that managers are not professionals it’s somewhat related to the, for me anyway, rather common input from developers when it comes to meetings:
"Are we finished, I really have to get back to work."
What that means is that meetings are not working. And what are managers doing: spend their days in meetings.
So, how do you become a professional manager? I’m not native to the English language so my taste of the word probably differs from a person for which English or American is a native language, but for me manager is someone who manage something or someone. And for me to manage is to handle, perhaps even take care of. And now I don’t mean the mafia style "take care of" but more the thoughtful taking care of. There’s a lot of feeling but also not only emotional feelings. There is a logic to how one takes care of the person or the situation. To be able to take care of a situation and a person I need to know what I’m doing and why. And if my methods don’t work, I have to think of another way of doing it.
So, for me a professional manager is a person who knowingly handles situations and people. I guess it’s mostly a mindset. A good manager like a good leader does not care about the title, he cares about his work and people. So, why do we suck at this in the eyes of the developers? Well, how can you handle what you cannot see? How can you care about people who’s work you never take part in?