16 ms·

If you're getting burnout doing agile, you're doing agile wrong. Don't do sprints. Have a continuous backlog. Don't do overtime. Don't make estimates. Always d

If you're getting burnout doing agile, you're doing agile wrong. Don't do sprints. Have a continuous backlog. Don't do overtime. Don't make estimates. Always do the simplest thing. Only ever do the most important thing, as defined by the stakeholder. I've written and talked about this at great length. The fact people suggest agile gives you burnout reinforces my experience that Scrum is largely misinterpreted and people incorrectly focus on sprint commitments. If Scrum is so commonly misinterpreted, it is flawed. https://www.linkedin.com/pulse/scrum-makes-you-dumb-daniel-jones https://www.linkedin.com/pulse/scrum-makes-you-dumb-daniel-j... https://youtu.be/k9duArRuSjQ https://youtu.be/k9duArRuSjQ

fatnoah 8y ago
Scrum is a framework to achieve "agility" and people forget that. The point is agility, not scrum.
- EngineerBetter 8y ago
  Indeed, and the Scrum-Industrial Complex has vested interests in codifying a certain format that it can sell.
  - reallydontask 8y ago
    not heard that term before (Scrum Industrial Complex) but it's pretty good, going to use it from now on :)
    - beat 8y ago
      I just used it in another comment. :)
- ako 8y ago
  And agility in this case being Business Agility: the business being able to change course, not being hold hostage to a years long plan which cannot be changed. Agility has nothing to do with software development, and everything with business.
- Scarblac 8y ago
  The point is making valuable software in reasonable time. Agility is a way to deal with the fact that the idea of what "valuable" is changes constantly.
- tetha 8y ago
  I tend to view scrum, kanban, XP and also the more traditional tools like V-model as tool boxes - or maybe some kind of pre-configured framework. They combine agile or other project management tools in order to solve problems the team or stake holders of the team have. However, this doesn't mean you can't take out and exchange parts. Some teams work profiles fit well with set sprints with a stable set of tasks. Others, like ops work with few people, doesn't due to incalculable factors like incident management. Prioritization might need different mechanics depending on the position and the responsibilities of the team. It's all a big grab bag of tools to create some working workflow for a team.
Scarblac 8y ago
The business wants to know how much feature X is going to cost and when they can expect it. They need to know that, because they need to decide if it's worth it in the first place, or because they need to plan follow-up actions for when the feature will be done. If the developer doesn't make estimates, you're just forcing other people to make their own estimates, that they'll hold you to.
- RandallBrown 8y ago
  Nobody should make estimates. They're always wrong. Do your best to break tasks up so that all tasks are the same size. Then work on tasks. You'll find a stable average of tasks per amount of time and that will let you forecast how long things will take, how much they'll cost, etc. That's how you figure out when things will be done.
  - PaulHoule 8y ago
    That is bull. Some tasks have a high degree of uncertainty. Others don't. Back when I was using a ruby-on-rails style framework (in PHP) I would frequently get 20 hours of work estimated properly down to 15 minutes when it came to adding simple features to a web application. If on the other hand you are trying to figure out the gap between what the documentation says should work and what actually works, that is hard to estimate.
    - carlmr 8y ago
      And nevermind the technical issues. If you need to work with others, that's where estimating gets hard.
  - lordCarbonFiber 8y ago
    That act of breaking up and organizing tasks of the same size, that's what estimation is. This feature has these tasks, historically we complete these tasks in this time, so here's a hard minimum for a completion date (which implies cost). Slap on an appropriate fudge factor for dealing with other teams, testing and burn in, and general error bounds as needed. You've described scrum, what you're doing is scrum.
justjash 8y ago
I agree with most of it minus the "Don't make esitmates" part. Without making some sort of estimate things just don't work. I guess maybe it could work assuming you fully control a single product. Everywhere I have worked we need the estimates simply for coordination of all the moving parts.
- spamizbad 8y ago
  I think by estimates they might mean deadlines. It’s well worth asking, as an engineer several questions like: “How complicated is this? What are all the moving parts? Whose going to need to be involved to get this out the door?” But it’s counter productive sometimes to say “ I think feature X will be completed by Y” and then that estimate turns into a deadline.
- eikenberry 8y ago
  Maybe you could rephrase it to "Don't make estimates before work is well underway". The main problem with estimates is that they are usually just wild guesses and pretty useless. But once you've got going on something, have had time to think it through and test your ideas, you can usually give at least a very rough estimate at that point.
