6 ms·

If I had a coin for every time someone replied to these kinds of posts with "That's not Agile! You're not doing Agile properly! True Agile is..blah..blah".....w

If I had a coin for every time someone replied to these kinds of posts with "That's not Agile! You're not doing Agile properly! True Agile is..blah..blah".....well, I'd have a few coins! I have had Agile/Scrummy Agile/FrAgile/Enterprise Fragile shoved firmly down my throat in every single job I've work since 2006. Rather than actually let the software professionals do their job, other non-technical people insist on these poor excuses for a micro-management methodology. Just this week, I was asked by our resident enterprise management consultant to put hourly estimates and actual hours worked on all of my assigned 20+ User Stories. He said "This is Agile 101! All of the best teams in the world do this! Follow the process!" Today, he wants me to add estimates and actual hours to my 20 Bugs and bug-fixes too, plus add tasks to each User Story explained what work I actually did. Nevermind that I'm the only developer 100% allocated to the project, so there's only one person to micro-manage I suppose! Shouldn't commonsense prevail in these modern times? No? lol :-P Edit: Is it possible for one to get paid just to rant about how terrible Agile is?

__derek__ 4y ago
No True Scotsman is indeed a popular fallacy.
aliswe 4y ago
To be completely fair, what you are describing is not truly agile :)
- misterflibble 4y ago
  Aha! Now I'm rich! :-D
plaguepilled 4y ago
As a fellow anti-agile dev, I can understand why its so prevalent. Labour estimates are crucial for business, even if they're bad - the goal is to improve iteratively over time and gradient-descend towards an accurate picture of resource allocation. Is there a better way to do this than agile? No duh, but that's another topic. :-)
- misterflibble 4y ago
  I'm happy to provide whatever estimates are desired by the business, and I'm sure all other programmers would too. But...most of the time I'm estimating something that I haven't done before (or for a long while), so they're bogus! The common pattern I've seen is that everything is about estimates, which end up becoming deadlines. The management worry about them to the point of bloody-mindedness, at the neglect of gathering actual requirements from the customer. In my company, I work in a software department (I suppose we're an internal agency with just one customer). But, we can't speak directly to the customer and instead speak to another Project Manager (apparently because of "SaFE Enterprise Agile" policies), so we can't ask the customer what they truly need, and so the product isn't accurate, and neither are those estimates!
  - plaguepilled 4y ago
    Estimates become deadlines because most managers don't understand the terms 'statistical variance' and 'sample size', not because the estimates are made. ;) Entering a contract with a client based on an estimate without a large margin for error is a statistical failing, not a strategy one. That said, I still think waterfall and other related variants are overwhelmingly the way to go. I've done both styles and the difference is night and day.
- BlargMcLarg 4y ago
  >Labour estimates are crucial for business, even if they're bad - the goal is to improve iteratively over time and gradient-descend towards an accurate picture of resource allocation. I have two problems with this. One, almost all work that is easily estimated falls into the realm of trivial work. Most work is not trivial given the rapidly changing work environments. If it isn't the tech itself, it's the people around you and above you. If it isn't the people, it's some context which in common human fashion, has become overcomplicated to high heaven. Two, because things change so rapidly and riskmanagement is the way it is, we are in a perpetual state of businesses trying to pressure one another into getting the best short term deals at the cost of almost everything else. How many times has a deadline not been met with it being critical? Not that often, most things can wait another month. So why do we keep making unrealistic deadlines? (Semi-rhetorical)
keyle 4y ago
Yeah measuring efforts in hours is the wrong kind of agile. That's the whole point of their effort point system. Also the fact that you're alone and only you to do them means it will get done when it will get done and they should only prioritise items in a list. Sorry you seem to hate agile and I could see why but hopefully some day you get to be part of an effective team with a common sense approach to agile.
- misterflibble 4y ago
  I really appreciate your comment and yes, I hope I find another team soon. Or better yet, hopefully I'll be replaced by a script (like an AWS lambda or an Azure function), ánd then I'll have all day to rant on HN. Beware! lol :-]
- ljw1001 4y ago
  Every team I’ve ever seen converts effort to burn down rate and then into time, because that’s what their bosses care about. Now 50 points per week with a team of five is 10 points per person-week or two points per person-day. So a point is 4 Hours. Next we multiply by the number of points in the backlog and we have our delivery date. If you don’t keep turning out two points per day the project will be late and there’s gonna be a problem. Estimating in points is just what the magician does so you don’t see what he’s really up to.
