Agile isn't a development methodology.

If you’re an Agile Coach, I apologize up front... I’m going to at least threaten, if not outright slaughter, a couple sacred cows in the next few paragraphs. Agile practitioners tend to be a pretty passionate bunch, and that’s a good thing… But after 25 years of working on product design and development, I have my own thoughts on how to get the most out of collaborative teams. This isn’t meant to be an Agile primer, but the nature of the topic requires I touch on a few basic principles, then I can proceed to distort them to my own nefarious ends.

“Orthodox Agile” as a software development methodology grew out of developers’ very real and very reasonable frustration with always being downstream of the requirements process, and the inefficiency of classic waterfall methodologies.

In traditional product development, wicked smart business people lock themselves off in an airless conference room for weeks on end, studying competitors and existing feature sets, customer surveys, focus group results – what-have-you – then they come up with a hundred pages of requirements, cross-tabbed and indexed, with all their very reasonable assumptions documented in the executive summary and meticulously curated in the appendices. 

When they’re done, they throw the requirements over the wall put in place to protect them from the unruly rabble that makes up the UX design team. The UX designers rotate the requirements document in space and scratch their heads, then make their best guess as to what the business partners really meant, and turn that into a design…

And when the designers are done they throw their work over the wall to the developers’ bullpen, where the developers have been anxiously awaiting any news of the project they estimated from a paragraph of vague text six months before. When they finally get the requirements doc and the accompanying design, their eyes well up in despair and they mumble to each other things like, “If they’d only asked us...” Then they sharpen their pencils and they update their estimates, pretty much always in an upward direction.

Every stage along the way is a lot like a dead-drop handoff in a spy movie. And dead-drop handoffs are a lousy way to communicate.

The basic principle of Agile as a development methodology places the developer at the center of the process and surrounds them with business, design, analysis, and QA resources. By building from the development point of view out, you can be much more efficient, focusing only on elements that need to be constructed. By collocating the team and aligning them to “feed the developer” in near-real-time, you dramatically improve communication and reduce unnecessary work. You only build what you need to solve a particular problem.

Also, developers love having a conga line of people ready to massage their proverbial shoulders while they work; who wouldn’t?

Agile teams work by breaking projects down into bits of user functionality called “user stories” -- brief descriptions of user needs and wants -- prioritizing them into a “backlog”, and then continuously delivering them in short cycles called “sprints”. The very essence of user stories goes a long way toward ensuring customer centricity… but you have to be vigilant that old-school requirements don’t masquerade as user stories restated in pseudo-user-needs terms.

In classic Agile, all design and development is done within a sprint. I take the sometimes-unpopular view that this isn’t necessarily efficient, results in short-sighted design and technical architecture decisions if you take it too far (more on this in a future blog), and kind of misses the point of what really makes agile great.

In reality — I think one of the big reasons agile works is that it is actually a communications protocol. It establishes that all members of the team have a voice, and participate meaningfully throughout the process, bringing their perspective to the discussion early and often.

The beauty of agile teams is they mean that smart ideas are always welcome and can come from any member of the team regardless of discipline – but smart ideas in isolation are a bad thing. If we’re working in scrum, and a QA person has a great idea for a UX feature, they can bring it to the table and the team can work it together, shape it, and make it real in short order.

Close communication also means that unintentional drift is caught immediately and course corrected. The iterative nature of agile, combined with smart design testing means that designs can be efficiently refined throughout the development process. This doesn’t necessarily mean that design and development all have to occur within a single sprint – I favor a “staggered start”, with design working a sprint or two ahead of active development, figuring out design problems and even doing light user testing before the coders dig in. Because the agile is more about communication – team members are always available to one another for ideation and questions.

Agile teams also operate under a set of explicit agreements on how the team will work together. Work agreements are the set of rules/disciplines/processes the team agrees to follow to make themselves more successful. They can be broad – basic agreed-upon tenets – or very specific, down to the agreed-upon time to respond to requests from teammates. Agile teams typically either only work on the active agile scrum, or they agree to prioritize the work of the team. 

Team agreements build trust and allow agile teams to self-govern and optimize their workstyles to suit the task at hand and the needs of team members.

Agile most often makes its way into organizations sponsored by development leadership, and its apparently "developer-centric" nature can occasionally be off-putting. That's a shame. I believe you can -- should -- apply many of the same principles for any kind of product development or team endeavor.

It turns out that great product teams were “agile” long before agile was cool. Agile just gives us a framework and a language for how to discuss great teams.