hrktb 8y ago
> people incorrectly focus on sprint commitments. I think it's often the over approach from the manager/PM side: they will be looking for a methodology to have estimates and team commitment, and Scrum will be an option. There is an awful lot of PMs who will candidly explain that they don't really care about the methodology, they just need stuff to get done and know when.
jgust 8y ago
> Always do the simplest thing. Can you clarify? If you meant "always search for the simplest solution" I agree. If you meant, "always do the easiest tasks" I don't.
- chrisweekly 8y ago
  Simple != Easy I highly recommend this Rich Hickey talk (transcription): https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
  - jgust 8y ago
    Thanks!
LifeLiverTransp 8y ago
Its never the wrong socialism. Maybe actual agile as imagined is incompatible with captialsim and human nature?
- jeletonskelly 8y ago
  Would you prefer the centralized planning model of waterfall? Of course none of these systems are perfect, but it's been a major step in a better direction for everyone involved.
  - JohnFen 8y ago
    > it's been a major step in a better direction for everyone involved. I am not convinced that this is true.
  - LifeLiverTransp 8y ago
    What i would prefer, is to take a step back and look at all major interest partys involved, who will deform the development process. If management puts to much pressure on, a good process would give tech and the customer more chances to counter said pressure, to avoid tech debt and badly implemented features. I want a process that reacts to the situation, in favour of the product, in favour of longterm goals - who actively resists people who try to gamble it for whatever reason. Agile is not that.
    - droussel 8y ago
      "Agile" is a set of principles and values as defined in the Manifesto for Agile Software Development. If how you work contrary to those principles, then you simply are not "Agile", no matter if you call it that. "Agile" will never fix bad management, nor will anything else for that matter.
- jdauriemma 8y ago
  Agile was created to sell software to clients, so I think was intended to be very compatible with capitalism.
hopler 8y ago
"commitments" do not exist in Agile. Agile was created to remove commitments and insert collaboration in it's place. You don't have to make big promises when your client has ongoing clear visibility into your progress.
- JohnFen 8y ago
  That is technically be true, but I've worked at four shops that have implemented Agile methodologies and it hasn't been true for any of them, nor for most of the engineers I personally know but don't work with. I do personally know one person who works on a team that this is true, but he's the only one. This may be doing Agile wrong, but if something can be so easily done wrong that it's common, I count that as serious flaw in the methodology.
  - cromulent 8y ago
    agile is not a methodology though - it's a set of principles. Many so-called "Agile methodologies" put structures in place that prevent agility.
  - jdauriemma 8y ago
    I'd push back on calling Agile a methodology. [The Agile Manifesto](http://agilemanifesto.org http://agilemanifesto.org) a set of ideals, that's all. These ideals often run afoul of conventional wisdom in traditional management/business/sales circles, so we end up with a set of procedures masquerading as "Agile" in order to not upset prevailing sensibilities.
    - JohnFen 7y ago
      I did not call Agile a methodology. I referred to "Agile methodologies", as in "methodologies that are intended to adhere to Agile principles".
noxToken 8y ago
>Don't do sprints. Have a continuous backlog. Don't do overtime. Don't make estimates. Always do the simplest thing. Only ever do the most important thing, as defined by the stakeholder. The problem with this is that the stakeholder might not understand what simple means. It happens here all the time. We get "simple" requests for verbiage changes, but after reviewing the story, the verbiage request isn't universal. It only applies to certain offerings, and the stakeholders only want the verbiage the be applied after a certain step in the application. This is still a relatively simple change, but when factoring in all the other "simple" requests that involve complex logic, changing displayed text becomes relatively complex. We do sprints because it's our time box to see how close we are to hitting the mark. A sprint isn't a hard deadline in which the team must kill themselves to get everything finished. It's an arbitrary passage of time for setting goal to keep on track with what is going to be released. If you have something that's releasing two months into the future, it's easy to say that you can still make time although your first two weeks were riddled with unexpected complications and stoppages. A sprint forces us to focus on what should have already been completed to re-prioritize if necessary. And you can't feasibly do that without an estimation. The two biggest problems with estimations are underestimating and treating estimations as promises. It's hard to estimate. So the best course of action is to make stories as small as possible. Probably smaller than someone would consider rational. If not, at least have the stories divided into individual tasks or chunks. Then once you have estimations, treat them as goals rather than deadlines. Use your sprint review as a time to honestly reflect on why the estimation was missed. Then, and this is critical to successfully estimating in the future, use the notes of reflection to make better estimates.
- joncp 8y ago
  > The problem with this is that the stakeholder might not understand what simple means. It happens here all the time. "Do the simplest thing" means don't overengineer, not necessarily that the feature won't be complex. You only code up what helps fulfill that particular story's definition of "done." As for complex features. when my stakeholder asks for some big complex change it's almost always decomposable into much simpler stories. Maybe those have to be hidden behind feature flags until the whole epic is done, but they're shippable individually. Doing that decomposition up front helps demonstrate the complexity to the stakeholder and takes some pressure off of me. It also makes them feel secure because they have more granular insight into progress; that they're not sending me off on some Lewis & Clark expedition.
