Integrated scrum and kanban

This week we moved into a new phase in our first project on TUI Nordic in which we use kanban. We are kind of working with the same stuff as another project which uses scrum values like sprints and estimates. So, what do we do?

1. Tight communication between product owners

I start every day by a chat with the other product owner. We’ve decided that the best way to do this is mutual success. That is; if both projects are successful; the individual projects are successful. And we both know that communication is the basis for this. So, I plan for my stuff so that it helps the other project, and vice versa.

2. Guest players at daily standup

Both teams have daily standups and first we discussed scrum of scrums but since we have so tight discussions anyway, we realized that what was really important was when someone from my project (which is the smaller one) is working with code which directly affects the other project, he participates in that daily scrum as well. Since he’s a pig he can talk and this has worked surprisingly well. We all know that we have all to gain by helping each other and there’s a lot of sharing work and ideas.

3. Shared code

We work on the same project and work with integration as often as we can. We want to know as soon as possible if the shared code does not work.

4. Consider the scrum team’s sprint delivery

Checking in non working code is never OK but oft course this becomes a worse problem the nearer delivery a sprint is. Since we don’t have sprints on our kanban project, we must not forget to take this into consideration so we’re not half finished with something they need for their sprint delivery.

5. Nice and professional people

This would never have worked with the wrong people. I’m really proud to work with guys who realize that we’re all to gain here and there is no “that’s not my problem since that does not affect my project” mentality.

 

To summarize, I actually think it’s easier to integrate one scrum project and a kanban project than two scrum projects. But the story continues. It’s not over until the fat lady sings!

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!

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.

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

To sprint or not to sprint, that is the question

The problem with scrum and agile lingua is that it’s so often misunderstood. Being a runner myself, ‘having a sprint’ is something completely different than what you want in a scrum sprint. When I sprint, I run like hell until I reach the goal and there should not be any energy left to just start a new  sprint. Mike Cohn told a similar story with a team which used Sprint as a term for when you just coded like hell just to meet a deadline. Not the sustainable pace, in other words.

Reading Seth Godin’s blog post Sprint!, I can see that his concept of a sprint is more in the line of the runner’s sprint rather than the rugby and scrum sprint.

So, is ‘sprint’ a good word to use? Does it not cause a lot of confusion? Especially if you also use words like iteration. I’ve found that I’ve stopped using the word at my new position. Not deliberately, but I’ve realized that I will be misunderstood if I use that word. Worth reflecting on when introducing scrum in a new organization.