7 ms·

It's time to break free from Corporate Agile

91 points by pcloadletter_ 3y ago

santoshalper 3y ago
Practically speaking, Corporate Agile is Agile in that it is what 95%+ of people doing Agile are actually experiencing. As far as I can tell, the only companies doing "manifesto" Agile are startups, mostly out of necessity or out of a preference for agility (which is necessary for a startup) over predictability (which is impossible for a startup). Large companies mostly fail to do Agile not because they are incapable (well, maybe some), but because they don't want to - they value predictability over agility. If you're about to reply that your Product/Engineering team is totally doing "real" Agile inside a traditional corporate operation, save your energy lol. Now here is my hot take: Any organization that can reasonably hope to achieve predictability will strongly prefer it to agility and always choose it. This is why Agile never works in established corporations. No matter how much they talk a good game about "disruption", the reality is that they are just hoping to get predictable results.
- tootie 3y ago
  I've seen a lot of agile shops and in my experience most of them have the right idea and relatively few are really abusing it. The friction with any project, agile or not, almost always boils down to estimation. "When will my product be done?" That's a really hard notion to disabuse regardless of process. No methodology has successfully solved for predicting the future.
  - santoshalper 3y ago
    And none ever will, but organizations will keep chasing that brass ring.
  - convolvatron 3y ago
    of course not. but if you don't follow corporate agile, then you're allowed to make estimates beyond a single sprint. are these prophetic? only in the sense of being self fulfilling. we can do is have a rough map of the work and eyeball our progress given the team we have, and try to line that up with the endpoint by working backwards. this should give us some general feeling about risk. we have lots of ways to repond to perceived risk of failure - - pull in a more experienced person to get a read and possibly help with that part - shuffle the order of development to try to swallow some of the uglier pieces early - talk with product (possibly yourselves wearing different hats), about whether we can meaningfully throw some work off the bus without hollowing out the release - thin out some features and actually probably several more. what corporate agile says is 'this is all too hard, screw that, lets not try to account for individual strengths, and the nature of the development process, and the sensitivity of the markets towards particular features. everybody pick something to work on for the next two weeks...and if that didn't work. well, we tried our best'
- TheCleric 3y ago
  You’re 100% right. In every case where I’ve been a part of agile, you have someone at the top that’s wanting predictability. If I told them to pick between 5 guaranteed features and 10 features but they don’t have control over the timing, they’d pick the former every time (well they’d try to pick 10 guaranteed, but ultimately they’d rather have predictability than velocity).
- opportune 3y ago
  Even a startup cannot do manifesto-agile most of the time IMO, at least not if they have a strong desire to succeed, because they are constrained by the possibility of running out of money in the near-future. I am dabbling with bootstrapping now that I've hit my financial-independence targets and I think this, along with profitable+small+private+engineering-led software businesses and FOSS, are some of the only environments in which you can engage in true Agile. That assertion stems from the fact that they are not subject to real constraints in budget and resilient to business meddling in things like TTM and MVP.
  - mrkeen 3y ago
    Is there anything you can't substitute into "Even a startup cannot do X most of the time IMO, at least not if they have a strong desire to succeed, because they are constrained by the possibility of running out of money in the near-future." ?
    - opportune 3y ago
      Not exactly sure what you mean, but most startups operate at losses for a long time before becoming profitable. I explicitly noted that bootstrapped startups with passive income and profitable small engineering-led companies are not constrained by this problem, because their financials support operating indefinitely - but perhaps I misunderstand your point