potta_coffee 8y ago
"Don't make estimates." Very few managers / CEOs are going to let you get away with this.
jayd16 8y ago
>Don't do overtime. Don't make estimates. Said another way, estimates are not promises. Don't crunch to meet them. I think it should be phrased as "no deadlines". The whole sprint structure is so you're constantly adjusting your plans and estimations at some predictable time. Without a sprint you can end up with randomization.
- asark 8y ago
  I've noticed some managers and project managers love to emphasize the that sprint plans are "commitments". "OK, is this what we're committing to for this sprint? Is everyone comfortable committing to this?". LOL. OK. Maybe that guilts the young bloods into doing free overtime or something. But no. It's like when car salesmen try to get you to name a number you'd definitely buy the car for and sign it on some not-at-all-binding-or-official piece of paper, like that means something, before they go back and "ask their boss if they can make it work". Psychological trickery bullshit.
  - acct1771 8y ago
    You work on a team with members that make you feel like you're buying a car..?
    - asark 8y ago
      It's a very similar psychological trick. I've even heard project managers I like and who I think are generally very good do it. I think it's just part of their language now, and some may not realize they're doing anything kinda shitty. But it's something straight out of Cialdini's Persuasion, and unsubtle enough that even I can tell what it is. "Do you feel comfortable committing to these stories?" Always a question. Committing. If you don't make it for any reason not obviously caused by "outside blockers" you're morally responsible—and maybe even then. What are you, some kind of liar? Quite a step from an estimate. Kind of harsher than a deadline, even, which are oh-so-rarely as "deadly" as the name implies. But people close enough to Scrumish processes to get in the meetings but far enough away not to be writing code or testing things or putting out designs sure seem to like that word. Commit.
diminoten 8y ago
You have to do estimates, it's how a business works. Not knowing when something will be delivered is too much to ask a company to deal with. Also, "always do the simplest thing" is one of those phrases that can be twisted and morphed to support literally anything, which makes the phrase useless. It feels good to hear and say, but the reality is it doesn't help you out of a jam. Sprints are exactly what you're describing, except with accountability built in. That shouldn't scare people, but it does, and that is what causes burnout. Fixing the fear around accountability is how you fix burnout, not eliminating the thing that your boss can use to justify your job.
tootie 8y ago
The number one reason agile projects fail in my experience has absolutely nothing to do with planning session, sprint cadence or estimation. It's because the client was not properly prepared to accept iterative delivery or play their part as product owner. I see a lot of team organize themselves around a well-groomed backlog and set their priorities only to have clients come in and ask for deadlines and fixed scopes and all the other stuff that is anathema to agile. If you client is able to set priorities effectively and allow a slower, quality-driven model then everything else becomes just so much easier.
- beat 8y ago
  I just read a marvelous book called Handmade, by a fine furniture woodworker, and something he says over and over is "Go slow to go fast". The sales pitch to the business for a well-controlled agile process is that it maximizes productivity. Shifting priorities and poor planning undermine the productivity of the development team.
  - gridspy 8y ago
    Yes, this is also worded as "Slow is smooth, smooth is fast" - used for instance when following emergency checklists. It's a good mantra when under serious pressure.
  - e12e 8y ago
    "slow is smooth, and smooth is fast" Ed: see also: "practice makes permanent".
  - vitro 8y ago
    I remember one movie scene where old sniper teaches young one "To be slow is to be precise, to be precise is to be fast"
- wool_gather 8y ago
  Ironically, such clients also seem to expect that whatever additions/changes they dream up should be able to be folded in to the plan willy-nilly. Whereas if they accepted an iterative process that would come naturally, without constant re-negotiation or ill will.
