Ready for Agile? Who are your specialists?

Posted by Keith McMillan

May 19, 2012 | Leave a Comment

I sometimes wonder about whether large companies can be agile. When I think about how a company grows organically, one of the first things that seems reasonable is that as you add more testers, for example, you hire a testing manager, and they have their own group.  The same applies to database administrators, business analysts and the like, and you arrive at something that looks very like the average modern company today.  When you set out to create a project team, it’s obvious with this structure you’re going to need specialists from a number of different domains to fulfill all the requirements of your project.Once you’ve done this you might end up with a team of 35 people (as one client of mine did) for a modest software development project that involved 6 developers and a couple of testers on a day-to-day basis. The other 28-odd people were “required” even though their roles could be fulfilled by people on the team with the required skills. They were required because the people who could do their tasks weren’t in the right organization, and so weren’t allowed to do those tasks.

I see problems with this: first, as you increase the size of your team, you make communication more difficult. For every person you add over around 7, you significantly increase the communication burden between team members. Adding additional people to the team makes it harder to communicate with everyone on the team.

Another issue is divided loyalties. If I report to the testing organization, and you to the business analyst organization, then is our allegiance to the project, or to our respective supervisors?  Hopefully, it’s the latter, but we’ve created a situation where it may very well be the former.

This is why I put a premium on cross-functional individuals in a team. We do need a bunch of skills in order to deliver the typical project, and the trick is to fulfill those skills with the fewest individuals, thus making sure that we minimize the communication burden.  It also minimizes the number of hand-offs, thus making the work flow more smoothly and efficiently.

Broadly skilled team members also make planning your project simpler, which aids in agility. If only a few people can add a database trigger, for example, you have to wait until one of them is available in order to do that task. That means you’re planning at an individual level, which is frankly unsustainable with an agile project: things change too fast, or you have people idle because their tasks aren’t ready to be started yet. The less your plan focuses on an individual, instead focusing on the team, the better off your plan will be when it meets reality.

Lest there be any confusion, I’m not proposing that everyone be an expert in everything; but I am proposing that everyone have a basic level of competency in a broad set of skills, and access to in-depth expertise when required.

So what should you be prepared to do when you’re setting up a project, and you want to use agile techniques to run it?

If you’re wedded to the idea that you need all the traditional specialists on your project, I’m skeptical that you’re going to be successful. You would be better served to identify and recruit as few broadly skilled individuals as you need to meet your requirements. The more (relevant) skills someone has, the more valuable they are on my project team.

From an organizational point of view, there’s another difficult issue to at least acknowledge: many times groups within companies have different agendas and it may be in the interest of one group to have a project fail.  By creating groups of like-skilled individuals with their own management structure, we encourage these competing goals, frequently to the detriment of the company as a whole.  Minimizing the number of specialist groups will in turn minimize the possibility of such a conflict of interest, but I don’t believe it can be completely eliminated without fundamentally changing the structure of the modern corporation.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.