Here in north Texas, marching bands are large and competitive with their own cultures.  My daughter’s high school band has around 260 kids. They are a competitive band and the competitions are extravaganzas of massive orchestration. The complexity of the shows is stunning. My little high school band had only a couple of dozen kids and they just wore green polyester and marched in straight lines with the odd occasional left turn.

My daughter’s band, however, can take up nearly an entire football field when standing still and they quickly form large patterns like their high school’s letters while marching sideways and backwards in intertwining lines. The complexity of a set’s mechanics are almost a distraction from the performance itself.  These elaborate band shows are modeled through software, but the execution is managed by section leaders and band directors. While directing by instrument and other organizational break-downs help make it easier to coordinate, in the end, the band has to operate together.

I use the opening act before band performances to process my working day. (The warm-up is an avant garde experiment with time displacement where giants donned in ceremonial faux-armor group, struggle, and regroup while searching for a pointy leather balloon. The surreal part of the performance is there is a clock that slows down, teasing you with the Theory of Relativity.)  As I decompress and have sensory input outside of a computer screen, I reflect on Agile, Scrum, and the nauseating smell of liquid arena cheese.

I’m less enamored with Agile and Scrum as of late. I just don’t think it’s a one-size-fits-all system. The transition from Waterfall to Agile has been a little ugly. The unforeseen consequences are rearing their heads as we spend copious blocks time fixing things we broke in haste to make dates.

For example, with Waterfall, we had accounting systems that tracked project numbers. It wasn’t perfect, but if you knew the project number, you could search any internal system and find documents, diagrams, code, etc. Now, project numbers are peripheral. Those same systems (e.g. our testing and bug tracking system) are free-for-alls. The taxonomy of projects is based on whatever the person entering the data thinks of. It could be project name, number, or cutesy Scrum names you only know if you’re on those teams.

Agile is like vaguely written legislation. It’s open to interpretation and abuse. Part of the problem lies in the Agile Manifesto, published in 2001. Each tenant of the manifesto is utopian and lacks specificity. Agile is one of the best, neutral (i.e. not religious or political) examples I can think of demonstrating how philosophical underpinnings affect the execution of an idea. Unless the organization has absolute cultural practices that supersede process ambiguity, then things will stop getting done with each new process, for example, documentation.

Organizations who don’t have a strong content strategy embedded in its culture will lose knowledge when processes don’t unconditionally require matters of record.

Traditional software development methods seem clunky. Gathering and writing requirements is perceived to be arduous. Agile software development is a convenient excuse to shortcut research and documentation. On the surface this seems like a good idea. Who reads the requirements anyway?

Basic software documents like requirements, use cases, user studies, etc. have quick expiration dates. There’s no question about it. But it’s not the documentation that’s important—it’s during the exercise of producing traditional documentation when the magic happens. When business analysts work with developers to determine technical constraints, for example, they are providing context for everyone. Yes, this takes time, but the consequences of not going through those exercises is a future full of reconstructing knowledge often, meetings with the only goal of clarity, arguments over semantics, and a disregard for complexity and nuance.

There’s fast and then there are aimless, spastic, endless releases. The more release cycles are sped up, the more things we drop to meet deadlines. The larger the scale of software, the more complex its environment. While mobile apps lend themselves well to Agile, large enterprise applications interconnected with other large enterprise applications have layers of complexity you can’t deal with in a six-week sprint. At what scale does ambiguity across dozens or hundreds of autonomous teams no longer function?

I often feel Agile in large enterprises is like a big marching band without a planned show. We are all out on the field and left to our own autonomous teams who are trying figure out where to go to form the letter “T.” There is a band director and drum major signaling to us but they keep looking at the visiting team’s band for queues so we can improvise competitive moves. Then every once in a while the school’s principal shows up and yells at us maneuvers the district’s administration wants added into the show. And, by the way, we need to stop using one-third of the field because they’ve decided to add folding chairs there. Apparently we aren’t maximizing the potential revenue of the stadium.

Back in my Air Force days, I marched in the honor guard. Four of us worked together to present the flags at ceremonies. We were flexible enough to fall in with larger parades or individually, we could march with members from other services (i.e. the Army, Navy, and Marines). I know how to march and I have a snappy salute to boot. But I would never hold up in my daughter’s band because I learned military rather than band marching, the scale is much greater, and the purposes of each are distinct (not to mention considerable time has passed since then, but let’s keep our eyes on the pointy balloon).

Orchestration of so many people is strategic, not tactical. The trick, I think, is to work the process most applicable to the scale of the project. Using different methods for different circumstances, planning scalable processes, setting absolute standards for matters of record, and paying attention to what is and isn’t working are all more in the spirit, rather than the letter of Agile.