rqtwteye 3y ago
Large corporations are basically run like planned economies in communist states. 5 year plans, leadership detached from reality on the ground, tons of internal propaganda, lots of pretending that things are great, empire building by the mid levels and so on. There may be pockets of "true" agile here and there but I believe a large corporation simply can't be run in "true" agile manner. They are way too controlling to really empower their workers.
- santoshalper 3y ago
  Communism is essentially corporatism for nation states.
  - dwd 3y ago
    No, that's fascism; Read Mussolini's manifesto. Fascism is basically Communism (as practiced); corporations own the means of production rather than the government, and it uses religion/nationalism rather than humanism/atheism. They are the same in kind, but different in degree. You could even say China under Deng Xiaoping and later Xi blended the two. Agile is many ways does smack of Communism: - It proposes egalitarianism (skin in the game), but generally leads to micromanagement/totalitarian situations. - If it fails it's because you didn't do the "real" Agile. - If adherents often speak/act in cultist/religious ways.
    - santoshalper 3y ago
      That's fair, I think I was making the mistake that so many others have - mistaking Sovietism with Communism.
      - dwd 3y ago
        Which is similar to people confusing Agile with agile. There's a perverse Newspeak aspect to the way agile is implemented as Agile. Need to go back to core values like: "Individuals and interactions over processes and tools."
- 3y ago
rebeccaskinner 3y ago
Agile is a tainted term. For it's proponents, it's become nothing more than a vacuous manifestation of the No True Scottsman fallacy. Anything that works is True Agile, and anything that doesn't is Not True Agile (or would be True Agile if you weren't holding it wrong). The principles that underlie Agile are either entirely self-evident and can't be claimed as a particular benefit of Agile per-se, or they are hopelessly naive about the way people, and companies, actually work. Agile itself has no real original ideas, and offers nothing of value. At this point, the best thing we can do is let Agile, all of it, die.
- randomdata 3y ago
  > Agile itself has no real original ideas Core to the 12 Principles, and thus Agile by extension, is the idea of no managers. Each of the 12 items exists to get you thinking about what developers (and the business people!) need to do if there is no manager acting as the guiding force. While no managers is not a novel idea in a vacuum, it isn't something organizations usually think about. It's just the unspoken expectation that there will be managers once you have enough people to form a team. > hopelessly naive about the way people, and companies, actually work. Indeed. One of the 12 principles is quite explicit that it will not work with any Random Joe; that you need very specific people who are motivated to make an organization function without management helping them. Much as you want to pretend you are not Random Joe, you are, and it literally tells you that it won't work for you.
  - nradov 3y ago
    The original agile manifesto is silent on the topic of management. Self-organizing teams are a good practice, but once you scale up and have to coordinate the work of many teams across a huge portfolio it generally becomes necessary to have some level of hierarchical management in order to prevent chaos and dysfunction. https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html
  - eesmith 3y ago
    I don't see how that "no managers" core can be true. Many of the principles, like "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." are valid even for solo developer projects. Agile came out of older practices, like Rapid Development, which definitely could be used by solo developers. Several of the principles do imply the existence of multiple people - #4 implies business people are distinct from developers - but still apply to a two-person company, like married friends I knew who ran their own software company where the wife handled the business and the husband the development and there was no manager. If there are no managers, then either everything they do is Agile (because there are no managers) or nothing they do is Agile (because "Agile" can't be applied). If the former, then a solo developer following waterfall is Agile. If the latter then what alternative principles can be applied to solo- and partnership developer projects?
CartyBoston 3y ago
In the startup world and in much of the tech corporate world in practice predictability is valued above all else. It's because investors, perhaps reasonably, value and therefore demand predictions. But as we know that is fundamentally difficult. So many tech orgs make up a "hero-hustle" culture to compensate. "We're top 10% and we work all the time, this is the best we can do!" Strong leadership is strong leadership, building the right product development culture is really hard.
- ramijames 3y ago
  I agree with this. Visibility and accountability shouldn't trump creativity and innovation. Good leadership doesn't allow that to happen. Bad agile is just bad leadership in practice.