dave_sullivan 4y ago
Maybe the time is right for anti-agile coaches to call all the companies that bought agile coaching over the past 15 years. I guess they'd be talking about why waterfall was best all along. I think some of the root issue is the annoying micromanagement and lack of trust from non technical stakeholders. They need to chill out, but it's in their nature to be dicks somehow. They think if only they plug numbers into a spreadsheet correctly, huge savings will just pop out. But really they waste time and annoy the hell out of people. Maybe anti-agile is "fire all the nontechnical managers". Agile as a system of prioritization isn't bad, but human factors mess it up a lot.
- misterflibble 4y ago
  Yes I definitely feel that technical expertise and trust is needed in decision making for all projects. In my current team, developers don't have much influence (lol um.. I mean just me as I'm the only 100% full stack) and we have non-technical leadership. One problem is our tech leader isn't familiar with our programming language or development framework (worked with a different stack entirely). Also, both the tech leader and the Scrum master do not trust us to make any API or front end changes that aren't listed on the sprint board. Everything must be decided during sprint planning for the two-week sprint. So, if there's some code that obviously needs refactoring, or small code improvements (i.e. anything that's not on the board), every Pull Request is rejected. What's that you say? "Create an explanatory task/story ahead of time, and mention it during planning?" Sorry, I've tried that many times and they were all de-prioritised and post-poned. So, no trust both ways it seems! and now I'm ranting on HN Edited: grammar
- hef19898 4y ago
  >> I think some of the root issue is the annoying micromanagement and lack of trust from non technical stakeholders. They need to chill out, but it's in their nature to be dicks somehow. Sure. And now imagine that one of those people encounters your proverbial, arrogant, software solves it all developer. The results, if there are any to begin with, are glorious (gloriously unusable).
  - BlargMcLarg 4y ago
