Live data from Hacker News

Warning Signs that Agile Is Declining

javacodegeeks.com

31–40 of 95 posts

Re: Warning Signs that Agile Is Declining

#31
I hate to use the word "Agile" because the very act of naming seems to encourage the nonproductive behaviors the OP is talking about. Calling it a "process" is even worse, because it's a metaprocess, not a process.

Like he says, "it's the doing, the reflecting, and the adapting that count the most." That doesn't really need a name; that's just how you become good at anything. Software, jazz piano, raising chickens...anything.

Any productive methodology is a local adaptation to local conditions. Any codified methodology should be treated as a suggestion, not a constraint. If you stop observing and adapting your methods, they rapidly become less relevant and eventually turn into useless dogma. I'm pretty sure that just about anyone who is good at doing anything does this without being told, or giving it a name.

Re: Warning Signs that Agile Is Declining

#32
I've worked in a global company pushing agile, as well as currently running my own start-up. My problem with Agile (with a capital A) is that it has become something it didn't set out to be.

Individuals and interactions over processes and tools

Agile has become about processes and tools. Tools for burn rate management, estimation processes, test-driven development is a process.

Working software over comprehensive documentation

Documentation is now done, just in a different place. We seem to document everything but the product. Processes/interactions/estimation accuracy. And then this point is just used to not even produce any helpful/lightweight documentation by the end.

Customer collaboration over contract negotiation

BA's and managers speak to customers. They claim to be collaborating, but in reality, it's just a contract negotiation. You want x, we can deliver y, it will cost z. Even within a corporation, it's just contract negotiation. Devs still aren't pushed to talk to customers, and managers still don't understand estimation. Incentives are poorly aligned.

Responding to change over following a plan

People following Agile still have a plan. It just takes into account burn-rate, and a few other metrics. Changes still hurt, because the deadlines don't change. However, customers are now told it's OK "We can respond to change!".

These days, my aim is to get stuff working and maintain motivation. No more, no less.

Re: Warning Signs that Agile Is Declining

#33

Required reading: “We tried Baseball and it didn’t work.” http://xprogramming.com/articles/jatbaseball/

That's a really bad analogy. People can, and do, play cut-down versions of baseball all the time (in Britain we call this kind of game "rounders". It has very flexible rules, and yet I've never seen it "not work").

I’ve played rounders in Nigeria. But it isn’t a cut-down version of Baseball, it’s its own game :-)

As far as the analogy is concerned, I don’t see it suggesting that you can’t cut Baseball or Agile or anything else down. For example, XP started as a bunch of practices cut down to what its proponents felt were the essentials! What I personally read in the story is that if you are given something new, you have to embrace it for what it is and learn to do thing sits way if you want to benefit from it.

If you fight against it at every turn because it feels different or awkward, you are going to end up neutering it, and it will not be a surprise that it doesn’t deliver what you hoped.

I have experienced the exact same thing with programming languages. If you try to write Java programs in Clojure, you will walk away very unsatisfied with the result.

Re: Warning Signs that Agile Is Declining

#34
post #21

I worked at a company which tried to push agile process upon us in a 'top-down' fashion. I believe this is a cargo cult behaviour caused by a lack of understanding of underling development issues. Late-running projects that don't meet requirements are often a result of poor communication and a lack of concrete requirements. This is clear to most business people. What isn't so noticeable to many is that software devel…

Thanks for this post. I agree wholeheartedly. A lot more effort has to be put into the 'learning your process' part. The problem is that this requires self-reflective and humble individuals who are willing to work on improving their skills. I see far too many who are not willing to improve and learn, and most of these individuals lurk at big companies. Such an individual sees only imposed constraints in the methodology, and no possibilities. Since these passive individuals are easy to control, management has formed as a constraint-imposer and controller above them. Introduce a new methodology, and the workers will only (rightfully) complain while the management translates it into control constraints. So the problem lies not within the process, but the individuals. Start with improving the attitude, then let the team members bring in useful parts from methodologies as tools to reach the goals you have set together.

Re: Warning Signs that Agile Is Declining

#35

