Devil’s Advocate: Don’t Be Agile

Continuing our series on the pros and cons of popular technical topics for non-technical managers. We look today at the concept of Agile Development and how it will really #$%* you and your developers over.

As a developer, there are three words I dread hearing when I’m interviewing at startups:

We are agile-ish.

Or really any variation thereof: agile inspired, agile influenced, kind of agile. UGH. Going agile is like going gluten-free: doing it half-way causes more pain than not doing it at all.

So just don’t be agile.

The Spirit of Agile is Trusting Your Developers to Lead

To non-technical managers Agile is appealing because it means getting results fast. Indeed, agile promises a MVP in your hands ASAP, a quick launch, followed by growth growth growth.

Who wouldn’t love that?

But the problem with Agile Development is that most non-technical managers do not really do much research into why Agile methodology gets results so quickly. They don’t realize that Agile aims to move the decision making power out of their hands and into the hands of their developers. They think that by importing the format of Agile– sprints and scrums and whatnot– efficiency will just naturally follow. They micromanage, which is exactly what Agile Development is trying to prevent, and when delays hit they micromanage even more.

Agile Development aims to destroy the typical model of “the waterfall” where in orders of what to build come down from above for programmers to execute. That doesn’t mean that non-technical team members have no place in the process. On the contrary, non-technical team members, particularly customers and other stakeholders are a vital part of Agile Development.

But in order to work, programmers in Agile need the freedom to experiment, and to execute without getting caught up in multiple levels of management approval. Agile aims to create small teams where consensus and collaboration are easier.

What typically happens in “Agile-ish” situations is that as developers work on initial product specs, they must constantly come back to the non-technical manager for clarification or adjustment. As the non-technical manager tries to save time and money, acting as Agile Development intends– that is experimenting with one approach, collecting feedback and evolving– become nearly impossible. Building in systems to collect feedback are resources not devoted to the core product and are usually put off until “later”. Testing out new ideas is resented, as non-technical managers have already decided what they want to be built and perceive these experiment as time and money taken away from the real product. (This is particularly true when the dev team is working freelance)

Agile Development relies on the assumption that you trust the judgement of the people you’ve hired and therefore do not feel the need to dictate every element of every decision to them. After all, what does the manager’s opinion on the position or color of a button matter if you’re going to experiment with different options and choose the one that is the most successful with the customer?

But too often non-technical managers get caught up in policing their technical staff in order to eliminate waste. They are afraid of the false starts that Agile Development tells them to embrace. They want Agile, but they want an impossible hybrid of Agile where all the decisions about the product are made in the beginning and are all 100% right.

This is not Agile Development at all. The first rule of Agile Development is to assume that you’ve gotten some aspect of the product wrong and to structure your process around systematically identifying and correcting those mistakes. Even if by some miracle you do manage to get everything 100% correct the first time, business situations change. Products need to evolve.

Yet in the Agile-ish development cycle the product must first be built exactly as the non-technical manager wants it. If the non-technical manager has overlooked a decision or a problem comes up, the dev team must wait for commands. To take initiative and to try a solution without the non-technical manager’s approval is insubordination. Feedback from customers are cherry picked and reinterpreted by the manager. When one component of the product is finished, very little effort is “wasted” talking with stakeholders. It’s more important to move on to the next feature.

And so it goes…

Agile + Remote == Death

What is it that people do when they want to be Agile without actually giving up the control necessary to be Agile? They take on the structure of Agile Development without any of the philosophy and end up with an impossible boondoggle in code. We’ve all experienced the horrors of failing Agile: the 15-min stand-ups that last for two hours, the endless series of planning meetings, “sprints” composed mainly of bug fixes and tweaks because not enough time was budgeted for proper testing and code review.

Agile relies on free flowing communication between members of a small team. Co-location, while not absolutely essential, is considered extremely important.

When your team is remote, especially when they are spread out across timezones, the type of informal collaboration and communication Agile aspires to becomes very difficult to achieve. As a result the daily morning “stand up” becomes the primary (and sometimes sole) method of communication between team members. Instead of fifteen minutes touching base, these conference calls become impossibly bogged down with conversations that would have naturally happened throughout the work day if everyone was working out of the same space.

It is possible for a remote team to be Agile, but it is very difficult … especially when the team members are strangers to each other.

Becoming Agile: Spirit First, Process Second

The goal of Agile Development is to rid dev teams of bureaucracy by throwing out the restrictions of stuffy management processes. It is therefore ironic that the first thing non-technical managers do when going Agile is ignore Agile Development’s core philosophy and skip straight to implementing their processes. Agile development, when poorly done, has become the very monster it was intended to slay.

