Results tagged “Team”

The last few days at work in 2012 held another surprise for us. Well, more for the other members of my team because I got the informations a few days in advance. Because of the current project situation it was no longer possible to keep our team together in its current structure.

We all knew that sooner or later one of our colleagues would leave the team and also start supporting other teams as Scrum Master as he has expressed his wishes and goals already some time in the past. Something similar applied to me (just not that openly) as I always communicated to my department leaders that if there is a project or team with the requirement of a Scrum Master who has also a proper technical background in development and there is no other possibility they could get back on me as a last resort. What only I knew in advance was that there were already restructuring plans emerging as the project situation could no longer afford our current team in its entirety. The large project we were working on ends with 2012 and will be continued (with a certain probability) earliest in February. And there are no other short-term projects available which could carry our team in the meantime. Furthermore other teams were also in need of new Scrum Masters and that was the the tipping point why not only my colleague is leaving my current team but also I have to leave it to support another team.

The current team is left with two full time members, one part time member and one member on unpaid leave until March. It has been decided that it will be merged with another smaller team and its Scrum Master to work on small tickets and also the current projects of the joining team. In the end we were victims of an unclear project situation in our technological areas and a high demand for support in other areas.

It's really sad that this is the fate of our team. In the last year we became specialists in our technological areas and had a steady rise in expertise, know-how and professionality. We had to cope with several difficult situations but in the last few weeks of 2012 it became clear that we were working together very effectively and there were also no issues on a personal or communication level (which is not that common in my experience).

I hope that I'll have the chance to keep up regular chats to all of them in the future and stay in contact.

My new team will be in a comparable situation as my old team way a bit more than a year ago. They are also only a few people and in the last year they had seen five other Scrum Masters come and go. That this poses an obstacle to building and adhering to processes should be pretty clear. In 2013 they will also take over a completely new project where there is not much prior work and they can start "green-field". As this is new to most of them I had been asked to become their 6th and hopefully more permanent Scrum Master because I had similar success with my old team(s) and also can offer deeper experience in that specific area of technology (Java, J2EE, etc.).

Thank you my old team for the great ride and I wish you all the best. Welcome my new team, I will do everything what is possible to me to make our upcoming work a presentable item of excellence.


Just yesterday I read the article from Joel Spolsky about A Little Less Conversation. Despite it being an article from the future, Feb. 1st, it reminded me a lot of the experiences I've collected in our company myself.

In short, Joel repeats once more the sadly not-common-knowledge that the more people are on a team the slower and less effective it gets. "Adding people to a late project makes it later!". He explains this counterintuitively effect, that the number communication paths does not grow in a linear way with the number of team members. Instead it grows much faster so that on a team with 10 people you already have 45 different paths of communication which have to be managed and synchronized. And if everyone on the team has to kept up-to-date with the information-flow the overhead for managing this information (even if just sorting into relevant/irrelevant) can quickly reach nontrivial amounts.

There are two ways to soften this problem. The one with the bigger impact is to keep your teams below a certain size. In our company the experience seems to come up that our Scrum teams work best if they do not exceed eight people. If with or without Scrum Master depends on the team. The second measure which can be taken is, that not everyone is invited or updated with information which is unrelevant for his or her position. Even more so if there is no influence possible for these people. But people also have to understand that it's not out of personal dislike or conflicts that they aren't kept up-to-date with everything on the company but that this lowered information-level allows them to concentrate more on their actual stuff which they are working on and removes a lot of unnecessary interruptions.