5 ms·

Three Ways Agile Has Gone Astray

17 points by aard 8y ago

mlthoughts2018 8y ago
I am not a fan of the general commoditized one-size-fits-all management approach that goes by the modern term "Agile" (putting aside all the no-true-Scotsman debates about what 'real' Agile is for now...) Usually I read articles like this feeling like the author missed the point, and that it's just some rehashing of the many different ways modern Agile gets it so wrong. But this article actually impressed me a lot. I agree very much that the one of the biggest problems with Agile is the notion of fixed-length "sprints". Even the basic language of 'sprinting' is a problem, which begets bad culture and a misunderstanding of different speeds and priorities for different teams and different paradigms of work, like the difference between people answering PagerDuty alerts and people researching a new statistical model ... Those two groups absolutely don't work the same way or at the same cadence or with the same need for planning, and there are a million other teams and work types that differ too. It seems reasonable to use bookkeeping tools like Trello or JIRA, but the horizon of work should be customizeable and should be adaptive to specific personnel, teams, workflows, situations, times of the year, etc. If the interface artificially requires choosing one cadence length, then just make sure the company knows to ignore it and assign no meaning to it. Then let teams break things up however they choose. The other huge one, which the author mentions, is wasting time on useless group estimation. This one is a gigantic mess and fraught with problems: - It can become politicized among the team, seen as a chance to lobby for whose work is more valuable, or even in the worst cases to try to directly attack someone else on the team by making it look like their workload is always lighter. - It sparks a ton of bikeshedding. People will argue about whether something is "a 1" or "a 2" in some totally meaningless Fibonacci units, like OMG who cares! You'd be better off just assigning it, starting some work, and asking for updates. You'll know when something creates a surprise blocker or involves way more work than expected. - Managers always claim that they just want velocity numbers for ballpark understanding to aggregate up to higher level managers, but it's not true. They really want to cherry-pick statistics and charts from that nonsense to sell other managers on stories about progress, road maps, etc. So you basically turn your expensive software developers into Mechanical Turkers who are manually punching in meaningless Fibonacci numbers for no other reason that giving middle management the opportunity to datamine juvenile Excel charts. In the end, none of it corresponds to deadlines, workloads, etc. - Agile support staff, like Scrum masters and coaches and shit, always have their own take on it that superficially sounds like it's more humane and focused on holistic workflow health, but really is just double-speak for capitulating to the stuff management wants. For example, I had an Agile coach once who swore that all our troubles with time getting wasted on story points estimation could be solved if we created "gold standard" example stories, like a canonical 1-pointer, canonical 3-pointer, etc., and just used these during our planning meeting. I could see the painful sincerity in his expression, and I couldn't help but think, "this guy doesn't know anything about software engineering at all ... he just wants us to think positively about what management is making him make us do." On the third point that the author made, about group code ownership, I think the problem ties back in with the estimation problems. For example, the author writes, > "Rightfully, everyone should have read access, but things go wrong when everyone has write permissions..." It's not so much that literal write privileges are the problem. Rather it's about fluffy policies like, "everyone's opinion should could equally towards code review" or the idea that everyone has equal say in the chosen architecture, design idea, etc. It sounds nice and democratic, but in practice it's just more surface area for bikeshedding and time wasting. I find it's a lot better to explicitly take into account who has expertise in which topics when weighting whose opinion to use. Letting people act as mini-dictators regarding a certain implementation, or have creative control over an API design, is often a lot better than trying to get consensus on everything. Besides, the bigger picture is that you want to use code review and testing to make nice iteration loops over your code and your choices anyway. So if someone has creative control and gets an API done quickly, you can do code review and let someone else iterate on some refactoring during the next cycle, or later when there is time. Over time, the code begins to reflect a compromise among the design preferences of the team, but in a way that always maintains testability and gets checked through acceptance tests and CI. Compared with a design project that flames out before it even starts because you have multiple competing design doc proposals and bitter arguments about whether to use OOP or functional programming or this library or that library ... Most of the time just assign it to someone with skills in that area and move on. No story points, no two-week implied deadline or progress check in, no feeding of meaningless Fibonacci numbers to middle management, no speaking about the creative process of software design with language like "sprinting." No time wasting with useless group discussion for assigning story points. No time wasting with bikeshedding and stylistic debates about how to solve a problem or start a design solution. Just use common sense, and then during the rare times when your team actually flags something up for group debate about a design idea, you'll be more confident that it has a good signal-to-noise ratio, and your team's work won't be judged by arbitrary Fibonacci numbers.
- commandlinefan 8y ago
  The problem with agile methodologies, or any other software methodology, is that they can't solve the problem that the managers pushing them want solved: predict, with near certainty, how long it will take to create a non-trivial bit of software. The old XP that modern "agile" grew out of explicitly reminded adopters that this was, by definition, impossible, but that reality was cast aside when it was found to be too inconvenient. So we have legions of people pretending something that is demonstrably untrue is true.
  - vannevar 8y ago
    The old XP that modern "agile" grew out of explicitly reminded adopters that this was, by definition, impossible, but that reality was cast aside when it was found to be too inconvenient. It may have been cast aside by somebody, but not by agile practitioners. The reason that many managers still oppose agile is precisely because it explicitly rejects the predictability that the traditional waterfall promised.