Its core principles read something like a eulogy now:


  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Self-organizing teams
  12. Regular adaptation to changing circumstances


If you aren’t willing to sign up for that, just don’t be Agile.

Devil’s Advocate: Don’t Use Open Source

Do to the nature of our work, we frequently collaborate with non-technical organizations. This is the first part of what we’re calling our “Devil’s Advocate” series, intended to help non-technical people make better technical decisions by presenting the negative side to current tech trends.

Don’t use open source.

Don’t get me wrong, I love open source. I use open source projects and I contribute fixes back to them whenever I can. Open source is great.

But open source does not make solutions instantly better, more democratic, or more transparent. A lot of organizations– particularly nonprofits– insist upon open source because the philosophy of the open source movement matches their own ideals. Well, that’s nice, but technical decisions should be made based on technical arguments. Open source is the right solution when there’s an open source project that fits what you want to build.

Far too often nontechnical managers ask the dev team to take an open source project and completely alter the functionality without realizing that it’s harder and takes more time to do that than it would have to build something custom. The manager thinks using open source should make the project cheaper and speed up turn around time, if that doesn’t happen he gets frustrated by the work ethic of the programmers. “Why isn’t this done already?” he might ask. “The open source project works out of the box, all you need to do is just make these tiny changes.”

Granted there are considerable advantages to going with an open source solution. It is easier to onboard new devs. You benefit from an established community of devs without having to pay them. You have a mature, fully functioning platform to test various ideas on.

But that last advantage is exactly why open source might be the wrong solution for you.

As code “matures” good developers reorganize it to remove duplicate functions and make it easier to maintain. From a nontechnical mindset it is difficult to understand what these periods of “refactoring” (translation: code clean up) are really doing or why they are necessary. Too often nontechnical managers see refactoring as a period where nothing is getting done because the devs were sloppy and have to go back and fix their mistakes! But all devs, even the best in the business, write code that eventually has to be refactored. It’s an important part of how software evolves.

Imagine we had two functions: send_email which takes values from a form, generated a request to the server to send an email … and forward_email which takes values from a form plus values from a database and generated a request to send an email. We wrote send_email before we knew that we would ever want forward_email, but when someone requested the ability to forward emails that sounded like a good idea so we quickly copy and pasted send_email and changed a few things before renaming it forward_email. Now suppose that we realize we have made a mistake writing the code to generate the request. Or maybe we hadn’t made a mistake at all, maybe we upgraded to a new version of something and that required a change. Both send_email and forward_email need to be updated… but if we had created a third more generic function (say generate_mail_request) and moved the code that wrote the request out of send_email and forward_email, then we would only need to change generate_mail_request.

This is the concept of “abstraction”, building reusable bits of code that several parts of the application will use to do the same thing.

The process of minimizing and reusing code is essential to project growth. However, it can also make changing small things more difficult if the change conflicts with the way the program was designed to behave. This is why taking an open source piece of software and making “a few changes” may in fact take longer and be more difficult than writing the same software from scratch. If the open source project is mature enough it has probably been refactored a few times, creating several layers of code that effect hundreds of features and functions.

Assessing the Ease of Your Desired Change

At the same time most mature open source projects do in fact assume you will want to change things around a bit. Their programmers work in pathways where certain changes can be made quite easily. The trick is understanding whether the customizations you want fit into that system or not.

As a general rule it is usually possible to change the way an open source project looks. If the project has a templating system, there should be an easy way to override the default templates with your own.

For mature and complex projects it is also usually possible to add new, independent features pretty easily. Since these tasks leave the core behaviors alone they only need a place to hook into so the open source application knows it’s there.

The big question mark is always how much of the existing behavior can be changed, that will depend on whether what produces the behavior in question is a link in the template, client side javascript, or something in the server side code and if in the code, how deep?

Open Source as Parts of a Whole

Now that you’ve heard all the consequences of picking an open source project over a custom solution, there’s good news: the best projects use both custom solutions AND open source. There’s an open source solution for practically every major feature you need, designed to slide easily into place with all kinds of different applications. So if you truly need something unique and there’s no open source platform that fits the bill. You can hire a developer to build something custom, but fill it with open source parts so that you’re not wasting time and money building things that someone else has already built. Pop in a login system, image uploading, commenting … all areas where there are several good open source options available.

And when you’ve finished your custom piece of software … you should definitely open source it 🙂