A version of this article originally appeared on Cognitect blog.

One of the wonderful things about working in software is that every company, every system and every project is a little experiment in group dynamics. From the tiniest of startups to the most massive of enterprises, behind every information system are teams of people who spend a lot of time collaborating. And when people work together a lot they tend to develop their own idiosyncratic vocabulary. Certainly we at Cognitect have our own jargon. At Cognitect everybody knows that a Cognation is our periodic company meeting, that the Zoom Party (think group video call) happens on Fridays and that it is better to elide than to complect. Everyone at Cognitect also knows the difference between agile and Agile.

Since this is print, I’m using some font tricks to represent what is primarily a difference in pronunciation: Think of Agile as being projected from the diaphragm of a Shakespearean actor during a critical bit of the script, perhaps To Agile or not to Agile? or maybe You feelin’ Agile punk?

In contrast, agile is said in the familiar tone you would use for a particularly handy tool: Hey could you hand me the three-quarters-inch agile?

The Two Agiles

The real question, aside from pronunciation, is what’s the difference? To us, Agile (the Kenneth Brannagh version) is the mainstream vision of agile, a family of software development methodologies built around some key practices:

• Standups
• Iterations
• Development stories - with or without points
• Some version of self organization
• Retrospectives

Let me start by saying that I’m a fan of each of these practices. In my experience software projects that do some or all of these things tend to succeed while projects that do none of them tend to end up face down in the gutter. But as valuable as they are, I don’t think that these practices are at the core of the monkey wrench version of agile.

To get to that core you need to dig into why these practices became associated with agile (either flavor) in the first place. In fact, you need to go all the way back to the manifesto that started it all, which (in part) says:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Despite the name – manifesto sounds like something you work on from the comfort of your Federal prison cell – there’s a vital idea lurking inside those four sentences. And that idea is:

To get the job done you need to focus on the goal and the people who will get you there.

Processes and tools are great, but in the end it’s the people and not the rule book that get things done. So if the goal is working software, then working software is more important than the tools, processes and documentation that you use or generate along the way. And if working with your customer is a key to success then work with them. And if getting to working software is the point then be prepared to tear up the plan the minute the plan gets in the way. That’s what we at Cognitect mean when we talk about the monkey wrench version of agile: Focus on the goals and the people who will get you there.

Goals and People

Once you have the goals and people idea in your head, a lot of the standard agile practices do make sense:

• Frequent short, informal meetings help to keep everyone pulling in the same direction, so sure, let’s have stand ups.
• Breaking up larger goals into smaller chunks helps get things done, so let’s have iterations.
• Knowing what you need to do next is always helpful so let’s have stories to describe what we're doing.
• And if your people have the goal firmly in mind, you can leave it to them to get much of the project organized.

But while the classic agile practices make sense, they are not an end in themselves. At Cognitect we do projects large and small, from enormous e-commerce and financial applications for giant enterprises to much more modest systems for tiny but innovative start ups. For some customers we have built the whole thing, all the way from an idea to launch. At other times we worked side by side with the clients, helping them turn their vision into bytes. Still other clients have pulled us in for training, where our job is to help them get better at their job. And on other projects we have been more like advisors, looking over the plans or the code and offering expert advice.

If there is one thing that is clear from our experience doing projects long and short for customers large and small, it is that one size does not fit all:

• Stand ups are great, but you can’t go round the room quickly if there are fifty people on the project. At the other end of the spectrum stand ups are also silly if it’s just you and your partner working together day after day.
• Incremental progress is great, but can you iterate your way to an overall architecture for a giant fault tolerant distributed information system?
• Stories are wonderful, but what if your project is more research than development? Or what if you are still trying to figure out what it is you need to build? What’s the point value of vision? What if your job is to train another developer? Don’t you need something that looks less like a story and more like a lesson plan?
• And how much self organization can you have if the vision is fuzzy or the domain is beyond most of the team.

What we’ve learned is that there is no magic recipe, no set of practices that will guarantee success. We’ve found that if you try to build information systems with a recipe, if you put your faith in a standard playbook of processes and practices, you are setting yourself up to make a bitter discovery about reality: Reality is a jerk. Sooner or later reality will find something that your rules can’t handle and lob that thing right into the middle of your project.

At its heart, the monkey wrench version of agile says that in order to be agile you need to actually be agile in the sense that civilians use the word: You need to be ready to throw away the rule book and bob and weave and flex with whatever comes next. You need to improvise, adapt and overcome. Above all, agile means keeping your eye on the fundamentals: What are the goals? And how are we going to get there?

… And Results

At the risk of repeating myself, let me say it again. Here at Cognitect we do the standard agile processes and I think we do them well. We’ve iterated our way through hundreds of software projects. We have run more retros than most people have had hot lunches. And we’ve written more stories than Stephen King. But we also know that iterations, retros and stories are just a means to an end. When they make sense, we use them. When they don’t we let them go without a moment’s regret. Agile isn’t a rule book, it is the absence of a rule book. Here at Cognitect our focus is on the goals and the people who will get you there.

As I say, at Cognitect we don’t do Agile. We do agile. In other words, we focus on people and results.

– Russ