Skip to main content

Agile is still dead and has been since 1991

[updated 2011.09.30] yet another response to Agile is good.
When you have so much of you career invested in something like Agile, XP etc... it can be hard to see the forest for the trees. I had a consulting job in The Haag many years ago. IBM was the incumbent contractor at the customer site (a bank) but after 5 years on the job they had not written a single line of functioning code. In the office there were two teams of software people... both behind closed doors. The first team was the Data team and the second team was Functional. They rarely spoke and they never shared information. I was there for a week, introduced the client to OO and we had a functioning prototype. Smart people do smart things, You cannot make an underachiever exceptional by using Agile. Either they get "it" or they don't.

I just commented on a blog. I'm sure there is some validity to his post beyond observing that Agile Scrum is broken. It certainly is not what it was originally intended but for that you have to go way back to Dave and Andy from PragProg. I have not found the original links and references myself but I recall enough from my reading at the time. Today's Agile does not look anything like what it was.
Scrum deflects from individual accountability. But the failure of agile/scrum is probably more psychology than technology. There are essentially three groups of people. 1) the high achievers that you want everyone to emulate; 2) the average devs; 3) and the low achievers. The high achievers hate these processes because it simply adds friction to their day. The low achievers love it because it deflects individual responsibility (think Survivor or Big Brother; the best do not always win. Floater is a legitimate strategy). And the average achiever is ambivalent and can be tipped either way.

Everyone is different and creative in their own way. You cannot herd cats with agile or scrum.

Agile does not treat people with respect. It dictates with strict rules what and how things are to be done. When the reality is that we have individual and collective responsibility. And most of that is encapsulated in an unwritten "bill of rights" that we carry around with us. At least the high achievers do. Translating that BOR to everyone else with a wide brush is simply too general an approach. Improvement from the under achievers comes from training, education, and more then anything else experience and experience from making mistakes.

The real chalenge here is that businesses are trying to grow their ranks as fast as they can. Many times that means hiring people that they would not hire if there was not such a shortage. This is a different set of problems from Agile and Scrum. This problem can be fixed by being selective, selecting people with aptitude for the work, selecting tools that lower the bar of entry, and managing people rather then allowing them to manage themselves.


  1. I like the title of the article you pointed to: Agile: Delivering broker software since 1991.

    In any case, I don't think Agile is dead, in fact, everything points that it's still alive and kicking (even PMI now has an agile certification)

    Agile has its limitations, of course, but it's far from being dead...

  2. I have an appreciation for continuing education as I make a point of learning as many difficult concepts a year as I can handle. (usually one solid programming language). However certification is the paper dragon's playground and is only valuable in the absence of a professional career or formal education.

    As for Agile being dead. Well, it's not really (but it should be)... and if the certification mills, scrum dojos, and certified PMs who have dedicated their entire careers to agile do not stop taking themselves seriously agile cannot advance to the next stage of life; which could be death.

    Agile fails because it does not reliably scale or replicate. And it actually promotes mediocrity and not excellence. But that's just my experience as I watched several teams grow from 15 to 250 developers.

  3. It seems like the gloves are coming off in the Agile discussion; I've seen more anti Scrum or at least highly questioning of Scrum blog postings lately than previously;

    Before it was mostly rah rah fluff pieces.


  4. True. I think it's a much more complex subject than it once was and it has become polarized.

    One of the curious things I've noticed recently; very many job postings list "agile" or "SDLC" as part of the description or requirement. Is it an invitation or a warning?

    Don't get me wrong. Some process is good but you are NEVER going to replicate the success of the top 2% or maybe 10% by implementing a "process".

  5. I don't know that it's more of a complex subject than it once was, but there are more people doing Scrum than have been done previously.

    Scrum is too simplistic and prescriptive to work in the real world; now that people have more real world experience with it, and the problems are so obvious after 6 months or so, that we are seeing more people step up and say something besides fawning over the "new".

    I've been trying to wake people up to these issues for almost a decade and it's been (previously) like crying in the wind.

    Well, now people can revisit my postings and be more proactive hopefully! Or they can just keep believing in the simple gospel preached but the consulterati.

  6. You (and most agile critics) are assuming that there are high achievers and low achievers and that people cannot pass between these categories. In fact that is far far from the truth. You should read Mindsets by Carol Dweck.

    And there is plenty of data to show that agile projects are cheaper than other methods. Agile succeeds just because it replicates the values and principle in highly successful teams. And because it treats teams and organisations as what they are; complex adaptive systems.

  7. I do not believe I ever said that programmers, agile coaches/project managers could not pass between categories. Everyone can have a bad day or project. I'm fairly certain that if Tom Clancy, a fiction writer, had to write a Pascal or Ada programmer's manual he'd slip to low achiever. But that's a guess.

    While there have been studies I have criticized them too. Scott Ambler at AmblerSoft is a perfect example. He gave an Agile survey to Agile professionals. One would expect that the results would be skewed.

    Let's admit one thing. High achieving agile coaches are not going to have much effect on a high achieving team where a low achieving agile coach might have the exact opposite results. The same could be said about the opposite. Low achieving teams are not likely to be improved by low achieving agile coaches but a high achieving coach might be able to improve the low achieving team.

    The Agile Manifesto, the birthplace of Agile, says nothing about high/low achievers. It certainly declares "process" as a second class system. And in general the Agile Manifesto is a fraction of what Agile has become. I do not think that teams need a Agile coach to read and reread the manifesto. It's a solid set of principles and while it does not specifically reject Scrum, Scrumban and Kanban there does seem to be some conflict. As a matter of cost; there are only 12 basic principles and that does not require a coach.

  8. I was reading this last night and was amazed at the correlations between the things listed on that page and what we see every day in the agile community



Post a Comment

Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).


I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…