It has been a long time since the last post. This basically because I changed the company for which I work, and I needed a lot of time to integrate and to fix other issues.
I am going to speak about a topic I am discussing in this period, and I give here my personal opinion based on my personal experience.

As I always say, I am “passionate about […] agile methodologies“. I have always thought they simply work. I love them. This does NOT mean they are a religion. I think the guide for SCRUM (for example) explicitly says that, when it speaks about “adaptation of a process“: if for some reasons something is affecting the “creatively delivery of products of the highest possible value“, that something should be changed.
I was working in a team of seven developers. Seven developers and four QAs. The team is growing, we may want to hire 3 other developers. We have been split in two functional teams. On the paper, that was perfect. But I totally disagree.

WHY???

For a simple reason: whenever we respect this split, the quality of our work fall under the acceptable level (I am speaking about risk of break our production environment), so we end up breaking this rule anyway, and using it for justifying some behaviours.
I read a lot about this rule in the past, I still read lot of documents related, and I want to give you this post as an example, because it focus on the most important reason to keep the number of SCRUM team members between 3 and 9 as SCRUM says: the communication bandwidth inside the team. This is a concrete, valuable point of view: the more the number of people in a (sub)team, the more the time spent in communication. I accept this as a problem if we are a group of 10 developers and 4 QAs (keep in mind that QAs should be counted as dev team because they are part of our delivery process).
But again, is the speed a problem? Although the company wants to hire more devs for our team, just to increase the velocity, we had in the last (2-weeks) sprint a situation for which after 3 days one feature team had members with nothing to do (their tickets were all finished) and the other was risking of being late for a delivery that was affecting all the company. Because of the split, nobody could take any of our tickets (even if, in this moment, all of them knows the product enough to do the work) and we ended up closing the required tickets for the release on Friday at 2PM and asking to QAs to validate all the product for the sign off so late.

In the last sprint we also had one of the members of the other team who found a ticket in our backlog that forced us to deploy a service on prod with high urgency: if this member would not have broken the rule of not checking our work, again we would have broken the release.
So my question is: when does this rule (having max 9 people in the dev team) is so important to have priority over the quality of the work? My experience gives me one response: never!
In the last 3 years I worked for 3 companies: in the first we were 10+ devs (I think 12, but I remember only 10 people 😛 ), in the second we were 8 devs, here we are 7 split in 2 teams. And with the product with the highest internal dependencies for which I have ever worked, dependencies between components that are one in one team, one in the other.
I have never seen problems related the internal communications between developers before working here. Never. Now I saw them in every retrospective. Being honest, it is true that with 10 people we have more communication channel to handle, but we don’t really talk with everyone else all the time.
It is mainly a problem for the SCRUM meetings, that’s true. But again, is this really a good reason for the sacrifice of quality?

When I spoke to people who take decisions (yes yes, “self organised team” should be another SCRUM rule, but that apparently is less important because it is not considered) and I spoke about my experience, what they just replied is “it is obvious that we are more agile than your previous companies”. Strange. Because we were reacting even better, so well that we moved to kanban to be free of reacting immediately to (production) issues. And we were all really happy of the results.
Anyway if facts tell me that I am doing a better job when I am not agile, why should I care to be more or less agile? If agile is the problem, let’s evolve to something better. Let’s invent something new. I don’t care to tell to my friend that I am agile, if for doing that I have to accept to do a low quality work.

There are several other related topics to discuss but it is enough for this post.
Stay tuned!

Share