uhhhhhhh 8y ago
>Don't do sprints. Have a continuous backlog. Don't do overtime. Don't make estimates. Always do the simplest thing. Only ever do the most important thing, as defined by the stakeholder. you just described doing agile wrong... You're advocating for a version of agile lite, not agile. Or alternative, agile is different to everyone you talk to and your agile isn't the same as someone elses agile. Take your pick, but sprints, estimations, not only doing 1 thing/most important things are basic tenants of agile as most people see it.
- andrewprock 8y ago
  You are describing Scrum, not Agile. Scrum is a subset of Agile. There are many other Agile methodologies, including what the go outlined.
- fwip 8y ago
  The only thing consistent about Agile is that everyone is doing it wrong.
EngineerBetter 8y ago
Estimates seem to be a common topic in replies. If you can accurately estimate how long a software task will take, you should have already made a reusable component or automation to generate that code. Estimates are meaningless. I've seen PhDs waste endless hours faffing with estimate-calculating spreadsheets. Fundamentally, the universe is unpredictable. Chaotic and complex systems require their starting conditions to be measured to an infinite level of precision to be predictable. The Heisenberg principle means this is, as far as physics can tell, impossible. On a more practical macro level, a complex adaptive system becomes unpredictable once three feedback loops are present (the three body problem is related). Modern computer systems are unpredictable because we cannot predict the interplay between levels of abstraction. It does not matter how smart you are. Unless you have perfect knowledge of all levels of abstraction in the system below you, even in a macroscopic sense you cannot predict the future. Precise estimates will be inaccurate. Confidence ranges and superprobabilities are of some use. Discrete and precise estimates are an utter waste of time at best, and are dangerous and misleading at worst. EDIT Written on a mobile waiting for plane take-off, hence lack of citations. For more on complex adaptive systems, I recommend the works of Murray Gell-Mann and the research output of the Santa Fe Institute, particularly Scott E. Page.
- virtualized 8y ago
  Another way to put it: If you know how long something will take in advance, you have a solution in mind. It is unlikely that this solution is (A) the best one and (B) the one you will actually implement. It would be stupid to ignore information you learned along the way. If you could actually predict the future you should invest in the lottery, not in software. EDIT: Of course there are projects where you actually know exactly what to do. Happens a lot in consulting. That has nothing to do with Agile though.
  - EngineerBetter 8y ago
    > If you could actually predict the future you should invest in the lottery, not in software. Hear, hear!
mverwijs 8y ago
> The Product Owner prioritises the backlog Note: This would require a _really_ good product owner that does not merely focusses on features, but also on feasibility and 'fitness functions'. The rest of that article had me cheering all the way.

fatnoah 8y ago

Scrum is a framework to achieve "agility" and people forget that. The point is agility, not scrum.

EngineerBetter 8y ago
Indeed, and the Scrum-Industrial Complex has vested interests in codifying a certain format that it can sell.
- reallydontask 8y ago
  not heard that term before (Scrum Industrial Complex) but it's pretty good, going to use it from now on :)
  - beat 8y ago
    I just used it in another comment. :)
ako 8y ago
And agility in this case being Business Agility: the business being able to change course, not being hold hostage to a years long plan which cannot be changed. Agility has nothing to do with software development, and everything with business.
Scarblac 8y ago
The point is making valuable software in reasonable time. Agility is a way to deal with the fact that the idea of what "valuable" is changes constantly.
tetha 8y ago
I tend to view scrum, kanban, XP and also the more traditional tools like V-model as tool boxes - or maybe some kind of pre-configured framework. They combine agile or other project management tools in order to solve problems the team or stake holders of the team have. However, this doesn't mean you can't take out and exchange parts. Some teams work profiles fit well with set sprints with a stable set of tasks. Others, like ops work with few people, doesn't due to incalculable factors like incident management. Prioritization might need different mechanics depending on the position and the responsibilities of the team. It's all a big grab bag of tools to create some working workflow for a team.

Scarblac 8y ago

The business wants to know how much feature X is going to cost and when they can expect it. They need to know that, because they need to decide if it's worth it in the first place, or because they need to plan follow-up actions for when the feature will be done. If the developer doesn't make estimates, you're just forcing other people to make their own estimates, that they'll hold you to.

