Agileista

I was chatting with Eben about the current state of affairs at work. We got around to talking about the personnel and projects that my place has on the go.

The development staff consist of seven developers (one of which is the MD, one of which is me, with the obvious coding time impact for both of us) and roughly three testers.

The projects on the go, split roughly by a combination of technology and client number seven major and two minor.

If I count the two minor projects as one, and the MD's and my available development time as one developer, that's 1.125 projects, per developer!

This level of task diversity for our developers had never occurred to me before, in my defence this was largely the status quo before I even joined (bar one project or so). I wasn't exactly going to join and be able to convince the upper management to give up revenue streams.

All this is a far cry from Eben's situation of one team, aimed at one collective software goal (or at least, that's my current take on their situation).

It's obvious we need more staff, and there is an ongoing recruitment process. In the meantime the demographics lead to some interesting thoughts around the right way to structure the teams.

I may as well get around to admitting one of the Agile sins: We have a great deal of "infrastructure code". While I understand this can often be a bad thing, in this case it does serve to unify a lot of the work done in one language - indeed three of the biggest projects share exactly the same shared code base, with client-specific code on top.

Therefore I could potentially unify teams by language. This would help unify developer interaction. It would spread domain knowledge. It would create more of a team environment as the biggest team would now comprise of five 1/2 developers, plus two testers (say). I think this could be a marked improvement for the team dynamic; giving them the chance to really interact.

However, it presents a difficult question from the other side of the Agile coin: Specifically with reference to the Product Owner. How could a unified team like this serve the needs of the respective Product Owner for each client? I think the joint most important part of Agile is that it ends up (if done correctly) creating software the client wants. How then can the Scrum Master (say) use such a unified team such that each Product Owner's priorities can be folded into one Product Backlog?

It's this challenge that has prevented me from unifying the team, so I'm paying the price in terms of the greater complexity my current set-up creates.