Inversion of Control for teams

On the majority of software teams a hierarchy exists. There’s a pyramid of developers, senior developers, tech. leads, architects, project managers etc. The architects design the system and tell the tech. leads what to do, and the tech leads go to their teams and tell them what to do. The most experienced people are at the top of the pyramid (ie. furthest from the coal face), and there is a natural progression down until you get to where the code is being cut by the most junior members of the team. Hmm.

A self-directing, agile, emergent team doesn’t fit this model. When roles are fluid, and more like hats than job titles, a more service-oriented organisational style tends to emerge. The pyramid becomes partially inverted. In a well integrated and happy agile team the developers become the customers of the architects and tech. leads. As issues or design difficulties emerge, the developers seek out the guidance of the tech. leads and architects. The senior technical team members continue to remain responsible for the overall design themes and patterns within the system, but in a more event-driven, iterative way instead of an up-front, top-down imposition of designs that may not fit the reality the developers are working with.