- from-nibly 3y ago
  The hero hustle hides all the bad stuff which will then never get fixed. Predictability is a fantasy. It's predicting the future. No one can do it. When you hear someone say they've figured out a way to get predictability they are lying, in much the same way people who say they've come up with a new guaranteed way to make money off the stock market are lying.
  - nradov 3y ago
    Predictability depends primarily on the time scale, plus a few other factors. I have seen existence proofs of mature, disciplined organizations using stable technology consistently hitting >90% of commitments over periods of up to 3 months. Over longer periods or when more research is needed then predictability will necessarily be lower. While perfect predictability is impossible, many organizations have lower predictability than they could. This usually comes down to lack of discipline, which is a fixable problem (much easier than beating the stock market). Insisting on high levels of discipline eliminates the need for "hero hustle".
tamimio 3y ago
As a certified project manager myself, huge portion of all these practices are just pure none sense and sometimes are used only to feed the managers ego and burn the employees more while producing nothing but a garbage product. They see it done in an XY big corp and they start mimicking it blindly believing that in few years they will become mulit-billion dollars company, and I always say it, just because some approach worked in an environment with these people and that product, it does NOT mean it will work for you, it’s a tool, it fits that work it doesn’t mean it will fit yours, but holy crap how ignorant some people are when they just apply work without thinking, it is far dangerous than not knowing, the former one will think they know it all!
- Terretta 3y ago
  The problem with certified project management practices no matter the name is the lack of certified outcome owners.
leetrout 3y ago
Also see the recent post & comments: "The "3 standup questions" are terrible and need to die" https://news.ycombinator.com/item?id=39317107 https://news.ycombinator.com/item?id=39317107
teddyh 3y ago
The idea of “Basic Agile” is not new; there’s, for instance, “Clean Agile” from 2019.
heads 3y ago
I feel like there are metric lurking in here somewhere. Something to do with the following concepts: (1) the number of documented atomic changes to the codebase, be these merges or pull-requests or changesets or patches — the thing with a title and description that was code reviewed; (2) the number of tasks in your task management system that might be bugs or feature requests — these are large and must be implemented in pieces, with testing and reviewing of assumptions along the way; and (3) the time period on which you are required to be held accountable for actually finishing stuff. I do maybe 30 commits for a big task and will spend six weeks on it. There might be small bugs along the way that get closed out with a 1:1 mapping between task and commit. The majority of the work is a giant slowly but surely moving set of iterations towards a top level goal. The cadence is to review on a quarterly basis. Not so in the past though. I’ve had to do one commit per task. Multiple tasks in a big bushy tree of verbiage that overlaps too much with the actual commits (the meaningful bits!) and all done on two week cycles. It felt exhausting and piecemeal, as if software engineers were a fungible resource there to further marketing goals instead of innovate the next big things. Nowadays I demand to work for a true technology company, not a marketing company that sells tech.
- nradov 3y ago
  It's nice to have your labor in high enough demand that you can pick and choose which types of companies to work for. Most developers worldwide don't have that luxury.
  - NotSuspicious 3y ago
    Exactly. It's so interesting seeing the unstated assumptions software engineers let slip out. It really reveals the bubble they live in.
freitzkriesler2 3y ago
Time to call SAfE what it really is: waterfall.
- arcbyte 3y ago
  I never understand the SAFe hate.
- marginalia_nu 3y ago
  I think that is unfair to waterfall, which in practice tends to work pretty well.
- bartimus 3y ago
  And project management. They basically turned the PO role into a PM role.
