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 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:
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:
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.
Once you have the goals and people idea in your head, a lot of the standard agile practices do make sense:
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:
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?
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.