- rdiddly 8y ago
  Thanks for the thoughts...
- vannevar 8y ago
  Some of this is valid, but most is badly off-base. A lot of people confuse the sprint cadence with the natural functional milestones that emerge in any software project. Nothing in agile requires you to finish a feature in one sprint; it only requires that you have demonstrable functionality. Developers always chunk their work into comprehensible pieces, and those pieces are almost always less than two weeks work, for the practical reason that a project much bigger than that is pretty difficult for an individual developer to hold in his or her head. The worst case scenario is that some kind of interim demonstrable milestone has to be found in a chunk that is projected to take longer than a sprint, but in practice that's almost never very hard to do for an experienced developer. We routinely divvy up functionality, it's part of the professional skillset. You seem pretty hung up on the story point thing. I've never experienced that much of an issue with it. In practice, the team does give greater weight to the opinions of people with special expertise. And no team I've ever been on has spent much time arguing about 1 or 2-point stories. The advantage of group pointing comes when you talk to the outliers; often someone in the group will think of an aspect that no one else did, and group pointing brings that out. Regarding the motivation of managers, maybe everyone is out to get you, but probably not. Most managers really just want to know the team's velocity, so they can project the likelihood of making future (very real) deadlines. They're not taking your sprint stats and showing them off in some secret manager's society.
ianamartin 8y ago
This article isn't bad, but it misses the number 1 problem with Agile: Businesses are not agile. Some software teams might start out that way. Some start-ups may be nothing but the software team in the beginning, with a CEO in name in order to attract funding. But all businesses are waterfall organizations. The moment a business signs its first meaningful contract (money will be exchanged, on this date, for some product that does x), the company is waterfall. The "best" (read: most agile) scenario is when the product team bends over backwards to completely isolate the dev team from the rest of the business and maintains the illusion that the dev team is operating in an agile manner while dealing with the rest of the business in business (read: waterfall terms). But the layers of abstraction in this scenario are too thick and too leaky. There's no reason to maintain this fiction, and I submit that it's also extremely unproductive and inefficient to do so. Every software engineer not at an early stage software startup is working at a waterfall company. We should stop pretending otherwise and come to grips with that reality and put more effort into coming up with better ways of dealing with that.
OnlyRepliesToBS 8y ago
It's a cult imposed by top down to give powers to the managers above the developers at the expense of developers. "Look at all the paperclips I'm moving" > "Thinking ahead"

17 points by aard 8y ago

mlthoughts2018 8y ago

I am not a fan of the general commoditized one-size-fits-all management approach that goes by the modern term "Agile" (putting aside all the no-true-Scotsman debates about what 'real' Agile is for now...) Usually I read articles like this feeling like the author missed the point, and that it's just some rehashing of the many different ways modern Agile gets it so wrong. But this article actually impressed me a lot. I agree very much that the one of the biggest problems with Agile is the notion of fixed-length "sprints". Even the basic language of 'sprinting' is a problem, which begets bad culture and a misunderstanding of different speeds and priorities for different teams and different paradigms of work, like the difference between people answering PagerDuty alerts and people researching a new statistical model ... Those two groups absolutely don't work the same way or at the same cadence or with the same need for planning, and there are a million other teams and work types that differ too. It seems reasonable to use bookkeeping tools like Trello or JIRA, but the horizon of work should be customizeable and should be adaptive to specific personnel, teams, workflows, situations, times of the year, etc. If the interface artificially requires choosing one cadence length, then just make sure the company knows to ignore it and assign no meaning to it. Then let teams break things up however they choose. The other huge one, which the author mentions, is wasting time on useless group estimation. This one is a gigantic mess and fraught with problems: - It can become politicized among the team, seen as a chance to lobby for whose work is more valuable, or even in the worst cases to try to directly attack someone else on the team by making it look like their workload is always lighter. - It sparks a ton of bikeshedding. People will argue about whether something is "a 1" or "a 2" in some totally meaningless Fibonacci units, like OMG who cares! You'd be better off just assigning it, starting some work, and asking for updates. You'll know when something creates a surprise blocker or involves way more work than expected. - Managers always claim that they just want velocity numbers for ballpark understanding to aggregate up to higher level managers, but it's not true. They really want to cherry-pick statistics and charts from that nonsense to sell other managers on stories about progress, road maps, etc. So you basically turn your expensive software developers into Mechanical Turkers who are manually punching in meaningless Fibonacci numbers for no other reason that giving middle management the opportunity to datamine juvenile Excel charts. In the end, none of it corresponds to deadlines, workloads, etc. - Agile support staff, like Scrum masters and coaches and shit, always have their own take on it that superficially sounds like it's more humane and focused on holistic workflow health, but really is just double-speak for capitulating to the stuff management wants. For example, I had an Agile coach once who swore that all our troubles with time getting wasted on story points estimation could be solved if we created "gold standard" example stories, like a canonical 1-pointer, canonical 3-pointer, etc., and just used these during our planning meeting. I could see the painful sincerity in his expression, and I couldn't help but think, "this guy doesn't know anything about software engineering at all ... he just wants us to think positively about what management is making him make us do." On the third point that the author made, about group code ownership, I think the problem ties back in with the estimation problems. For example, the author writes, > "Rightfully, everyone should have read access, but things go wrong when everyone has write permissions..." It's not so much that literal write privileges are the problem. Rather it's about fluffy policies like, "everyone's opinion should could equally towards code review" or the idea that everyone has equal say in the chosen architecture, design idea, etc. It sounds nice and democratic, but in practice it's just more surface area for bikeshedding and time wasting. I find it's a lot better to explicitly take into account who has expertise in which topics when weighting whose opinion to use. Letting people act as mini-dictators regarding a certain implementation, or have creative control over an API design, is often a lot better than trying to get consensus on everything. Besides, the bigger picture is that you want to use code review and testing to make nice iteration loops over your code and your choices anyway. So if someone has creative control and gets an API done quickly, you can do code review and let someone else iterate on some refactoring during the next cycle, or later when there is time. Over time, the code begins to reflect a compromise among the design preferences of the team, but in a way that always maintains testability and gets checked through acceptance tests and CI. Compared with a design project that flames out before it even starts because you have multiple competing design doc proposals and bitter arguments about whether to use OOP or functional programming or this library or that library ... Most of the time just assign it to someone with skills in that area and move on. No story points, no two-week implied deadline or progress check in, no feeding of meaningless Fibonacci numbers to middle management, no speaking about the creative process of software design with language like "sprinting." No time wasting with useless group discussion for assigning story points. No time wasting with bikeshedding and stylistic debates about how to solve a problem or start a design solution. Just use common sense, and then during the rare times when your team actually flags something up for group debate about a design idea, you'll be more confident that it has a good signal-to-noise ratio, and your team's work won't be judged by arbitrary Fibonacci numbers.

