Feb

10

Can Big Shops Be Agile?

Posted by Keith McMillan

February 10, 2010 | Leave a Comment

I spent the last two years working for a Very Large Insurance Company, and before that I’ve worked with a number of different sized companies, with various sized development organizations. It’s got me thinking: just how easy is it for a big development shop to be agile?

My idea of an agile team resembles small businesses, or at least small development organizations: individuals have multiple responsibilities, and those responsibilities aren’t segmented off from each other and reporting to different managers, with “thou shalt not cross” lines between them.  Everybody does pretty much whatever needs to be done, subject to their ability to do the task at hand.  Sounds a lot like agile, doesn’t it?

As soon as development shops grow, they begin to encounter business pressures: unless your organizational structure is remarkably flat, your responsibilities begin to separate, because of the need for small groups reporting to a manager.  In my experience it’s pretty typical to see testing peeled off from the core developers fairly early on, and database administrators are shortly behind.  Before long, you’ve got a database group, a testing group, and a development group. While you can continue to build your teams out of people from these shops, and encourage them to learn each others skills and pick up tasks as they can, those groups tend to exist.  The larger the business grows, the more the pressure to further segment those groups: you get development teams reporting to team leads, who in turn report to managers or directors, and so on.

As the progression from small business to large continues, the “organic” development of small, manageable groups, and traditional reporting structures, tends to result in an organization that doesn’t really resemble our cross-functional teams any more, and so the pressures against cross-functional teams tend to increase.  Let’s face it, as we add more managers, directors  and vice presidents, people who occupy those positions tend to look out for themselves and their organization.  If they don’t, then they tend to not be in those positions very long, as someone else will come along and take over their group, or take advantage of them.

Which leads me to wonder: as you continue to grow, how do you overcome these pressures, and maintain a team of cross-functional (and as a result, more effective) individuals?  I think the only answer lies in delivering a message from senior management: your team assignments come first.  If you construct your teams out of individuals that come from multiple organizations, then their first allegiance should be to that team, and not to the database group, the testing group, or the developer group. In fact, what we’re really saying in this case, is that the team’s customer comes first, before their manager’s group. What’s wrong with that?

If you’ve got a large development organization, and you don’t send the message that the customer (that is to say, the project) comes first, then “your team” comes first, which means whoever works for your manager, and that leads to turf wars and inefficiency.  Senior management needs to hold their organizations to this standard, otherwise you’re not going to get the kind of results from agility that you would like to see.


Comments

RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
URI
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.

Blogroll