5 ms·

(Author of The Art of Agile Development here.) Lots of negativity in this thread. I can't say I'm surprised. For what it's worth, I mostly agree with the negati

(Author of The Art of Agile Development here.) Lots of negativity in this thread. I can't say I'm surprised. For what it's worth, I mostly agree with the negativity—"Agile," as commonly practiced, tends to be terrible. That's part of why I wrote the new edition. I say as much in the first paragraphs of the book: > Agile is everywhere. And paradoxically, nowhere. > In the 20 years after the Agile freight train roared into software developers’ consciousness, the number of companies calling themselves “Agile” increased by orders of magnitude. The number of teams actually taking an agile approach to their work? Not so much. “Agile,” the easily repeated name, is enormously successful. The ideas behind Agile—well, most of them are ignored. > Let’s fix that. If anybody would like to talk about the book, I'm happy to engage. If you're curious about the book, the first three chapters are currently up for free on my website, and there's a lot of excerpts from the remaining chapters posted too. Follow the links in the table of contents at the bottom of https://www.jamesshore.com/v2/books/aoad2 https://www.jamesshore.com/v2/books/aoad2.

recursivedoubts 5y ago
I think many aspects of Agile are sensible enough in most situations. My negative experience with Agile has mainly been through people who are ideological about it and insist, when agile fails, that it was not the fault of the process or some other factor, but rather the fault of the people who "didn't implement agile right." A bit of humility from the Agile community would be very welcome, as well as clarification of what types of problems it works well for and which ones it doesn't, where the dangers are, etc.
- jdlshore 5y ago
  I can't grant you humility from the Agile community, or even necessarily from myself, but I can clarify what problems it works well for and doesn't, dangers, etc. Agile works well when organizational leaders are willing to invest in changing the constraints of their organization, and team members are similarly willing to work to customize the philosophy—'cause that's all it is, a way of thinking about software development—to their specific situation. Given those two things, I've yet to find a type of software development where Agile didn't work. People have used its ideas for web development, embedded systems development, back-end, front-end, Java, C++, JavaScript, etc. etc. But those two things can be really really hard, which is why I think cargo-cult Agile is so common. And trying to be Agile without them is dangerous, in that it can easily be worse than whatever it replaced. I talk about them more in chapters 4 and 5 of the book. You can find an excerpt of chapter 4, including a list of the investments needed, here: https://www.jamesshore.com/v2/books/aoad2/invest_in_agility https://www.jamesshore.com/v2/books/aoad2/invest_in_agility