bitwize 3y ago
Does whatever you propose to replace corporate Agile give upper management fine-grained observability and control of the SDLC? No? Then it won't get adopted, especially not by large organizations. Period. It's not the 80s or 90s anymore, programmers don't get to build little fiefdoms of accountability strictly on their own terms anymore. The C suite knows that those fiefdoms are Dennis Nedry situations just waiting to happen. Software development is accountable to the business. The business has a right to track how much value developers are delivering, and to change things if it's not enough.
LuciBb 3y ago
[flagged]
sirspacey 3y ago
I appreciate the spirit this is written in. Having fought the good fight, here’s what I’ve learned: Leadership in most organizations have ideas about product but no idea what the actual product is that runs things. Anything that a client or stakeholder wants is an automatic “P1.” The senior dev team inevitably concludes that tech debt, which has been accumulated for years, has to be address due to near catastrophic levels of issues in security, compliance, performance, or maintenance. Business analysts & PMs, almost always bright, well-intentioned people that don’t realize they are in Kafka-topia, believe that all that is missing is a clear business justification for prioritization & with calculated value to the end user. Those that go hunting for answers are soon shocked to discover their core users have no idea why they do what they do or what relevance it has to the org. All of the above drives additional, well-research product enhancements that get greenlit by leadership to be done “alongside the client P1s.” If your pipeline is clogged, shipping value can’t happen. However little time it takes, it still takes time to change the way you work - which is what agile is about at its best: continual learning and improvement. I learned a valuable lesson in game design - your constraints are your rules engine. As much as the concepts and beliefs at the core of agile are an amazing “dev outward” approach to value creation, agile does not and cannot stand alone in the global dysfunction of human organizations. Without clear leadership on priorities, without clear budgeting of investment in infrastructure, and most importantly without an actual feedback loop across all the players in a system, agile is not agile. Agile is a way to get there, yes, but if you are in an organization that can’t answer basic questions about itself then you are probably in an organization that won’t be able to implement anything authentically. You will just have new shapes and sizes on the same lack of alignment, decision making, and insight.
- BandButcher 3y ago
  Well said
moribvndvs 3y ago
I recently left a long-established, mid-sized company that has been stuck in a miserable mire of Scrum that stands as an ironic antithesis to the manifesto the countless (and exorbitantly expensive) agile evangelists we’ve had slink through our doors exhort yet fail repeatedly to achieve. The new company has no formal agile process, but effectively is kanban. I gotta say, it’s glorious. Leadership gives us a clear and actionable goal, we self organize the work, and we approach it in a way where we can iteratively build and release things every few days to maybe a week or two and get it in front of stakeholders for feedback, adjust as necessary, repeat until it’s done. If something urgent comes up, stakeholders are apprised, we handle it, and we return as soon as we can. We have a little bit of documentation to help with the bus factor and onboarding. No bullshit, no scrum master or coach, no planning poker, no fucking stand ups or parking lots or sprint planning or retrospectives or scrum-of-scrum or refinement or the dozens of other meetings that took 1/3 to 1/2 of my time at the old place. We can afford to do this because we’re a small, focused company where everyone knows their role, we get the fuck out of each other’s way but we hold each other accountable, and the pulse of the org is built around this lifecycle. As the business gets larger, it will stress this nice and cozy arrangement and I imagine we may have to add some light process to keep it from spilling apart, but I’m really hoping this ground up culture of getting things done can scale. That’s the thing of it. scrum arose out of people trying to boil down and extract the magic of very successful teams so we can duplicate it everywhere, but in the process of trying to make it a machine you just install and turn on, it has turned a photocopy of a photocopy of a photocopy of a Frankenstein monster where various leadership members-who may unfortunately not be as smart or effective as the folks they emulate-pick the parts they like and push it down onto their reports, whether it works organically or not. Worse than that, it gets applied piecemeal across the organization rather than the organization being built around it. And of course they change it unilaterally and don’t coordinate across teams. I think you either have it or you don’t. If you’re waterfall and can’t do anything but waterfall, just do waterfall and don’t make everyone miserable by wasting their time trying to pretend something you're not. If your org isn’t effective, sure, give it a shot, but it’s going to take an organization-wide, focused effort to make agile work. At any rate, I can’t understand or justify the amount of money and time we throw at snake oil salesmen and charlatans in the scrum/project management space.
- 3y ago
pjmlp 3y ago
Good luck with that, when corporate agile directly depends on job roles and consulting agencies built around it.
cranberryturkey 3y ago
agile is a cancer just like cloud.
Vinaas 3y ago
[dead]
Vinaas 3y ago
[dead]
Sofiaaz 3y ago
[dead]

