Agile Complexity
A couple of posts ago, I shared a concern with distributed agile development. A similar thing happened to me recently with another question from two different clients who work on a highly complex mobile operating system.
"Can you be agile in highly complex environment with emergent system characteristics across two thousand developers?"
And I had the same response as to the distributed agile question.
"Uh, yeah, you could go agile... I guess."
Why can't I get the easy questions? The fact is, you can't go for an pure-play agile approach across such a large organization with critical system-level characteristics. You have to put into place more planning than a pure-play agile process would desire.
"But," my more hyperactive agile friends would say to me, "you are not having success with a pure play plan driven approach either." (Ever notice that some arguments for agile have to do mostly with what isn't working with something else?) Yes, my hyperbolic prognosticators, there are a lot of issues with a highly plan-driven approaches as well.
So my answer is to do both.
As with any big project, you first have to break it into lots of smaller teams. This is just to get things done. How do you break it apart? Well you have to do some planning. Often, you create the smaller teams along the architectural lines (up front analysis) to have high cohesion, low coupling between the teams.
On the smaller individual team, we do something very close to the pure-play agile side of things. The team has a backlog of work. That work is done in short increments/iterations. The team defines the tasks to complete the work on the backlog. The team calculates its own velocity. The design of the functionality the team is working on may emerge over time. Feedback (as much as you can get) from critical stakeholders or their representatives is solicited.
To coordinate those teams we have a mix of planning and agility. First, modify the idea of a scrum-of-scrums. Attempting to "roll up" status at the same level of abstraction has failed in my and my colleagues experience. (Perhaps somebody, somewhere, got it to work once, probably while involved in some sort of substance abuse.) In the modified second level meeting, individuals who have participated in the smaller team status meeting "scrums" report at a higher level of abstraction. The "scrum of scrums" report is at the release level, not the task level.
To report at that level of abstraction, each member of the second level of status translates what they hear from the daily status meeting to a meaningful statement of the status of the release/milestone. Eight completed iterations out of ten does not necessarily equal 80% when a translation is involved. The human ability to consider multiple variables and intuition plays a part as well.
Planning also happens by placing items in the product backlogs of the small agile teams. System architecture or its equivalent watches over the product backlogs to 1) make sure system-wide characteristics are considered and included and 2) modify the timing of some backlog items to make sure that cross-team dependencies are worked in an acceptable order.
For all practical purposes, system architecture is one of the critical customers of the individual small teams. The system architecture group writes the stories and the tests of the system wide characteristics and can put those stories into the product backlog. In the customer role, system architecture's acceptance tests are the system tests.
So we have planning where we have to and agility where we can. No, it doesn't fit into the agile camp or the planning camp. I like to think it fits into the common sense camp. I guess common sense can be complex.