RandallBrown 8y ago
Nobody should make estimates. They're always wrong. Do your best to break tasks up so that all tasks are the same size. Then work on tasks. You'll find a stable average of tasks per amount of time and that will let you forecast how long things will take, how much they'll cost, etc. That's how you figure out when things will be done.
- PaulHoule 8y ago
  That is bull. Some tasks have a high degree of uncertainty. Others don't. Back when I was using a ruby-on-rails style framework (in PHP) I would frequently get 20 hours of work estimated properly down to 15 minutes when it came to adding simple features to a web application. If on the other hand you are trying to figure out the gap between what the documentation says should work and what actually works, that is hard to estimate.
  - carlmr 8y ago
    And nevermind the technical issues. If you need to work with others, that's where estimating gets hard.
- lordCarbonFiber 8y ago
  That act of breaking up and organizing tasks of the same size, that's what estimation is. This feature has these tasks, historically we complete these tasks in this time, so here's a hard minimum for a completion date (which implies cost). Slap on an appropriate fudge factor for dealing with other teams, testing and burn in, and general error bounds as needed. You've described scrum, what you're doing is scrum.

justjash 8y ago

I agree with most of it minus the "Don't make esitmates" part. Without making some sort of estimate things just don't work. I guess maybe it could work assuming you fully control a single product. Everywhere I have worked we need the estimates simply for coordination of all the moving parts.

spamizbad 8y ago
I think by estimates they might mean deadlines. It’s well worth asking, as an engineer several questions like: “How complicated is this? What are all the moving parts? Whose going to need to be involved to get this out the door?” But it’s counter productive sometimes to say “ I think feature X will be completed by Y” and then that estimate turns into a deadline.
eikenberry 8y ago
Maybe you could rephrase it to "Don't make estimates before work is well underway". The main problem with estimates is that they are usually just wild guesses and pretty useless. But once you've got going on something, have had time to think it through and test your ideas, you can usually give at least a very rough estimate at that point.

hrktb 8y ago

> people incorrectly focus on sprint commitments. I think it's often the over approach from the manager/PM side: they will be looking for a methodology to have estimates and team commitment, and Scrum will be an option. There is an awful lot of PMs who will candidly explain that they don't really care about the methodology, they just need stuff to get done and know when.

jgust 8y ago

> Always do the simplest thing. Can you clarify? If you meant "always search for the simplest solution" I agree. If you meant, "always do the easiest tasks" I don't.

chrisweekly 8y ago
Simple != Easy I highly recommend this Rich Hickey talk (transcription): https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
- jgust 8y ago
  Thanks!

LifeLiverTransp 8y ago

Its never the wrong socialism. Maybe actual agile as imagined is incompatible with captialsim and human nature?

jeletonskelly 8y ago
Would you prefer the centralized planning model of waterfall? Of course none of these systems are perfect, but it's been a major step in a better direction for everyone involved.
- JohnFen 8y ago
  > it's been a major step in a better direction for everyone involved. I am not convinced that this is true.
- LifeLiverTransp 8y ago
  What i would prefer, is to take a step back and look at all major interest partys involved, who will deform the development process. If management puts to much pressure on, a good process would give tech and the customer more chances to counter said pressure, to avoid tech debt and badly implemented features. I want a process that reacts to the situation, in favour of the product, in favour of longterm goals - who actively resists people who try to gamble it for whatever reason. Agile is not that.
  - droussel 8y ago
    "Agile" is a set of principles and values as defined in the Manifesto for Agile Software Development. If how you work contrary to those principles, then you simply are not "Agile", no matter if you call it that. "Agile" will never fix bad management, nor will anything else for that matter.
jdauriemma 8y ago
Agile was created to sell software to clients, so I think was intended to be very compatible with capitalism.

hopler 8y ago

"commitments" do not exist in Agile. Agile was created to remove commitments and insert collaboration in it's place. You don't have to make big promises when your client has ongoing clear visibility into your progress.

JohnFen 8y ago
That is technically be true, but I've worked at four shops that have implemented Agile methodologies and it hasn't been true for any of them, nor for most of the engineers I personally know but don't work with. I do personally know one person who works on a team that this is true, but he's the only one. This may be doing Agile wrong, but if something can be so easily done wrong that it's common, I count that as serious flaw in the methodology.
- cromulent 8y ago
  agile is not a methodology though - it's a set of principles. Many so-called "Agile methodologies" put structures in place that prevent agility.