Gareth321 4y ago
I've been lucky in that I haven't had to argue with agile consultants claiming their 90s project management techniques are agile. I feel fairly confident I'd raise holy hell until either they fuck off or admit that our organisation is no longer agile. You want to work like it's the roaring 90s again? No worries! Just don't lie to me to get me in the door. In this job market we have options.
- misterflibble 4y ago
  Your words honestly give me hope that there's a better place to work! lol
  - Gareth321 4y ago
    I promise you there are! My most recent interview was me interviewing them. I grilled multiple managers over multiple interviews over their culture, ways of work, their expectations, etc. I made my expectations crystal clear, and they accepted these without question. If they lied I'll simply leave. Tick that little box in LinkedIn and start interviewing workplaces for one which aligns with your values. It's easily the best time in 40 years to be shopping around for better employers.
    - misterflibble 4y ago
      I think I'll take your advice and start ticking that LinkedIn box tonight! Cheers!
  - wink 4y ago
    I've seen my fair share of broken "Agile" processes but officially estimating bugs for more than "hey, do you think this is small or big?" for urgent stuff sounds even more terrible. I'm sorry you have to endure this :(
newusertoday 4y ago
would you buy a tool that creates automated report for you to make management consultant happy?
jillesvangurp 4y ago
Great software was produced before agile became a thing and lousy software continued to be made after it. And agile is of course not a thing but an adjective. Everybody wants to be seen as doing things in an agile fashion. It's an aspirational goal. The opposite of doing things with some agility would be sluggishly. There's a difference between what people say they do, what they would like to do, and what they actually do. But generally, sluggishness is not something you call out as a good thing. Hence world+dog is doing agile now. Even when they are obviously being ineffective and slow. Any time you see a product manager plan 10 sprints ahead, you know that whatever that is supposed to be, it involves a lot of pre-planning before anything has actually happened. We used to call that waterfall. Planning is not actually a bad thing. It's just when those plans are unrealistic, infeasible, or very rigid that they become a problem. That was always the problem with waterfall. The plan was treated as set in stone and two months into the project it became a bad plan. That still happens a lot. People come up with bad plans all the time and then get sucked into believing in that plan. Being agile means having the tools to adjust the plan when it needs changing. If your PM sells a six month 12 sprint project four months before engineers even look at it, you know it's going to be a mess. The plan is probably wrong and the clock started ticking long before engineers got involved. But on the other hand, when you sell a project, there needs to be more than a "we'll see what we do and how long it will take". This fundamental dilemma was never really solved by agile. I'm less concerned with agile as a noun or adjective these days. Everybody does some form of that; so there's very little point in splitting hairs over it. I'm more concerned with processes and practices. And as an engineer, cto and product manager, my observation is that processes are introduced when automation and common sense fail. Getting rid of unnecessary process is form of agility that is good. I'm always on the lookout for those. When it comes to sprints, I treat them exclusively as planning horizons. Checkpoints where we assess where we are relative to the current plan and decide on what to focus on in the near future. We practice continuous integration and continuous deployment. The life cycle of a sprint and of a feature bear very little relation to each other. Work might start one sprint and then a few sprints later the change might get merged and deployed. Or the work is planned, executed, and shipped during a single sprint. Or even in between sprints. I define work here to cover the whole process of inception, business requirements gathering, design, implementation, and deployment. It's fundamentally an asynchronous thing. Features ship when they are ready, not when a sprint ends. Work on features starts either when planned or when prudent/urgent. Some things just can't wait and generally, I like short cycle times for work. There is no need for synchronization bottlenecks in the form of meetings, commit freezes, sprint reviews, or other things we had to do in the past. Because we have asynchronous tools now. Up until the merge, the feature is not interacting or interfering with the software. After the merge, the CI/CD is fully automated. There's just one manual step: clicking the merge button. Doing this in an agile way means doing that without unnecessary delay but with all the due diligence of testing, reviews, etc. And it's nice if that goes according to a plan.
Joeri 4y ago
I find it helpful to distinguish between Agile, the thing that is waterfall in new terminology, and agile, the philosophy of how to flexibly adapt the way of building software to the lay of the land. You "do" Agile, or you "are" agile, never both. The litmus test is quite simple: are sprints planned more than one sprint ahead? If an organization has a schedule where they map work to sprints months in advance, they are doing Agile. If they just have a backlog and the only planning they do is in preparation of the next sprint, they stand a chance of being agile.
jokethrowaway 4y ago
There is agile in practice and then there is the https://agilemanifesto.org/ https://agilemanifesto.org/ The agile manifesto is purely common sense, everything else is useless managers je*ing off.
felix_n 4y ago
That sounds excruciating. I've had those various pieces but never all at one job. I hope you grind that twerp under your tires while driving away after quitting in some epic fashion.
tiberriver256 4y ago
Sounds like you're working with someone who has never even taken the time to read the agile manifesto. https://agilemanifesto.org/ https://agilemanifesto.org/ There is no mention of estimates at all lol.
- watwut 4y ago
  There is literally nothing else at all either. It is kinda short poem and that is all.
  - jmainguy 4y ago
    A manifesto if you will
- misterflibble 4y ago
  Lol omg in my last project team, no one was gathering requirements or doing analysis at all - noone! The developers asked every single day for someone to write down some basic requirements. Someone from the "product owner" team called is into a meeting to lecture us about "true Agile" and "The Agile Manifesto"....still no requirements after that! So I just left the team and cried.
Eddy_Viscosity2 4y ago
Surely you realize project development meta-data is far far more important and valuable than actual software development. How are managers going to fill excel sheets and make bar charts for powerpoint slide decks to show off their management prowess without it?
commandlinefan 4y ago
> Agile/Scrummy Agile/FrAgile/Enterprise Fragile shoved firmly down my throat The really frustrating thing is that what's now called "Agile" devolved from "Extreme Programming" (XP) which was as appropriate as it was poorly named. I first heard of it sometime around '99 or so, long after I had put up with my share of frustrations around the expectation that every programming task could be predicted ahead of time on the spot (and that every prediction was a few hours). XP, on the other hand, was a reasonable pushback against mismanagement: say what you want and then get out of the way and give them time to make incremental progress toward that goal. There were no estimates or deadlines in XP. There weren't any in the agile manifesto, either. However, what's now Orwellianly called "Agile" as "tell me right now on the spot how long it's going to take to deliver this vaguely defined piece of functionality so I can 'negotiate' it down to when I need it by"... which is exactly what XP and the agile manifesto were trying to explain was impossible.
- switchbak 4y ago
  I was in an XP shop in the semi early days, and it really was a grass roots counter reaction to the enterprise over the top culture of the time. In the teams I've worked on that had a good sense of the essence and spirit of agile principles, we've done extremely well. But it's always been context specific and very fluid. Where it's been a mandate from on high, where it's dogmatically enforced and people say things like "that's not Agile": it's always been a bit of a shitshow. Usually it's just window dressing on old school command and control style management. I've personally found almost all SCRUM teams I've been on to be more of the latter. Not all but close. I think fundamentally business school is just teaching a more static model than what really makes sense with modern software development, and that pervades throughout and beyond the organization. Hopefully we'll see that slowly evolve as competitive pressures punish the less adaptive ones.
bmitc 4y ago
I posted this same sentiment just yesterday: https://news.ycombinator.com/item?id=32502498 https://news.ycombinator.com/item?id=32502498 Some highlights: > How many books, conferences, certifications, practitioners, evangelists, etc. does it take to make a paradigm, supposedly the paradigm, of working actually work? > If the number one answer to we're using Agile but it's not working is "you're doing Agile wrong", then maybe Agile isn't the solution?

__derek__ 4y ago

No True Scotsman is indeed a popular fallacy.

aliswe 4y ago

To be completely fair, what you are describing is not truly agile :)

