The Agile Conspiracy

There’s no conspiracy. But agile is a silly process for n00bs. So why are established companies who hire the best of the best still doing it?

Agile Software Development is a “set of principles” according to Wikipedia. I prefer to call it a productivity system. People don’t implement Agile because they are swayed to new principles in general, they implement it because they want their teams to ship more and better code, and hopefully, make more money.

I was introduced to Agile in 2014 when I came back to coding after getting my degree. I had previously worked on my own projects, a startup in San Jose, and the incubator Science. I also had contract work here and there – but these startup experiences formed my approach to coding and building web technology products. Of course, we didn’t use Agile. We didn’t use anything. There were no buzzwords and no meetings. If you had a question, you went and bothered the person if they were within walking distance, and texted, emailed, or called if otherwise. We simply gathered, discussed, planned, and everyone who was involved in creating was involved in planning. Every person was involved in asking questions. I would ask a lot of questions, I like to keep things written down, and I’ve never had a problem with this very simple system that everyone basically learns in school. Listening – Asking – Writing Down. I’m gonna call it LAWD and then charge $3,000 for seminars on how to implement it. Lawwwwwd, help us.

Why is Agile a “conspiracy?” Well, for one, it promises that it will save us from waterfall projects. Of course, I have never in my life worked on a waterfall project, because I’ve worked at startups mostly. I am not in danger of waterfall. Waterfall is Agile’s straw man.

Another thing Agile does is add layers of people between people by creating “Product Managers”.

Full disclosure: I am, ironically, a product manager.

I don’t think this role always fosters efficiency. I think the job that “Project Managers” do should be done by everyone on the team. Everyone should listen, ask questions, do research and be involved in planning the specific work that they are involved in. Product design decisions about a technical product should be made by whoever implements. For the following reasons:

  1.  The classic principle of “skin in the game.” If something goes wrong, a developer has to get on late and fix it. That developer may not have had a choice in designing the product in a way that would be better technically and better for his schedule. Not giving them the choice is the worst use of a technically skilled person. They, after all, are the expert on the topic. And they have the most to lose from a bad call – they have to lose the work they already did.
  2. Technical products need technical designers. If you decide how a technical product is built, you should know how to build one, and you should actually go through and build it. Even as a former engineer, the fact that I don’t actually build the products I plan and design give me a huge disadvantage. I find myself guessing when I shouldn’t be.
  3. In theory, a product owner would filter out information from stakeholders and pass it on. In practice, it becomes a game of telephone. Agile fosters misinformation just as much as when you build the mythical waterfall projects.

I believe Agile is a reaction to bad developers. Bad developers only care about code, have no interest in the product they are building or the goals of the business even though the code they are writing directly impacts it. Agile seems to push developers out of most of the process – and focus them on writing code. This is inefficient and boring for good developers. The skills web developers have give them a lot of power over the companies they work for. A good developer can assess the strengths and weaknesses of an implementation. They can spot areas for opportunity. By having nontechnical people plan technical products, we are throwing out most of the fun of development – which is being able to make a big difference with a small amount of work.

In the end, Agile is trying to simulate the experience of a small startup where a few people get together to build something by hand. It is a decent attempt, but not a great one. As someone new to product management, I have challenged myself to think about how to solve these problems. My first reaction has been to look at the team as a sports team, and dictate as little as possible. This requires that I’m a channel of communication. No matter how you look at it, the solution is clear from the start – the engineer needs to be in control of his work. How we get there with stakeholders on board is a process I am trying to figure out. Right now, I’m starting to think my role should be centered around talking to customers and users and not product design.

Agile is about productivity, output, and business outcome. I think business outcome should be the only goal. I think people should sit around and think about stuff. I think meetings should be random. Sometimes no output could mean better long-term outcome.* This is why Agile can be a trap.

*I’ve heard this concept referred to as sharpening the axe.

Leave a Reply

Your email address will not be published. Required fields are marked *