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!
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!