misterflibble 4y ago
Aha! Now I'm rich! :-D

plaguepilled 4y ago

As a fellow anti-agile dev, I can understand why its so prevalent. Labour estimates are crucial for business, even if they're bad - the goal is to improve iteratively over time and gradient-descend towards an accurate picture of resource allocation. Is there a better way to do this than agile? No duh, but that's another topic. :-)

misterflibble 4y ago
I'm happy to provide whatever estimates are desired by the business, and I'm sure all other programmers would too. But...most of the time I'm estimating something that I haven't done before (or for a long while), so they're bogus! The common pattern I've seen is that everything is about estimates, which end up becoming deadlines. The management worry about them to the point of bloody-mindedness, at the neglect of gathering actual requirements from the customer. In my company, I work in a software department (I suppose we're an internal agency with just one customer). But, we can't speak directly to the customer and instead speak to another Project Manager (apparently because of "SaFE Enterprise Agile" policies), so we can't ask the customer what they truly need, and so the product isn't accurate, and neither are those estimates!
- plaguepilled 4y ago
  Estimates become deadlines because most managers don't understand the terms 'statistical variance' and 'sample size', not because the estimates are made. ;) Entering a contract with a client based on an estimate without a large margin for error is a statistical failing, not a strategy one. That said, I still think waterfall and other related variants are overwhelmingly the way to go. I've done both styles and the difference is night and day.
BlargMcLarg 4y ago
>Labour estimates are crucial for business, even if they're bad - the goal is to improve iteratively over time and gradient-descend towards an accurate picture of resource allocation. I have two problems with this. One, almost all work that is easily estimated falls into the realm of trivial work. Most work is not trivial given the rapidly changing work environments. If it isn't the tech itself, it's the people around you and above you. If it isn't the people, it's some context which in common human fashion, has become overcomplicated to high heaven. Two, because things change so rapidly and riskmanagement is the way it is, we are in a perpetual state of businesses trying to pressure one another into getting the best short term deals at the cost of almost everything else. How many times has a deadline not been met with it being critical? Not that often, most things can wait another month. So why do we keep making unrealistic deadlines? (Semi-rhetorical)

keyle 4y ago

Yeah measuring efforts in hours is the wrong kind of agile. That's the whole point of their effort point system. Also the fact that you're alone and only you to do them means it will get done when it will get done and they should only prioritise items in a list. Sorry you seem to hate agile and I could see why but hopefully some day you get to be part of an effective team with a common sense approach to agile.

misterflibble 4y ago
I really appreciate your comment and yes, I hope I find another team soon. Or better yet, hopefully I'll be replaced by a script (like an AWS lambda or an Azure function), ánd then I'll have all day to rant on HN. Beware! lol :-]
ljw1001 4y ago
Every team I’ve ever seen converts effort to burn down rate and then into time, because that’s what their bosses care about. Now 50 points per week with a team of five is 10 points per person-week or two points per person-day. So a point is 4 Hours. Next we multiply by the number of points in the backlog and we have our delivery date. If you don’t keep turning out two points per day the project will be late and there’s gonna be a problem. Estimating in points is just what the magician does so you don’t see what he’s really up to.

dave_sullivan 4y ago

Maybe the time is right for anti-agile coaches to call all the companies that bought agile coaching over the past 15 years. I guess they'd be talking about why waterfall was best all along. I think some of the root issue is the annoying micromanagement and lack of trust from non technical stakeholders. They need to chill out, but it's in their nature to be dicks somehow. They think if only they plug numbers into a spreadsheet correctly, huge savings will just pop out. But really they waste time and annoy the hell out of people. Maybe anti-agile is "fire all the nontechnical managers". Agile as a system of prioritization isn't bad, but human factors mess it up a lot.

