SCRUMHockey

For not so long ago I started playing icehockey. I came in a team as a complete rookie. For a mounth ago, I came in a new firm for a project as an external developer in a SCRUM team. In my experience there are many simmilarities how good softeware and icehockey teams work.

The first time I was on ice this year, it was a disaster for me. The guys there were all well trained playing hockey since ever, making a good team; and then I came there with really basic skills and no training at all. It was pretty devastating to be such a nut, however I made some perceptions how the team reacts and what measures they toke to improve the teams performance (and of course mines too).

The team had started the training as usual and I was just dropped into the deep water. They let me suffer for a while but then one of the best player in the team, who also had some coaching experienses, just stood beside me and started to gave me some advices on how to do the excercises better.

The first training match I played, was ad-hoc at all. I was asked which position I liked to play and just tried to keep up with the others (with rather less than more success). After the match the team made some discussions and I was briefed again and got some technical and strategical hints, how to make the most out of my lousy abilities. Of course during the game there was also hints mad by the others, but they were more concentrated on playing the game, and making the most out of it.

So that is how actually we train in the team, and after some trainings I was just wondering how similar it is to the way a good SCRUM team should work.

Actually when I went to a new firm for about a month ago, I have had a very similar experience. I was new to the project, to the team and the whole framework they used was also pretty new for me. So after two days of trainings (some very basic overview of the architecture) and basic project information I was started a sprint with the team. In the first sprint I was the one who got the small issues, mainly bugfixes, to warm up and have some overview over the modules integrated into the project. For the first two issues I was in pair programming with a senior team member, and for the rest it was mainly a question/answer game I played.

In the second sprint I was already working on more complex issues, and now I'm just about implementing additional features for some user stories. By the sprint reviews and retrospectives we discussed about the tooling and the way we should process our issues. We coverd some coding practices and some testing questions, and I was asking some open questions to get a better view of the project.

My conclusion from this story is, that a team is successfull if there is a strong coherence. All the success is about teamplay! In the sport is it most of the time self-evident, but why is it all so many times overseen by software teams? Why do teams still rely on estimates of some 'superhero', and let one senior write specifications and stories all alone? Why do managers beleave, that a team review or a sprint planning meeting with all the team members is waste of time and/or resources and try undermine it, or just pull the majority of the team out of those meetings?

In my eyes the only way to succeed with software projects is to enforce teamwork. And the more risky the project is the more this rule applies!

More on hierarchical scrum teams

Software development can make so much fun! One of the big idea behind scrum, is to enforce a face to face communication in the team. To get the power of the community, through the whole development lifecycle. For me it was one of the main arguments to start working with scrum. A really good team works much more efficient, produces much better code and of course software quality too. And by the way, it does make much more fun to work this way.

However, i find that the team should not be hierarchically organized. Every developer in the team should be equal (not the way our old Orwell meant it: "ALL ANIMALS ARE EQUAL, BUT SOME ANIMALS ARE MORE EQUAL THAN OTHERS." ;) we all know how the story ended up!). Of course there are seniors and more advanced members, but they will be forming the team, and other team members will respect them without any hierarchy.

The power of scrum is that it enforces the individual, and at the same time reinforces teams. It gives one the feeling of freedom. The developer is not a resource any more that can be assigned to one or another team, for 10% of a week and just do some job for the manager that got him from his boss. His performance can not even measured. The smallest unit is the TEAM! At least concerning controlling!

For the old fashioned manager, who manages his resources and got his weekly reports about the progress on this and that project, this seems to be a pretty inconvenient situation, if suddenly, that particular excel rubric can not be rewritten, or moved to another project, or even can not be evaluated/measured on its own.

Who cares, which developer had made it. It was the team! And may be one or another developer is not so good, but we all have our strengths and weaknesses. And you can be sure, if a team keeps somebody, than he/she's worth to be kept.

However, scrum does not mean the loss of control. If you look at it, it gives much more control for the management, since it delivers real value! It's not about working hours spent on this or that, it's just about functionality, you've got integrated into the project. It's about transparency, you got by the product backlog and by the story board. It's about risk mitigation you can get by the short iterations. The main problem with scrum is that it is different! It is not the old school, and chaps of the old school need some time to change (could ask Galileo he knows it well! ). I see pretty the same situation with scrum. You can prove it by doing. You should just start dong it! But the old school won't start with it, since we all know: the Earth is the center of the Universe.

Another big advantage of scrum comes with effort estimation. Planning is a hard stuff. As the old good Churchill said once: "It is difficult to make prediction, especially about the future".

So, what to do (the ultimate  recipe of planning):

1) Get an experienced developer, and let him/her be a leader or manager. You can be sure, that with the time she got away from the code.

2) Let him the one who is authorized to make effort estimation (give him a star ;) )

3) Discuss the requirements and wait for the magic number: 42

4) Ok. if you have a good project manager she would still multiply it by two! Just to be sure ;)

It sound so cool, since we know, the chap who made the prediction was a really good software developer... but forget it. It fails in most of the cases completely. The chap with the star will communicate less and less with the poor developers! He is better now. He is authorized! The effort estimation is his responsibility, so he doesn't need to consult with the developers! He might do it, but it won't be enough, and it gonna be even less and less. I'm pretty sure about it (unfortunately).

But wait, just call your team together for a game. Just meet a room for a day and play poker with them! The development team has the most adequate information to make a good effort estimation. If they are not influenced by some lead or boss or manager or whatsoever, and are supported by a qualified scrum master and product owner, the result of the planning will be impressive!

In my team we have made many mistakes, and did not apply the process the way scrum suggests, but still we achieved much better results on effort estimation by introducing user stories, and start using story points.

But again. You can call it ideal day, or story point, or potato, it doesn't matter what the unit of estimation is. The real matter is, how to get to the result! 

"The plan is nothing but planning is everything"