Mickaël’s Weblog

This week, the team get a training on Scrum. The goal was to introduce more agility in our development methodology. After this training, managers decided to use Scrum as Agile methodology, starting in 2 weeks for our neqw internal release. That sounds good.

The team is about 18 developers and QA engineers. Scrum recommende to have about 7 folks per group. This imply to split the team into smaller groups. The current oganization is really not agile; this not so suprizing as we kept the same organization for around 11 years and we are Agile practitioners only for 3 years. So the team in splitted into 3 blocks: QA and 2 development groups (business and platform). My concern is that we keep the same organization on re-grade the existing manager as ScrumMasters. I think this is faking Scrum for 3 reasons.

First, teams are supposed to be cross-functional, which is not the case today.

The ScrumMaster is supposed to be a facilitator/moderator and contribute to the features development as the other members of the group. The existing managers do not have such contribution. More over the ScrumMaster is not supposed to have any authority, which makes very difficult the association of manager and ScrumMaster roles for one person.

And last; self-organization of the team is a fundamental of Scrum. I do not see any of that in a re-organization fully handled by managers.

I hope we will go throw a different path: let the team re-organize itself by involving every members and do not fake Scrum.

 I see often managers stretching their team to acheive goals as early as possible without any middle term or long terme appraoch.

Achievement is important but you have to be less productive at some point –take a breath — to get better acheivement latter. Here are some example:

• training and team’s skills ehancement,
• change a tool if you are reaching the edge of it
• do not assign storyes/task on a specific area always to the same developer for productivity reasons
• reduce tests (automatic or not) and focus exclusively on coding

We are doing daily stand-up meetings in our team. This is one of the agile practices that has been setup (we are doing also test-first and time-boxing). These agile practices have been introduced progressively as the company decided to go on this path.

The initial goal was to improve internal communication inside the team on the project. I’m not satisfied with the result regarding our goal. Of course, every one is a little bit more aware of what’s going on in the project, but the organization of the team impact strongly the results. The team is in fact a composition of silos, and the daily stand-up is just an enumeration of information on really different areas. Finally there are very few cases where appears some shared information (I mean, information that is useful to more than only one guy).

In a certain extend, it does not provide the feeling that we are all on the same project. At least, folks have a rough view of who is doing what…which is not bad.

Today, Jeremy D. Miller have written a post that exprerss exactly my feeling:

A team building a feature is far better than a group of individuals doing tasks