Red Squirrel Reflections
Dave Hoover explores the psychology of software development
[Previous entry: "Another Elephant Hoister"] [Main Index] [Next entry: "Malleable Ontologies?"]
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?
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.
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 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.
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