misterflibble 4y ago
Yes I definitely feel that technical expertise and trust is needed in decision making for all projects. In my current team, developers don't have much influence (lol um.. I mean just me as I'm the only 100% full stack) and we have non-technical leadership. One problem is our tech leader isn't familiar with our programming language or development framework (worked with a different stack entirely). Also, both the tech leader and the Scrum master do not trust us to make any API or front end changes that aren't listed on the sprint board. Everything must be decided during sprint planning for the two-week sprint. So, if there's some code that obviously needs refactoring, or small code improvements (i.e. anything that's not on the board), every Pull Request is rejected. What's that you say? "Create an explanatory task/story ahead of time, and mention it during planning?" Sorry, I've tried that many times and they were all de-prioritised and post-poned. So, no trust both ways it seems! and now I'm ranting on HN Edited: grammar
hef19898 4y ago
>> I think some of the root issue is the annoying micromanagement and lack of trust from non technical stakeholders. They need to chill out, but it's in their nature to be dicks somehow. Sure. And now imagine that one of those people encounters your proverbial, arrogant, software solves it all developer. The results, if there are any to begin with, are glorious (gloriously unusable).
- BlargMcLarg 4y ago

Gareth321 4y ago

I've been lucky in that I haven't had to argue with agile consultants claiming their 90s project management techniques are agile. I feel fairly confident I'd raise holy hell until either they fuck off or admit that our organisation is no longer agile. You want to work like it's the roaring 90s again? No worries! Just don't lie to me to get me in the door. In this job market we have options.

misterflibble 4y ago
Your words honestly give me hope that there's a better place to work! lol
- Gareth321 4y ago
  I promise you there are! My most recent interview was me interviewing them. I grilled multiple managers over multiple interviews over their culture, ways of work, their expectations, etc. I made my expectations crystal clear, and they accepted these without question. If they lied I'll simply leave. Tick that little box in LinkedIn and start interviewing workplaces for one which aligns with your values. It's easily the best time in 40 years to be shopping around for better employers.
  - misterflibble 4y ago
    I think I'll take your advice and start ticking that LinkedIn box tonight! Cheers!