91 points by pcloadletter_ 3y ago

Practically speaking, Corporate Agile is Agile in that it is what 95%+ of people doing Agile are actually experiencing. As far as I can tell, the only companies doing "manifesto" Agile are startups, mostly out of necessity or out of a preference for agility (which is necessary for a startup) over predictability (which is impossible for a startup). Large companies mostly fail to do Agile not because they are incapable (well, maybe some), but because they don't want to - they value predictability over agility. If you're about to reply that your Product/Engineering team is totally doing "real" Agile inside a traditional corporate operation, save your energy lol. Now here is my hot take: Any organization that can reasonably hope to achieve predictability will strongly prefer it to agility and always choose it. This is why Agile never works in established corporations. No matter how much they talk a good game about "disruption", the reality is that they are just hoping to get predictable results.

tootie 3y ago
I've seen a lot of agile shops and in my experience most of them have the right idea and relatively few are really abusing it. The friction with any project, agile or not, almost always boils down to estimation. "When will my product be done?" That's a really hard notion to disabuse regardless of process. No methodology has successfully solved for predicting the future.
- santoshalper 3y ago
  And none ever will, but organizations will keep chasing that brass ring.
- convolvatron 3y ago
  of course not. but if you don't follow corporate agile, then you're allowed to make estimates beyond a single sprint. are these prophetic? only in the sense of being self fulfilling. we can do is have a rough map of the work and eyeball our progress given the team we have, and try to line that up with the endpoint by working backwards. this should give us some general feeling about risk. we have lots of ways to repond to perceived risk of failure - - pull in a more experienced person to get a read and possibly help with that part - shuffle the order of development to try to swallow some of the uglier pieces early - talk with product (possibly yourselves wearing different hats), about whether we can meaningfully throw some work off the bus without hollowing out the release - thin out some features and actually probably several more. what corporate agile says is 'this is all too hard, screw that, lets not try to account for individual strengths, and the nature of the development process, and the sensitivity of the markets towards particular features. everybody pick something to work on for the next two weeks...and if that didn't work. well, we tried our best'
TheCleric 3y ago
You’re 100% right. In every case where I’ve been a part of agile, you have someone at the top that’s wanting predictability. If I told them to pick between 5 guaranteed features and 10 features but they don’t have control over the timing, they’d pick the former every time (well they’d try to pick 10 guaranteed, but ultimately they’d rather have predictability than velocity).
opportune 3y ago
Even a startup cannot do manifesto-agile most of the time IMO, at least not if they have a strong desire to succeed, because they are constrained by the possibility of running out of money in the near-future. I am dabbling with bootstrapping now that I've hit my financial-independence targets and I think this, along with profitable+small+private+engineering-led software businesses and FOSS, are some of the only environments in which you can engage in true Agile. That assertion stems from the fact that they are not subject to real constraints in budget and resilient to business meddling in things like TTM and MVP.
- mrkeen 3y ago
  Is there anything you can't substitute into "Even a startup cannot do X most of the time IMO, at least not if they have a strong desire to succeed, because they are constrained by the possibility of running out of money in the near-future." ?
  - opportune 3y ago
    Not exactly sure what you mean, but most startups operate at losses for a long time before becoming profitable. I explicitly noted that bootstrapped startups with passive income and profitable small engineering-led companies are not constrained by this problem, because their financials support operating indefinitely - but perhaps I misunderstand your point

rqtwteye 3y ago

Large corporations are basically run like planned economies in communist states. 5 year plans, leadership detached from reality on the ground, tons of internal propaganda, lots of pretending that things are great, empire building by the mid levels and so on. There may be pockets of "true" agile here and there but I believe a large corporation simply can't be run in "true" agile manner. They are way too controlling to really empower their workers.

