It's time to break free from Corporate Agile

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.

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.

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.

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.

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.

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.

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.

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!

Also see the recent post & comments: "The "3 standup questions" are terrible and need to die"

https://news.ycombinator.com/item?id=39317107

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.

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

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

Time to call SAfE what it really is: waterfall.

agile is a cancer just like cloud.