- jdauriemma 8y ago
  I'd push back on calling Agile a methodology. [The Agile Manifesto](http://agilemanifesto.org http://agilemanifesto.org) a set of ideals, that's all. These ideals often run afoul of conventional wisdom in traditional management/business/sales circles, so we end up with a set of procedures masquerading as "Agile" in order to not upset prevailing sensibilities.
  - JohnFen 7y ago
    I did not call Agile a methodology. I referred to "Agile methodologies", as in "methodologies that are intended to adhere to Agile principles".

noxToken 8y ago

>Don't do sprints. Have a continuous backlog. Don't do overtime. Don't make estimates. Always do the simplest thing. Only ever do the most important thing, as defined by the stakeholder. The problem with this is that the stakeholder might not understand what simple means. It happens here all the time. We get "simple" requests for verbiage changes, but after reviewing the story, the verbiage request isn't universal. It only applies to certain offerings, and the stakeholders only want the verbiage the be applied after a certain step in the application. This is still a relatively simple change, but when factoring in all the other "simple" requests that involve complex logic, changing displayed text becomes relatively complex. We do sprints because it's our time box to see how close we are to hitting the mark. A sprint isn't a hard deadline in which the team must kill themselves to get everything finished. It's an arbitrary passage of time for setting goal to keep on track with what is going to be released. If you have something that's releasing two months into the future, it's easy to say that you can still make time although your first two weeks were riddled with unexpected complications and stoppages. A sprint forces us to focus on what should have already been completed to re-prioritize if necessary. And you can't feasibly do that without an estimation. The two biggest problems with estimations are underestimating and treating estimations as promises. It's hard to estimate. So the best course of action is to make stories as small as possible. Probably smaller than someone would consider rational. If not, at least have the stories divided into individual tasks or chunks. Then once you have estimations, treat them as goals rather than deadlines. Use your sprint review as a time to honestly reflect on why the estimation was missed. Then, and this is critical to successfully estimating in the future, use the notes of reflection to make better estimates.

joncp 8y ago
> The problem with this is that the stakeholder might not understand what simple means. It happens here all the time. "Do the simplest thing" means don't overengineer, not necessarily that the feature won't be complex. You only code up what helps fulfill that particular story's definition of "done." As for complex features. when my stakeholder asks for some big complex change it's almost always decomposable into much simpler stories. Maybe those have to be hidden behind feature flags until the whole epic is done, but they're shippable individually. Doing that decomposition up front helps demonstrate the complexity to the stakeholder and takes some pressure off of me. It also makes them feel secure because they have more granular insight into progress; that they're not sending me off on some Lewis & Clark expedition.

potta_coffee 8y ago

"Don't make estimates." Very few managers / CEOs are going to let you get away with this.

jayd16 8y ago

>Don't do overtime. Don't make estimates. Said another way, estimates are not promises. Don't crunch to meet them. I think it should be phrased as "no deadlines". The whole sprint structure is so you're constantly adjusting your plans and estimations at some predictable time. Without a sprint you can end up with randomization.

asark 8y ago
I've noticed some managers and project managers love to emphasize the that sprint plans are "commitments". "OK, is this what we're committing to for this sprint? Is everyone comfortable committing to this?". LOL. OK. Maybe that guilts the young bloods into doing free overtime or something. But no. It's like when car salesmen try to get you to name a number you'd definitely buy the car for and sign it on some not-at-all-binding-or-official piece of paper, like that means something, before they go back and "ask their boss if they can make it work". Psychological trickery bullshit.
- acct1771 8y ago
  You work on a team with members that make you feel like you're buying a car..?
  - asark 8y ago
    It's a very similar psychological trick. I've even heard project managers I like and who I think are generally very good do it. I think it's just part of their language now, and some may not realize they're doing anything kinda shitty. But it's something straight out of Cialdini's Persuasion, and unsubtle enough that even I can tell what it is. "Do you feel comfortable committing to these stories?" Always a question. Committing. If you don't make it for any reason not obviously caused by "outside blockers" you're morally responsible—and maybe even then. What are you, some kind of liar? Quite a step from an estimate. Kind of harsher than a deadline, even, which are oh-so-rarely as "deadly" as the name implies. But people close enough to Scrumish processes to get in the meetings but far enough away not to be writing code or testing things or putting out designs sure seem to like that word. Commit.

diminoten 8y ago