santoshalper 3y ago
Communism is essentially corporatism for nation states.
- dwd 3y ago
  No, that's fascism; Read Mussolini's manifesto. Fascism is basically Communism (as practiced); corporations own the means of production rather than the government, and it uses religion/nationalism rather than humanism/atheism. They are the same in kind, but different in degree. You could even say China under Deng Xiaoping and later Xi blended the two. Agile is many ways does smack of Communism: - It proposes egalitarianism (skin in the game), but generally leads to micromanagement/totalitarian situations. - If it fails it's because you didn't do the "real" Agile. - If adherents often speak/act in cultist/religious ways.
  - santoshalper 3y ago
    That's fair, I think I was making the mistake that so many others have - mistaking Sovietism with Communism.
    - dwd 3y ago
      Which is similar to people confusing Agile with agile. There's a perverse Newspeak aspect to the way agile is implemented as Agile. Need to go back to core values like: "Individuals and interactions over processes and tools."
3y ago

rebeccaskinner 3y ago

Agile is a tainted term. For it's proponents, it's become nothing more than a vacuous manifestation of the No True Scottsman fallacy. Anything that works is True Agile, and anything that doesn't is Not True Agile (or would be True Agile if you weren't holding it wrong). The principles that underlie Agile are either entirely self-evident and can't be claimed as a particular benefit of Agile per-se, or they are hopelessly naive about the way people, and companies, actually work. Agile itself has no real original ideas, and offers nothing of value. At this point, the best thing we can do is let Agile, all of it, die.

randomdata 3y ago
> Agile itself has no real original ideas Core to the 12 Principles, and thus Agile by extension, is the idea of no managers. Each of the 12 items exists to get you thinking about what developers (and the business people!) need to do if there is no manager acting as the guiding force. While no managers is not a novel idea in a vacuum, it isn't something organizations usually think about. It's just the unspoken expectation that there will be managers once you have enough people to form a team. > hopelessly naive about the way people, and companies, actually work. Indeed. One of the 12 principles is quite explicit that it will not work with any Random Joe; that you need very specific people who are motivated to make an organization function without management helping them. Much as you want to pretend you are not Random Joe, you are, and it literally tells you that it won't work for you.
- nradov 3y ago
  The original agile manifesto is silent on the topic of management. Self-organizing teams are a good practice, but once you scale up and have to coordinate the work of many teams across a huge portfolio it generally becomes necessary to have some level of hierarchical management in order to prevent chaos and dysfunction. https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html
- eesmith 3y ago
  I don't see how that "no managers" core can be true. Many of the principles, like "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." are valid even for solo developer projects. Agile came out of older practices, like Rapid Development, which definitely could be used by solo developers. Several of the principles do imply the existence of multiple people - #4 implies business people are distinct from developers - but still apply to a two-person company, like married friends I knew who ran their own software company where the wife handled the business and the husband the development and there was no manager. If there are no managers, then either everything they do is Agile (because there are no managers) or nothing they do is Agile (because "Agile" can't be applied). If the former, then a solo developer following waterfall is Agile. If the latter then what alternative principles can be applied to solo- and partnership developer projects?

CartyBoston 3y ago

In the startup world and in much of the tech corporate world in practice predictability is valued above all else. It's because investors, perhaps reasonably, value and therefore demand predictions. But as we know that is fundamentally difficult. So many tech orgs make up a "hero-hustle" culture to compensate. "We're top 10% and we work all the time, this is the best we can do!" Strong leadership is strong leadership, building the right product development culture is really hard.

