Success in an agile organization brings challenges to the organizational structure. An agile team of up to 8 people can successfully self-manage and deliver more than enough functionality to win that big contract. But once you win the big deal how do you organize 20 to 30 people successfully in self managed sub-teams?
A couple team members suggested similar team structures, all based on more traditional, large project org charts. Recommended are vertical sub-teams responsible for product areas (architecture, baseline functionality, specialized/configured capability). There’s also horizontal competencies recognizing areas we tend to see as “specialized”, like Architecture, QC and User Experience.
Maybe it’s my experiences in similar org structures making me question this approach. It reminds me of the “software factory” concept circa 1996. We’re just missing a requirements gathering sub-team full of business analysts throwing functional design documents in the factory’s front door.
The “software factory” approach also takes advantage of defined program phases to modify staffing by phase. Early in the program staffing is dominated by business analysts and architects. As the program moves towards the development phase the majority of business analysts and architects are rolled off in favor of a development heavy skill set. This approach continues throughout the life cycle until the only staffing left is maintenance team members.
Programs with a water tight Statement of Work (SOW), well defined change management processes and semi-annual (or longer) delivery milestones can operate successfully in this scenario.
An agile approach does not contain a locked down SOW, program phases or an aversion to change. Agile reacts well to change and user feedback, incorporating both into multiple, short (monthly) iterations. As stakeholder and solution provider better understand the problem space and the evolving solution the possibility of near real time adaptations emerges.
Agile also requires the availability of multiple skill sets in practically every iteration. Analysis, architecture, development, testing and QC are needed on all teams throughout the multiple iterations making up the program life cycle.
I’ve been reading 37Signals book Getting Real. They’re a self described Agile shop focusing on a very light methodology. I’ve admired their ability to consistently improve existing products and roll out new ideas. In their book they describe how, as a small company, they’ve achieved success from product focus through staffing, process and promotion.
In the organization section of the book they argue for unity. Silo-ing perceived skill sets (developers, user experience, architects, quality control) leads to a loss of “big picture” focus. I’d add silo-ing refocuses the emotional attachment from the big picture to the assigned silo.
So why not create multiple, self-contained sub-teams with the necessary blend of skill sets? Allow the sub-teams to work throughout the solution, selecting stories based on priority, not vertical slice. Spread the user experience knowledge around the sub-team; allow the architect to mentor developers; ensure all sub-team members are well rounded. Get the emotional buy-in of the team members. Let them see the opportunity for success, both personally and programatically. Most importantly this approach allows each team to develop potentially releasable software.
Ensuring sub-teams continue to pursue the same big picture requires each horizontal slice , or skill set grouping, meet regularly. In Scrum we refer to this as a Scrum of Scrums (SoS). Approaches and ideas are shared and coordinated approaches are drafted for acceptance by the teams.
Imagine that, a big company development program with an entrepreneurial spirit. Maybe we can actually achieve it!
