Friday, September 30, 2011

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



another bad day for open source

One of the hallmarks of a good open source project is just how complicated it is to install, configure and maintain. Happily gitlab and the ...