Red Squirrel Reflections Dave Hoover explores the psychology of software development

[Previous entry: "Another Elephant Hoister"] [Main Index] [Next entry: "Malleable Ontologies?"]

Flattening Hierarchies
Thursday, March 11, 2004

Note: I edited this entry out of an article I'm writing because it was no longer needed. I'm finding it hard to let go of, so I posted it here. It's a brief description of how the different software development roles are impacted by the flattened hierarchies of agile software development.

"On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader... The structure of the team is a network, not a hierarchy." Peopleware: Productive Projects and Teams, 2nd ed., p. 155, Tom DeMarco and Timothy Lister

Steep hierarchical structures tend to trap knowledge and authority in the hands of the select few. Agile teams have relatively flat hierarchies compared with their traditional counterparts. What does this mean for each of the traditional software development roles?

Architects

The principles of agile software development pull architects from their quiet cathedrals and invite them into the bazaar of developers. Architects find themselves in the trenches, literally shoulder-to-shoulder with developers, continually facilitating evolutionary design while maintaining conceptual integrity within the system.

Developers

Agile developers find themselves with more responsibilities than their traditional counterparts. They are responsible for effectively communicating with machines and humans. They are responsible for living up to their own estimates. Most unnervingly, they are responsible for collaborating with their teammates to continually improve the design of the system.

Managers

Managers of agile teams can find themselves caught between the values of agility and the values of the larger organization. While they remain under pressure to deliver better software faster and cheaper, they can no longer dictate fixed-scope, fixed-time schedules upon their teams. Instead, managers are informed daily of their teams’ progress, giving managers increasingly accurate estimates for delivery.

Customers

Agile teams’ relationships with business sponsors have fundamentally changed from competitive to collaborative. In many cases, business sponsors weren’t even considered a part of the team prior to the introduction of the agile principles. Business sponsors now find themselves attending daily status meetings, continually refining (and redefining) user stories, and test-driving early releases of their systems. Customers are a single voice speaking from within the eye of the hurricane that is this agile team. Their ongoing requests drive the entire development life cycle.

Powered by Greymatter