Required reading: “We tried Baseball and it didn’t work.” http://xprogramming.com/articles/jatbaseball/

I always have the impression that Agile is sort of like the True Scotsman or the Communist Manifesto

"If it didn't work, it's because it isn't really agile."

Re: Warning Signs that Agile Is Declining

#36
post #35

Required reading: “We tried Baseball and it didn’t work.” http://xprogramming.com/articles/jatbaseball/

I always have the impression that Agile is sort of like the True Scotsman or the Communist Manifesto "If it didn't work, it's because it isn't really agile."

Absolutely this is the case. But not to single Agile out unfairly: Although people are doing a lot of great work researching processes and so on, Software Development as an industry is like this.

Consider Waterfall. If you try it, and it doesn’t work, proponents will tell you that you were doing it wrong with all the changes late in a project. If you try Ruby and your code is a mess, Ruby programmers will say it isn’t the language, you failed to write good Ruby code.

And so on, ad infinitum.

So, if I agree with you, why did I post this? Not because I assert that Agile will “work” if you just do it right, but that I think it’s wrong to modify it and then blame it for not working.

Come to think of it, if you do it “right” and then succeed, I also think it’s wrong to give it the credit. But that’s another story.

Re: Warning Signs that Agile Is Declining

#37
Agile is just another in a long line of fads that try to use management "methodologies" to make programming a commodity that can be done by line-workers. It's not, and it can't be made so. Programming is a highly skilled craft.

Good code is written by good programmers. Bad code is written by bad programmers. Bad management can hobble good programmers, but no form of management can make bad programmers write good code.

(I'm not saying agile is bad, necessarily, just that it does not live up to its hype.)

Re: Warning Signs that Agile Is Declining

#38
post #12

I Can't agree more. I successfully applied agile ONCE during my 6 year tenure at a fortune 100. When approached with the question of what I thought was needed to make agile work, my reply was simple: "start with a good team who can handle it." That advice was of course tossed aside as corporations (especially middle managers) whose primary concern is the ability to shift resources cannot fathom the notion that agile…

From being on a few agile projects at Fortune 100s, I can attest to this. I once worked in parallel with another agile team that was doing a separate but integrated portion of an entire solution (it was a bunch of apps under one umbrella/initiative). At the risk of tooting my own horn, the other team was disbanded after three months without progress. The inherent problem that I saw was how those companies treat devel…

Regardless of whatever process you throw at these large companies, if you have a mediocre staff, expect mediocre results.

I agree about staff, but I also think that mindset is a huge component. There are organizations out there that consider software to be a necessary evil, something that they have to do in order to do the real stuff that needs to get done.

Other organizations consider software development to be a strategic advantage. Something that they can do more quickly or more effectively to make the organization succeed.

If you're at a "necessary evil" organization, neither talent nor methodology will save you.

Re: Warning Signs that Agile Is Declining

#39
post #37

Agile is just another in a long line of fads that try to use management "methodologies" to make programming a commodity that can be done by line-workers. It's not, and it can't be made so. Programming is a highly skilled craft. Good code is written by good programmers. Bad code is written by bad programmers. Bad management can hobble good programmers, but no form of management can make bad programmers write good code…

I feel you got it backwards. The whole idea behind agile is to treat programming as a craft and to focus on the people, as opposed to treating development as a production line.

Some good readings on the subject: Extreme Programming Explained, Agile Software Development Ecosystems, Balancing Agility and Discipline.

Re: Warning Signs that Agile Is Declining

#40
post #37

Agile is just another in a long line of fads that try to use management "methodologies" to make programming a commodity that can be done by line-workers. It's not, and it can't be made so. Programming is a highly skilled craft. Good code is written by good programmers. Bad code is written by bad programmers. Bad management can hobble good programmers, but no form of management can make bad programmers write good code…

Agile is just another in a long line of fads that try to use management "methodologies" to make programming a commodity that can be done by line-workers

It's sad that so many people have that perspective. I've always looked at it in the opposite way. I mean, the first part of the agile manifesto is "People over Process" and the first wave of agile evangelists were actual programmers and not fad-prone management types.

Post reply on HN