- wink 4y ago
  I've seen my fair share of broken "Agile" processes but officially estimating bugs for more than "hey, do you think this is small or big?" for urgent stuff sounds even more terrible. I'm sorry you have to endure this :(

newusertoday 4y ago

would you buy a tool that creates automated report for you to make management consultant happy?

jillesvangurp 4y ago

Great software was produced before agile became a thing and lousy software continued to be made after it. And agile is of course not a thing but an adjective. Everybody wants to be seen as doing things in an agile fashion. It's an aspirational goal. The opposite of doing things with some agility would be sluggishly. There's a difference between what people say they do, what they would like to do, and what they actually do. But generally, sluggishness is not something you call out as a good thing. Hence world+dog is doing agile now. Even when they are obviously being ineffective and slow. Any time you see a product manager plan 10 sprints ahead, you know that whatever that is supposed to be, it involves a lot of pre-planning before anything has actually happened. We used to call that waterfall. Planning is not actually a bad thing. It's just when those plans are unrealistic, infeasible, or very rigid that they become a problem. That was always the problem with waterfall. The plan was treated as set in stone and two months into the project it became a bad plan. That still happens a lot. People come up with bad plans all the time and then get sucked into believing in that plan. Being agile means having the tools to adjust the plan when it needs changing. If your PM sells a six month 12 sprint project four months before engineers even look at it, you know it's going to be a mess. The plan is probably wrong and the clock started ticking long before engineers got involved. But on the other hand, when you sell a project, there needs to be more than a "we'll see what we do and how long it will take". This fundamental dilemma was never really solved by agile. I'm less concerned with agile as a noun or adjective these days. Everybody does some form of that; so there's very little point in splitting hairs over it. I'm more concerned with processes and practices. And as an engineer, cto and product manager, my observation is that processes are introduced when automation and common sense fail. Getting rid of unnecessary process is form of agility that is good. I'm always on the lookout for those. When it comes to sprints, I treat them exclusively as planning horizons. Checkpoints where we assess where we are relative to the current plan and decide on what to focus on in the near future. We practice continuous integration and continuous deployment. The life cycle of a sprint and of a feature bear very little relation to each other. Work might start one sprint and then a few sprints later the change might get merged and deployed. Or the work is planned, executed, and shipped during a single sprint. Or even in between sprints. I define work here to cover the whole process of inception, business requirements gathering, design, implementation, and deployment. It's fundamentally an asynchronous thing. Features ship when they are ready, not when a sprint ends. Work on features starts either when planned or when prudent/urgent. Some things just can't wait and generally, I like short cycle times for work. There is no need for synchronization bottlenecks in the form of meetings, commit freezes, sprint reviews, or other things we had to do in the past. Because we have asynchronous tools now. Up until the merge, the feature is not interacting or interfering with the software. After the merge, the CI/CD is fully automated. There's just one manual step: clicking the merge button. Doing this in an agile way means doing that without unnecessary delay but with all the due diligence of testing, reviews, etc. And it's nice if that goes according to a plan.

Joeri 4y ago

I find it helpful to distinguish between Agile, the thing that is waterfall in new terminology, and agile, the philosophy of how to flexibly adapt the way of building software to the lay of the land. You "do" Agile, or you "are" agile, never both. The litmus test is quite simple: are sprints planned more than one sprint ahead? If an organization has a schedule where they map work to sprints months in advance, they are doing Agile. If they just have a backlog and the only planning they do is in preparation of the next sprint, they stand a chance of being agile.

jokethrowaway 4y ago

There is agile in practice and then there is the https://agilemanifesto.org/ https://agilemanifesto.org/ The agile manifesto is purely common sense, everything else is useless managers je*ing off.

felix_n 4y ago

That sounds excruciating. I've had those various pieces but never all at one job. I hope you grind that twerp under your tires while driving away after quitting in some epic fashion.

tiberriver256 4y ago

Sounds like you're working with someone who has never even taken the time to read the agile manifesto. https://agilemanifesto.org/ https://agilemanifesto.org/ There is no mention of estimates at all lol.

watwut 4y ago
There is literally nothing else at all either. It is kinda short poem and that is all.
- jmainguy 4y ago
  A manifesto if you will
misterflibble 4y ago
Lol omg in my last project team, no one was gathering requirements or doing analysis at all - noone! The developers asked every single day for someone to write down some basic requirements. Someone from the "product owner" team called is into a meeting to lecture us about "true Agile" and "The Agile Manifesto"....still no requirements after that! So I just left the team and cried.

Eddy_Viscosity2 4y ago

Surely you realize project development meta-data is far far more important and valuable than actual software development. How are managers going to fill excel sheets and make bar charts for powerpoint slide decks to show off their management prowess without it?

commandlinefan 4y ago

> Agile/Scrummy Agile/FrAgile/Enterprise Fragile shoved firmly down my throat The really frustrating thing is that what's now called "Agile" devolved from "Extreme Programming" (XP) which was as appropriate as it was poorly named. I first heard of it sometime around '99 or so, long after I had put up with my share of frustrations around the expectation that every programming task could be predicted ahead of time on the spot (and that every prediction was a few hours). XP, on the other hand, was a reasonable pushback against mismanagement: say what you want and then get out of the way and give them time to make incremental progress toward that goal. There were no estimates or deadlines in XP. There weren't any in the agile manifesto, either. However, what's now Orwellianly called "Agile" as "tell me right now on the spot how long it's going to take to deliver this vaguely defined piece of functionality so I can 'negotiate' it down to when I need it by"... which is exactly what XP and the agile manifesto were trying to explain was impossible.

switchbak 4y ago
I was in an XP shop in the semi early days, and it really was a grass roots counter reaction to the enterprise over the top culture of the time. In the teams I've worked on that had a good sense of the essence and spirit of agile principles, we've done extremely well. But it's always been context specific and very fluid. Where it's been a mandate from on high, where it's dogmatically enforced and people say things like "that's not Agile": it's always been a bit of a shitshow. Usually it's just window dressing on old school command and control style management. I've personally found almost all SCRUM teams I've been on to be more of the latter. Not all but close. I think fundamentally business school is just teaching a more static model than what really makes sense with modern software development, and that pervades throughout and beyond the organization. Hopefully we'll see that slowly evolve as competitive pressures punish the less adaptive ones.

bmitc 4y ago

I posted this same sentiment just yesterday: https://news.ycombinator.com/item?id=32502498 https://news.ycombinator.com/item?id=32502498 Some highlights: > How many books, conferences, certifications, practitioners, evangelists, etc. does it take to make a paradigm, supposedly the paradigm, of working actually work? > If the number one answer to we're using Agile but it's not working is "you're doing Agile wrong", then maybe Agile isn't the solution?