Want productivity? Try some team continuity (and a side of empowerment too)

I’m going to get into trouble for this if anybody reads this, but a conversation I had Friday made me want to write this…


I’ve worked on both traditional waterfall projects and XP/Scrum/Agile projects and seen a lot of factors contribute or detract from productivity.  A subtle factor in a project’s success or lack thereof has been the continuity of the team’s composition and general familiarity with the problem domain and each other.  I learned that very early as an engineer when we were able to keep the same basic project team together over the course of three projects.  Teams that stick together over time can be much more productive than teams that are thrown together and disbanded in rapid order.


Late in 2004 I was starting to look for a new position that didn’t involve being away from home most of the week so I could actually know my one year old son.  I detest the Big IT culture, so my initial thought was to stay in consulting but the no travel restriction from my wife was ruling that out.  Instead, I took my current position for a small software vendor after a conversation with a former colleague who told me the advantage of working at a software vendor was the stronger team relationships you build in a continuous team.  I thought it would be nice to be able to stick around at one place long enough to see software work and evolve.  So far I’ve enjoyed the continuity as opposed to being at a completely different client every 4-6 months, and it’s awfully nice to actually see the results of your work occasionally.


Positive Examples


My current team has been together for about 6-8 months working on a couple different components within a single large environment.  I think our time together and constant investment in better practices and project automation has made us more productive than some of my previous, more talented teams.  Since we’re going to be working in this environment indefinitely it’s to our advantage to make investments to the code, the build, or the tests because we’ll reap the rewards.  By sticking around in the same environment we get problems with project friction rubbed in our face.  Two or three times doing some manual process that takes too long and you’ll look for a way to automate the process.  You could say that we’re on our way to being a “river rock” team.


Over time we’ve accreted project automation and made the kind of “this is the way we’re going to do it” decisions that go so far in improving productivity.  We’re starting to develop a strong ubiquitous language for the problem domain.  Last week I spent a morning getting the infrastructure in place for a new web application that consumes some existing components.  In no more than a couple hours I had the CC.Net server up and running, a FitNesse deployment script and testing suite, an automated way to get the latest version of the shared components, and a kernel of the deployment script ready to go.  All I did was simply follow the patterns we had already established for ourselves over the past several months.


When people are shuttling in and out of projects or technical domains they don’t notice the repeated inefficiencies that we’ve been automating or refactoring away.  They also don’t have the incentive to make infrastructure improvements because they’re going to be moving on soon anyway.  You certainly won’t get the same kind of traction you get by being familiar with the same team members, code, and problem domain.


Negative Examples


Our much larger sister team in the mothership office rotates people every single iteration through 3-4 little project tracks and I know that they have been micromanaged in the past.  Last week a colleague from the main office told me he didn’t think they had time to see their inefficiencies because they were moving around so frequently.  Continuity is nice, but it doesn’t help as much if the team isn’t empowered.  Micromanagement kills teams.  It doesn’t matter if you do spot problems in your working methods and infrastructure if you simply can’t get permission to do anything about it — or don’t think you can get permission.  I don’t know if it’s our attitude that’s different (maybe), the fact that we’re a small satellite office that’s out of sight (most likely), or management actually trusts us (please), but whatever the cause we seem to be far more able to make continuous improvements than the development teams in the mothership office.  We think that we’re empowered, so we act like we’re empowered.


One of the most insane, Dilbertesque things I’ve ever seen was an matrix organization strategy at a previous employer that the bigshots called the “Consulting Model.”  The general idea was to make staffing more flexible to be able to do more projects simultaneously by sharing experts across projects.  In practice it meant a very inflexible version of the waterfall where the business analysts and architects would swoop in just long enough to create specifications to throw over the wall.  The developers were always tasked to multiple projects at any one time so their specialized knowledge about a technology or existing system could be shared between projects.  All project teams were virtual teams.  It was an absolute disaster.  Besides the sheer inefficiency of context switching, the lack of continuity and ownership in any technical area led to a large scale breakdown in productivity.  When I got out the mid level managers were agitating for rolling back the staffing model to make real teams that would be responsible for the stewardship of the different families of systems and services.  A little bit later the head of the business unit that my old organization served stepped in to run the IT project roadmap out of disgust.


 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/blogs/darrell.norton/ darrell

    What made the matrix organization? Just sharing resources doesn’t do it. In a true matrix organization an employee has multiple reporting relationships to multiple bosses, not just reporting to several Project Managers that aren’t really the employees’ true boss. Sounds like that “consulting model” was some good snake oil. :)

  • http://www.winterdom.com/weblog Tomas Restrepo

    I just posted some comments on the topic over on my weblog (http://www.winterdom.com/weblog/2006/05/07/TeamContinuityAndProductivity.aspx). In general, I’d agree pretty much with what you say, Jeremy, and it’s something I thought quite a bit about…