ramijames 3y ago
I agree with this. Visibility and accountability shouldn't trump creativity and innovation. Good leadership doesn't allow that to happen. Bad agile is just bad leadership in practice.
from-nibly 3y ago
The hero hustle hides all the bad stuff which will then never get fixed. Predictability is a fantasy. It's predicting the future. No one can do it. When you hear someone say they've figured out a way to get predictability they are lying, in much the same way people who say they've come up with a new guaranteed way to make money off the stock market are lying.
- nradov 3y ago
  Predictability depends primarily on the time scale, plus a few other factors. I have seen existence proofs of mature, disciplined organizations using stable technology consistently hitting >90% of commitments over periods of up to 3 months. Over longer periods or when more research is needed then predictability will necessarily be lower. While perfect predictability is impossible, many organizations have lower predictability than they could. This usually comes down to lack of discipline, which is a fixable problem (much easier than beating the stock market). Insisting on high levels of discipline eliminates the need for "hero hustle".

tamimio 3y ago

As a certified project manager myself, huge portion of all these practices are just pure none sense and sometimes are used only to feed the managers ego and burn the employees more while producing nothing but a garbage product. They see it done in an XY big corp and they start mimicking it blindly believing that in few years they will become mulit-billion dollars company, and I always say it, just because some approach worked in an environment with these people and that product, it does NOT mean it will work for you, it’s a tool, it fits that work it doesn’t mean it will fit yours, but holy crap how ignorant some people are when they just apply work without thinking, it is far dangerous than not knowing, the former one will think they know it all!

Terretta 3y ago
The problem with certified project management practices no matter the name is the lack of certified outcome owners.

leetrout 3y ago

Also see the recent post & comments: "The "3 standup questions" are terrible and need to die" https://news.ycombinator.com/item?id=39317107 https://news.ycombinator.com/item?id=39317107

teddyh 3y ago

The idea of “Basic Agile” is not new; there’s, for instance, “Clean Agile” from 2019.

heads 3y ago

I feel like there are metric lurking in here somewhere. Something to do with the following concepts: (1) the number of documented atomic changes to the codebase, be these merges or pull-requests or changesets or patches — the thing with a title and description that was code reviewed; (2) the number of tasks in your task management system that might be bugs or feature requests — these are large and must be implemented in pieces, with testing and reviewing of assumptions along the way; and (3) the time period on which you are required to be held accountable for actually finishing stuff. I do maybe 30 commits for a big task and will spend six weeks on it. There might be small bugs along the way that get closed out with a 1:1 mapping between task and commit. The majority of the work is a giant slowly but surely moving set of iterations towards a top level goal. The cadence is to review on a quarterly basis. Not so in the past though. I’ve had to do one commit per task. Multiple tasks in a big bushy tree of verbiage that overlaps too much with the actual commits (the meaningful bits!) and all done on two week cycles. It felt exhausting and piecemeal, as if software engineers were a fungible resource there to further marketing goals instead of innovate the next big things. Nowadays I demand to work for a true technology company, not a marketing company that sells tech.

nradov 3y ago
It's nice to have your labor in high enough demand that you can pick and choose which types of companies to work for. Most developers worldwide don't have that luxury.
- NotSuspicious 3y ago
  Exactly. It's so interesting seeing the unstated assumptions software engineers let slip out. It really reveals the bubble they live in.

freitzkriesler2 3y ago

Time to call SAfE what it really is: waterfall.

arcbyte 3y ago
I never understand the SAFe hate.
marginalia_nu 3y ago
I think that is unfair to waterfall, which in practice tends to work pretty well.
bartimus 3y ago
And project management. They basically turned the PO role into a PM role.

bitwize 3y ago

Does whatever you propose to replace corporate Agile give upper management fine-grained observability and control of the SDLC? No? Then it won't get adopted, especially not by large organizations. Period. It's not the 80s or 90s anymore, programmers don't get to build little fiefdoms of accountability strictly on their own terms anymore. The C suite knows that those fiefdoms are Dennis Nedry situations just waiting to happen. Software development is accountable to the business. The business has a right to track how much value developers are delivering, and to change things if it's not enough.

LuciBb 3y ago

[flagged]

sirspacey 3y ago