TeeMassive 5y ago
My own experience with (lack of) Agile development: - Water Epic Fall. An obvious symptom of Cargo Cult Agile. This happens when the phases of a waterfall project are disguised as epics that represent a huge fraction of the development. In my own experience this is caused when the MBAs try to force Scrum from top to bottom so they can pretend that they're doing agile on paper and thus "fulfill the values(tm) of the company". This is even worse than usual waterfall because it places an artificial limitation on making multiple components of the project live and evolve together and so "world collides" when each time an epic "is closed" and the new one has to find a place to fit, somehow. Proposition: epics are a way to breakdown work and work is done by a the team and so leave it to the team doing the work. Rule of thumb: stories are defined by time while epics are defined by stories with a common concrete idea. - Daily meetings are mostly reports to the boss. Proof of that was when the boss wasn't there meetings that normally endured for 30 minutes and more would only take 10 minutes. In none of these meetings the boss helped to resolve the blockers; other devs did. Proposition: no boss in daily standup; DSMs are a tool for and by the dev team. - Devs are blamed for not finishing stories in time. This is usually due to a bad backlog grooming where definition of ready is left as an exercise to the reader. It is also a symptom of the Water Epic Fall described above. Devs has to deal with the fact that the code isn't simply ready to integrate the new feature but the exercise to check if it was was never done in the first place. This is made worse when it is the dev who estimated the story and is now "responsible" for it. Also made even worse when "architects" with veto power decides what is ready or not and what the stories are. Proposition: again, let the devs have the final words on the backlog and its stories. - Asking for permission to fix problems and remove friction. This is usually a problem caused by survivor biased MBAs who think of the heroics they did 20 years ago as war medals and a good development methodology because after all "this is why we could afford our new building". This problem often forms a symbiotic relationship with a culture of fear lead by barons aka "team leads". Proposition: revolt. Seriously. "We can't work this way anymore" during the quarterly report mega-meeting in front of the C*Os has its impact. Otherwise change jobs and make sure to let HR know by naming names. It's sad to see this kind of situation but if you don't it will poison every aspect of your life. - Nobody RTFM. Seriously. Who can say they have read at least one book on Lean/Agile/Scrum/DevOps from cover to cover? I would say most MBAs didn't because there's an entire industry based on giving very expensive courses and on agile consulting just to repeat verbatim what are on these books. And even then most of the time you will never heard of concepts such as "lead time", "feed back", "release often", "no wip", etc. Some devs do tho, but they usually quit when they realize that their conversion efforts go to waste and provoke the wrath of the MBAs and the Teams Leads(tm) because either "we're not a startup" or "we can't be like Google" - Large teams. Scrum doesn't really say much about how to work with multiple teams. Even less so where you're dealing with hardware and firmware development.
trhway 5y ago
>"Agile," as commonly practiced, tends to be terrible > The number of teams actually taking an agile approach to their work? Not so much. Classic no true Scotsman. That inept excuse gets always invoked by the proponents of Agile, Lean, Scrum, Six Sigma and Communism.
- jdlshore 5y ago
  No True Scotsman isn’t what you think it is. > No true Scotsman, or appeal to purity, is an informal fallacy in which one attempts to protect their universal generalization from a falsifying counterexample by excluding the counterexample improperly. (Wikipedia) “It doesn’t work because you’re doing it wrong” is not an example of the fallacy. (For example: “A: Light bulbs suck because they don’t light up when you smash them into your head. B: That’s not how lightbulbs work. A: No True Scotsman!” Yeah, no.)
  - trhway 5y ago
    Classic double down on the Scotsman by a consultant right from Agile consultants training. Original version for commenter below as he is making an issue out of the edit: "Classic double down on the Scotsman by a consultant"
    - jdlshore 5y ago
      You’re being pretty offensive to someone who you don’t know, and who has only been polite to you. (Note: thrway edited their comment after I responded.)
      - trhway 5y ago
        Another classic from the snake oil pushers - trying to deflect criticism by painting it as personal offense. I don't know you and said nothing about you outside of what you just posted here. I met a lot of consultants pushing the stuff like you and I'm talking about that stuff that they and you push and how they and you do it.
  - 5y ago
corpMaverick 5y ago
I have been a proponent of Agile approach since the 90s (XP, Tom Gilb, RAD, Lean). But lately, I am really really hating it. People no longer understand what Agile is about. They just follow some Scrum practices and that´s it. I feel disempowered. How do I find a job that gets it ?
- jdlshore 5y ago
  I wish I knew! There are companies that get it, but they're hard to filter out from the noise. Two I'm aware of are Pivotal and Menlo Innovations. I'm sure there are more.

recursivedoubts 5y ago

I think many aspects of Agile are sensible enough in most situations. My negative experience with Agile has mainly been through people who are ideological about it and insist, when agile fails, that it was not the fault of the process or some other factor, but rather the fault of the people who "didn't implement agile right." A bit of humility from the Agile community would be very welcome, as well as clarification of what types of problems it works well for and which ones it doesn't, where the dangers are, etc.

jdlshore 5y ago
I can't grant you humility from the Agile community, or even necessarily from myself, but I can clarify what problems it works well for and doesn't, dangers, etc. Agile works well when organizational leaders are willing to invest in changing the constraints of their organization, and team members are similarly willing to work to customize the philosophy—'cause that's all it is, a way of thinking about software development—to their specific situation. Given those two things, I've yet to find a type of software development where Agile didn't work. People have used its ideas for web development, embedded systems development, back-end, front-end, Java, C++, JavaScript, etc. etc. But those two things can be really really hard, which is why I think cargo-cult Agile is so common. And trying to be Agile without them is dangerous, in that it can easily be worse than whatever it replaced. I talk about them more in chapters 4 and 5 of the book. You can find an excerpt of chapter 4, including a list of the investments needed, here: https://www.jamesshore.com/v2/books/aoad2/invest_in_agility https://www.jamesshore.com/v2/books/aoad2/invest_in_agility

TeeMassive 5y ago

