By Kevin E. Breidenbach - 29 October 2008
As you drive around the countryside of the Midwestern United States, you'll see silos towering over farmland. Depending on the time of year they may even be filled with grain. If you know where to look you might even be able to find a subterranean silo which housed one or more Minuteman ICBMs from the days of the cold war. In either of these cases the silos are used for a good purpose – to keep things in that either feed people or vaporize them!
For some reason though, there is a group out there that like to fill silos full of people. Even stranger is the fact that these people all work together but they may be put in different silos. It's really difficult to talk across silos, so nobody really knows what the people in the other silos are doing.
So who makes up this weird group that like to segregate people? After studying this group in the wild, researchers have named them Technicilli Managerius, or Technical Managers to us common folk.
In all seriousness this has been a problem for a long time. As an example, consider a large application that has many different major components. When the system is being designed, the managers often see benefits in creating individual teams to work independently on each component, with each team having its own manager, development leader and several developers. The teams start building their components and everything is dandy, but apart from the odd conversation over a beer between different team members, communication between silos is minimal. And this is where the problems begin.
If one team is having problems, it is unlikely that other teams will know about it. Different teams may very well be struggling with the same problem and coming up with different – even incompatible – solutions. Or they can play a game where each team waits for another to signal “defeat” and admit to being behind schedule. This defaults the entire application team into delay, giving everybody more time to complete their work – or simply another chance to play the game.
This inter-team disconnect is particularly prevalent in waterfall projects, which are far from transparent. Of course, the problem isn’t unique to waterfall; it can happen to any project. Agile teams have metrics such as burn down and velocity that allow us to see where they are, and across a large program of work this gives very good insight into which teams are behind schedule. But visibility doesn’t address the underlying problems of teams working in silos: multiple teams will still be working independently of each other.
I believe that fluidity of people across teams would improve communications and benefits the project as a whole. How would this work? Each major component has its own iteration manager and possibly a lead developer (although I'm becoming convinced that there is really no need for lead developers and a flat structure really is better). A developer can, when needed, move among component teams. In this structure, the "team" exists at the application level and not at the component level.
It can be argued that this fluidity is difficult to manage, and that developer ramp-up on each component is time consuming, both of which will impact timelines. These are valid points, but they don’t make a compelling counter-argument to trying this approach. If you have competent developers on your team, if there is nothing drastically different in the design of each component, and if there aren’t very different languages for each component, then developers moving among components shouldn’t be too much of a problem. Of course, not every developer may want to move between components, and they shouldn't be forced to make a move. But most developers are inquisitive enough to want to see what is going on in different components.
Another way to combat silos is through consistent, highly focused communications within and across teams. For example, a good development team holds daily stand-up meetings. They’re a great way to concisely communicate what people are doing and the problems they’re facing. While it isn't possible to bring a very large application team together for a stand-up, there is nothing to stop iteration managers from having regular stand-up meetings to inform each other of what their teams are doing and what problems they are facing.
Leave silos to grain and thermonuclear weapons: they are much better suited to that working environment than people. Development teams just get tunnel vision and projects end up badly disabled and sometimes dead. Plus, silos look terribly uncomfortable!
About Kevin Breidenbach: Kevin has a BSc in computer science and over 15 years of development experience. He has worked primarily in finance but has taken a few brief expeditions into .com and product development. Having professionally worked with assembly languages, C++, Java and .Net he's now concentrating on dynamic languages such as Ruby and functional languages like Erlang and F#. His agile experience began about 4 years ago. Since that time, he has a serious allergic reaction to waterfall and CMM.
No comments:
Post a Comment