You have to do estimates, it's how a business works. Not knowing when something will be delivered is too much to ask a company to deal with. Also, "always do the simplest thing" is one of those phrases that can be twisted and morphed to support literally anything, which makes the phrase useless. It feels good to hear and say, but the reality is it doesn't help you out of a jam. Sprints are exactly what you're describing, except with accountability built in. That shouldn't scare people, but it does, and that is what causes burnout. Fixing the fear around accountability is how you fix burnout, not eliminating the thing that your boss can use to justify your job.

tootie 8y ago

The number one reason agile projects fail in my experience has absolutely nothing to do with planning session, sprint cadence or estimation. It's because the client was not properly prepared to accept iterative delivery or play their part as product owner. I see a lot of team organize themselves around a well-groomed backlog and set their priorities only to have clients come in and ask for deadlines and fixed scopes and all the other stuff that is anathema to agile. If you client is able to set priorities effectively and allow a slower, quality-driven model then everything else becomes just so much easier.

beat 8y ago
I just read a marvelous book called Handmade, by a fine furniture woodworker, and something he says over and over is "Go slow to go fast". The sales pitch to the business for a well-controlled agile process is that it maximizes productivity. Shifting priorities and poor planning undermine the productivity of the development team.
- gridspy 8y ago
  Yes, this is also worded as "Slow is smooth, smooth is fast" - used for instance when following emergency checklists. It's a good mantra when under serious pressure.
- e12e 8y ago
  "slow is smooth, and smooth is fast" Ed: see also: "practice makes permanent".
- vitro 8y ago
  I remember one movie scene where old sniper teaches young one "To be slow is to be precise, to be precise is to be fast"
wool_gather 8y ago
Ironically, such clients also seem to expect that whatever additions/changes they dream up should be able to be folded in to the plan willy-nilly. Whereas if they accepted an iterative process that would come naturally, without constant re-negotiation or ill will.

uhhhhhhh 8y ago

>Don't do sprints. Have a continuous backlog. Don't do overtime. Don't make estimates. Always do the simplest thing. Only ever do the most important thing, as defined by the stakeholder. you just described doing agile wrong... You're advocating for a version of agile lite, not agile. Or alternative, agile is different to everyone you talk to and your agile isn't the same as someone elses agile. Take your pick, but sprints, estimations, not only doing 1 thing/most important things are basic tenants of agile as most people see it.

andrewprock 8y ago
You are describing Scrum, not Agile. Scrum is a subset of Agile. There are many other Agile methodologies, including what the go outlined.
fwip 8y ago
The only thing consistent about Agile is that everyone is doing it wrong.

EngineerBetter 8y ago

Estimates seem to be a common topic in replies. If you can accurately estimate how long a software task will take, you should have already made a reusable component or automation to generate that code. Estimates are meaningless. I've seen PhDs waste endless hours faffing with estimate-calculating spreadsheets. Fundamentally, the universe is unpredictable. Chaotic and complex systems require their starting conditions to be measured to an infinite level of precision to be predictable. The Heisenberg principle means this is, as far as physics can tell, impossible. On a more practical macro level, a complex adaptive system becomes unpredictable once three feedback loops are present (the three body problem is related). Modern computer systems are unpredictable because we cannot predict the interplay between levels of abstraction. It does not matter how smart you are. Unless you have perfect knowledge of all levels of abstraction in the system below you, even in a macroscopic sense you cannot predict the future. Precise estimates will be inaccurate. Confidence ranges and superprobabilities are of some use. Discrete and precise estimates are an utter waste of time at best, and are dangerous and misleading at worst. EDIT Written on a mobile waiting for plane take-off, hence lack of citations. For more on complex adaptive systems, I recommend the works of Murray Gell-Mann and the research output of the Santa Fe Institute, particularly Scott E. Page.

virtualized 8y ago
Another way to put it: If you know how long something will take in advance, you have a solution in mind. It is unlikely that this solution is (A) the best one and (B) the one you will actually implement. It would be stupid to ignore information you learned along the way. If you could actually predict the future you should invest in the lottery, not in software. EDIT: Of course there are projects where you actually know exactly what to do. Happens a lot in consulting. That has nothing to do with Agile though.
- EngineerBetter 8y ago
  > If you could actually predict the future you should invest in the lottery, not in software. Hear, hear!

mverwijs 8y ago

> The Product Owner prioritises the backlog Note: This would require a _really_ good product owner that does not merely focusses on features, but also on feasibility and 'fitness functions'. The rest of that article had me cheering all the way.