My own experience with (lack of) Agile development: - Water Epic Fall. An obvious symptom of Cargo Cult Agile. This happens when the phases of a waterfall project are disguised as epics that represent a huge fraction of the development. In my own experience this is caused when the MBAs try to force Scrum from top to bottom so they can pretend that they're doing agile on paper and thus "fulfill the values(tm) of the company". This is even worse than usual waterfall because it places an artificial limitation on making multiple components of the project live and evolve together and so "world collides" when each time an epic "is closed" and the new one has to find a place to fit, somehow. Proposition: epics are a way to breakdown work and work is done by a the team and so leave it to the team doing the work. Rule of thumb: stories are defined by time while epics are defined by stories with a common concrete idea. - Daily meetings are mostly reports to the boss. Proof of that was when the boss wasn't there meetings that normally endured for 30 minutes and more would only take 10 minutes. In none of these meetings the boss helped to resolve the blockers; other devs did. Proposition: no boss in daily standup; DSMs are a tool for and by the dev team. - Devs are blamed for not finishing stories in time. This is usually due to a bad backlog grooming where definition of ready is left as an exercise to the reader. It is also a symptom of the Water Epic Fall described above. Devs has to deal with the fact that the code isn't simply ready to integrate the new feature but the exercise to check if it was was never done in the first place. This is made worse when it is the dev who estimated the story and is now "responsible" for it. Also made even worse when "architects" with veto power decides what is ready or not and what the stories are. Proposition: again, let the devs have the final words on the backlog and its stories. - Asking for permission to fix problems and remove friction. This is usually a problem caused by survivor biased MBAs who think of the heroics they did 20 years ago as war medals and a good development methodology because after all "this is why we could afford our new building". This problem often forms a symbiotic relationship with a culture of fear lead by barons aka "team leads". Proposition: revolt. Seriously. "We can't work this way anymore" during the quarterly report mega-meeting in front of the C*Os has its impact. Otherwise change jobs and make sure to let HR know by naming names. It's sad to see this kind of situation but if you don't it will poison every aspect of your life. - Nobody RTFM. Seriously. Who can say they have read at least one book on Lean/Agile/Scrum/DevOps from cover to cover? I would say most MBAs didn't because there's an entire industry based on giving very expensive courses and on agile consulting just to repeat verbatim what are on these books. And even then most of the time you will never heard of concepts such as "lead time", "feed back", "release often", "no wip", etc. Some devs do tho, but they usually quit when they realize that their conversion efforts go to waste and provoke the wrath of the MBAs and the Teams Leads(tm) because either "we're not a startup" or "we can't be like Google" - Large teams. Scrum doesn't really say much about how to work with multiple teams. Even less so where you're dealing with hardware and firmware development.

trhway 5y ago

>"Agile," as commonly practiced, tends to be terrible > The number of teams actually taking an agile approach to their work? Not so much. Classic no true Scotsman. That inept excuse gets always invoked by the proponents of Agile, Lean, Scrum, Six Sigma and Communism.

jdlshore 5y ago
No True Scotsman isn’t what you think it is. > No true Scotsman, or appeal to purity, is an informal fallacy in which one attempts to protect their universal generalization from a falsifying counterexample by excluding the counterexample improperly. (Wikipedia) “It doesn’t work because you’re doing it wrong” is not an example of the fallacy. (For example: “A: Light bulbs suck because they don’t light up when you smash them into your head. B: That’s not how lightbulbs work. A: No True Scotsman!” Yeah, no.)
- trhway 5y ago
  Classic double down on the Scotsman by a consultant right from Agile consultants training. Original version for commenter below as he is making an issue out of the edit: "Classic double down on the Scotsman by a consultant"
  - jdlshore 5y ago
    You’re being pretty offensive to someone who you don’t know, and who has only been polite to you. (Note: thrway edited their comment after I responded.)
    - trhway 5y ago
      Another classic from the snake oil pushers - trying to deflect criticism by painting it as personal offense. I don't know you and said nothing about you outside of what you just posted here. I met a lot of consultants pushing the stuff like you and I'm talking about that stuff that they and you push and how they and you do it.
- 5y ago

corpMaverick 5y ago

I have been a proponent of Agile approach since the 90s (XP, Tom Gilb, RAD, Lean). But lately, I am really really hating it. People no longer understand what Agile is about. They just follow some Scrum practices and that´s it. I feel disempowered. How do I find a job that gets it ?

jdlshore 5y ago
I wish I knew! There are companies that get it, but they're hard to filter out from the noise. Two I'm aware of are Pivotal and Menlo Innovations. I'm sure there are more.