commandlinefan 8y ago
The problem with agile methodologies, or any other software methodology, is that they can't solve the problem that the managers pushing them want solved: predict, with near certainty, how long it will take to create a non-trivial bit of software. The old XP that modern "agile" grew out of explicitly reminded adopters that this was, by definition, impossible, but that reality was cast aside when it was found to be too inconvenient. So we have legions of people pretending something that is demonstrably untrue is true.
- vannevar 8y ago
  The old XP that modern "agile" grew out of explicitly reminded adopters that this was, by definition, impossible, but that reality was cast aside when it was found to be too inconvenient. It may have been cast aside by somebody, but not by agile practitioners. The reason that many managers still oppose agile is precisely because it explicitly rejects the predictability that the traditional waterfall promised.
rdiddly 8y ago
Thanks for the thoughts...
vannevar 8y ago
Some of this is valid, but most is badly off-base. A lot of people confuse the sprint cadence with the natural functional milestones that emerge in any software project. Nothing in agile requires you to finish a feature in one sprint; it only requires that you have demonstrable functionality. Developers always chunk their work into comprehensible pieces, and those pieces are almost always less than two weeks work, for the practical reason that a project much bigger than that is pretty difficult for an individual developer to hold in his or her head. The worst case scenario is that some kind of interim demonstrable milestone has to be found in a chunk that is projected to take longer than a sprint, but in practice that's almost never very hard to do for an experienced developer. We routinely divvy up functionality, it's part of the professional skillset. You seem pretty hung up on the story point thing. I've never experienced that much of an issue with it. In practice, the team does give greater weight to the opinions of people with special expertise. And no team I've ever been on has spent much time arguing about 1 or 2-point stories. The advantage of group pointing comes when you talk to the outliers; often someone in the group will think of an aspect that no one else did, and group pointing brings that out. Regarding the motivation of managers, maybe everyone is out to get you, but probably not. Most managers really just want to know the team's velocity, so they can project the likelihood of making future (very real) deadlines. They're not taking your sprint stats and showing them off in some secret manager's society.

ianamartin 8y ago

This article isn't bad, but it misses the number 1 problem with Agile: Businesses are not agile. Some software teams might start out that way. Some start-ups may be nothing but the software team in the beginning, with a CEO in name in order to attract funding. But all businesses are waterfall organizations. The moment a business signs its first meaningful contract (money will be exchanged, on this date, for some product that does x), the company is waterfall. The "best" (read: most agile) scenario is when the product team bends over backwards to completely isolate the dev team from the rest of the business and maintains the illusion that the dev team is operating in an agile manner while dealing with the rest of the business in business (read: waterfall terms). But the layers of abstraction in this scenario are too thick and too leaky. There's no reason to maintain this fiction, and I submit that it's also extremely unproductive and inefficient to do so. Every software engineer not at an early stage software startup is working at a waterfall company. We should stop pretending otherwise and come to grips with that reality and put more effort into coming up with better ways of dealing with that.

OnlyRepliesToBS 8y ago

It's a cult imposed by top down to give powers to the managers above the developers at the expense of developers. "Look at all the paperclips I'm moving" > "Thinking ahead"