I appreciate the spirit this is written in. Having fought the good fight, here’s what I’ve learned: Leadership in most organizations have ideas about product but no idea what the actual product is that runs things. Anything that a client or stakeholder wants is an automatic “P1.” The senior dev team inevitably concludes that tech debt, which has been accumulated for years, has to be address due to near catastrophic levels of issues in security, compliance, performance, or maintenance. Business analysts & PMs, almost always bright, well-intentioned people that don’t realize they are in Kafka-topia, believe that all that is missing is a clear business justification for prioritization & with calculated value to the end user. Those that go hunting for answers are soon shocked to discover their core users have no idea why they do what they do or what relevance it has to the org. All of the above drives additional, well-research product enhancements that get greenlit by leadership to be done “alongside the client P1s.” If your pipeline is clogged, shipping value can’t happen. However little time it takes, it still takes time to change the way you work - which is what agile is about at its best: continual learning and improvement. I learned a valuable lesson in game design - your constraints are your rules engine. As much as the concepts and beliefs at the core of agile are an amazing “dev outward” approach to value creation, agile does not and cannot stand alone in the global dysfunction of human organizations. Without clear leadership on priorities, without clear budgeting of investment in infrastructure, and most importantly without an actual feedback loop across all the players in a system, agile is not agile. Agile is a way to get there, yes, but if you are in an organization that can’t answer basic questions about itself then you are probably in an organization that won’t be able to implement anything authentically. You will just have new shapes and sizes on the same lack of alignment, decision making, and insight.

BandButcher 3y ago
Well said

moribvndvs 3y ago

I recently left a long-established, mid-sized company that has been stuck in a miserable mire of Scrum that stands as an ironic antithesis to the manifesto the countless (and exorbitantly expensive) agile evangelists we’ve had slink through our doors exhort yet fail repeatedly to achieve. The new company has no formal agile process, but effectively is kanban. I gotta say, it’s glorious. Leadership gives us a clear and actionable goal, we self organize the work, and we approach it in a way where we can iteratively build and release things every few days to maybe a week or two and get it in front of stakeholders for feedback, adjust as necessary, repeat until it’s done. If something urgent comes up, stakeholders are apprised, we handle it, and we return as soon as we can. We have a little bit of documentation to help with the bus factor and onboarding. No bullshit, no scrum master or coach, no planning poker, no fucking stand ups or parking lots or sprint planning or retrospectives or scrum-of-scrum or refinement or the dozens of other meetings that took 1/3 to 1/2 of my time at the old place. We can afford to do this because we’re a small, focused company where everyone knows their role, we get the fuck out of each other’s way but we hold each other accountable, and the pulse of the org is built around this lifecycle. As the business gets larger, it will stress this nice and cozy arrangement and I imagine we may have to add some light process to keep it from spilling apart, but I’m really hoping this ground up culture of getting things done can scale. That’s the thing of it. scrum arose out of people trying to boil down and extract the magic of very successful teams so we can duplicate it everywhere, but in the process of trying to make it a machine you just install and turn on, it has turned a photocopy of a photocopy of a photocopy of a Frankenstein monster where various leadership members-who may unfortunately not be as smart or effective as the folks they emulate-pick the parts they like and push it down onto their reports, whether it works organically or not. Worse than that, it gets applied piecemeal across the organization rather than the organization being built around it. And of course they change it unilaterally and don’t coordinate across teams. I think you either have it or you don’t. If you’re waterfall and can’t do anything but waterfall, just do waterfall and don’t make everyone miserable by wasting their time trying to pretend something you're not. If your org isn’t effective, sure, give it a shot, but it’s going to take an organization-wide, focused effort to make agile work. At any rate, I can’t understand or justify the amount of money and time we throw at snake oil salesmen and charlatans in the scrum/project management space.

3y ago

pjmlp 3y ago

Good luck with that, when corporate agile directly depends on job roles and consulting agencies built around it.

cranberryturkey 3y ago

agile is a cancer just like cloud.

Vinaas 3y ago

[dead]

Vinaas 3y ago

[dead]

Sofiaaz 3y ago

[dead]