Agile.

It’s probably one of the most used and abused terms in the world of software design and development today. Despite the overload, a lot of companies are still boarding the Agile train. And yet, you’ll find plenty of begrudging and cynical commentary online about how many folks aren’t actually doing agile design and development.

A deeper dive will reveal even more blog posts talking about agile’s demise or a particular agile methodology’s uselessness. Still, the spirit of agile development, as expressed in the Agile Manifesto, is by far the best way to build software at this time.

But, First…

Allow me to take a moment first to air a grievance:

Agile is not a methodology. It is a set of principles, even an ideology, sourced from the Agile Manifesto. Methodologies (or frameworks) have been developed over the years that aim to execute on the Agile Manifesto principles. These methodologies include Scrum, extreme programming (XP), and lean development, among many others. Therefore, it is appropriate to say that “Scrum is an Agile methodology” while it is inappropriate to say “We do agile and Scrum methodologies.”

Now, back to our regularly scheduled programming…

What We Don’t Do

Big Nerd Ranch also builds products with agility. Some of us Nerds (like me) obsess over the mechanics of various methodologies, eager to experiment with the latest and greatest in approaches to building software. However, we’re not strict adherents to any particular methodology. We’re not Scrum zealots, extreme programming purists, or kanban fanatics. Why? Because we accept that no one methodology will solve all of our problems. Rather, we appreciate the intent and goals of the those methodologies, and mix and match various practices to fit the project’s needs. We hold to each of them lightly, knowing that they are guidelines, not mandates.

For example, while we follow Scrum’s basic skeletal structure, we stop doing standups if we feel they’re really unnecessary, since the team and client are communicating so well throughout the day. In another case, the client may be so efficiently and thoroughly giving feedback on our iteratively delivered work that sprint reviews and demos become redundant. Or we might exercise some kanban principles by setting rules for ourselves to limit work in progress, working on one or two stories at most and never any more. This would reduce debt caused by inefficient multitasking. But we wouldn’t necessarily be ferociously calculating story lead times vs. cycle times, as some kanban disciples demand. We focus on delivery and communication, rather than being a stickler for rules that aren’t the right fit for the project.

What We Focus On

However, there are other things that we hold onto for dear life. Aligning with extreme programming practices, any chance we get to pair with other nerds or client engineers, we’ll do so, especially when it means ensuring success. Also, we’d never merge a particular branch into master until the code’s been reviewed by fellow Nerds. And even then, the code would have to pass unit tests before being integrated anyway.

At the end of the day, two questions ultimately drive our approach to process around product development:

• Is everyone (Big Nerd Ranch and our client) confident in each other’s ongoing contributions?
• Are our deliverables (design assets or code) built towards maintainability and elegance?

If the answer to these questions become “I’m not sure” or “no,” then we start implementing the appropriate methodology process(es) to right the ship. If the answer is “yes!” however, we throw off any burdensome and unnecessary weight. The purpose of a methodology is to ensure transparency and quality. The Scrum practice of doing retrospectives would be a helpful tool in gauging how the team feels about hitting those marks. Then adjust accordingly; nay, with agility!