From Agile to Anarchy

I have a love / hate relationship with Agile. Conceptually, I love it. Practically not so much. Since I was first exposed to it in 1999 though Object Mentors at Office Depot, it has always been present either in name or some form of practice. I and my teams paid the price of agile but we never seemed to reap any of the promised rewards. It was easy to be seduced by the Agile “no process” process, but on reflection we simply traded one heartless bitch for another. Yes, Agile is a process and quite an unforgiving one. It became apparent to me that you are either “all” Agile or not Agile at all. If your company is not 100% all in from dev to CEO then you are headed for problems. Trying to write good software with a bad Agile process is not fun.

With the introduction of micro services and docker a new SDLC is needed, but first here are some of the issues I have observed over the last 17 years in many different companies.

Agile is my safe word

Put 10 “Agile” experts in a room and … nothing; I just think it would be funny. Everyone is an Agile expert and yet most can’t agree on what the Agile process is and are certain that while we are an Agile shop we don’t practice Agile like it should be practiced.

Pair Programming

I could not sell pair programming to management. Nope, not once in 17 years. Oh, I could dabble in it from time to time but to call it a “practice”? not even close. Upon reflection it seemed that some team member just could not do it for very long. Some were good and some less so. It was more of a temperament than experience.

Story Points equals how many days?

No matter how many meetings I have to try and explain how this is supposed to work, there is always someone still thinks there is a direct or indirect relationship to time.

Is it Done or Done Done

In agile “Done” is smoke and mirrors. I know story points, blah blah blah. But done is so easily manipulated in Agile. Features are reduced to finish sprints and business stateholders are forced to accept it. The stakeholder gets discouraged because he knows that the rest of his feature is going into the “back log” black hole never to see th light of day.

In business everything is based on dates. Are you paid on a certain date? Would you accept part of your paycheck being moved to the next sprint because they payroll team could not get to it? I don’t think so. How can we expect a business that needs revenue or has to sign a contract based on a date accept what is supposed to be an engineering process that plays fast and loose with the rules?

Every other engineering discipline has to deal with dates and why do programmers need a sytem that basically ignores dates as key component of the system.

A couple of years back I was interviewed by company that was hard core Agile. They did scrum, story points, burndowns, retrospectives, you name it they did it. I remember speaking with the CEO and he quite proudly showed me that the development team had never missed a sprint end date in 15 months. I was impressed. I signed on and we moved 2 or 3 stories out of the next three sprints because the burndown showed we could not complete them. I think my 8 month old granddaughter Harper can make dates under these rules.

Technical Debt

One of the latest technical buzz words, “Technical Debt”. It sounds better in a meeting to say “Techical Debt” than steaming pile of %!$#. The Agile process builds up technical debt over time. It is built into the process. When you start on feature “A” you code 90% code and maybe refactor 10%, fast forward three years later and updating the same feature “A” takes 10 times as long due to refactoring. refactoring code and tests is now say 80% and new code is 20%. After several years the code is such a mess – thus the phase “your code has been Agiled”.

Lack of Engineering


Agile takes engineering out of the picture. There is simply no reward to remove dead code or do any more than is necessary to make the code “green”. Recently debugging an issue I came across the following code [Insert the hilarious code you found here]. You see there was a story to add this tsting code but no one ever wrote one to take it out and so for the last five plus years it has sat there and added some 40 million rows to a table.

Agile seems to lose site of the big picture; the code as a system. We are poking and prodding at it adding features here and there, but seldom take a giant step back and look at it an engineered system. Code is green so all must be well.

Skill level equality

There is and underlying presumption that all programmers have the same skill level. Over time in subsequent sprints, after being assigned a story the we find code may have been written by someone with a higher or lower level of skill. Typically this results in

  • The more experienced programmer rewrites the code.
  • The less experienced programmer thinks he understands it, add new code and creates a less than optimal implementation.
  • The less experience programmer thinks he understands it, rewrites the code and totals fubars it.

Site Footer