The Church of Agile | Hacker News Reader

The Church of Agile

thechurchofagile.org

22 pointsaninteger36 comments

I think Agile is a response to the reality that in many organizations writing code is a thankless and cynicism-inspiring burden.

Agile tips the balance and puts the technical team in control of process and expectation management in a way that lets everybody feel very good about how much they got done, regardless of whether there is good code being written or successful product/market fit.

It's also possible to justify quite a bit of architecture debt by deferring to agile principles and punting on systems thinking in favor of finishing a few n point stories, rinsing and repeating.

I'd say that if you have a team that is cynical due to changing requirements and technically naive management (or clients/stakeholders) then agile might be a great approach.

Or, if the sort of predictability and transparency offered by agile is of great value to the organization for some other reason.

In general I think that sprint velocity is a vanity metric that has nothing to do with product market fit or system quality.

The "retrospective" meeting is a nice idea, but the presence of a few complainers/gripers on the team can turn this into a morale-draining blamefest.

This is a weird comment. Assuming we're talking about a company of any real size, why is product/market fit the responsibility of engineering?

>regardless of whether there is good code being written or successful product/market fit.

I don't think OP is suggesting that engineering is responsible for product/market fit but rather sprints and burndown charts provide some visibility and satisfaction that work is getting done (regardless of whether the code is clean and regardless of whether it is the work that ought to be getting worked on).

I take the OP to be pointing out the reason that agile gets adopted and it's short comings that get overlooked because it makes people feel good.

Clueless management is clueless. They often feel that nothing gets done without some visible artifact. Agile allows the dev/engineering team to help show the tasks and behind the scenes things that need to be done. Clueless management likes Agile for this visibility. But Agile doesn't necessarily ensure proper product/market fit, especially early on when the first sprints deal with architecture setup foundation code. Clueless management doesn't understand this (and it is managements job to ensure the dev team/engineering team is working on the correct solution).

That sounds like an indictment of clueless management, not of Agile.

Correct. And to that some would say that the latest agile craze and the large number of shops using agile is because of clueless management. It's not the miracle cure some people want it to be.

In my experience Agile is most prevalent where the engineering culture is the weakest. When engineering culture is strong and effective, it's unnecessary. Where engineering is simply the business side's bitch is when you end up with a massive multi-tentacled PMO organization attempting to use their Agile hammer on anything vaguely nail-looking, cheered on by Chief Revenue Officers and Heads of Product who love that they have a direct line to individual engineering teams... Without any of that pesky engineering leadership getting in the way.

I've used Scrum in startups with strong engineering culture, and it helps align engineering and "the business" (sales, marketing, 'what are we building', 'for who'). As an engineer, Scrum helped me expose 'the realities' of software engineering to people who did't get it. For example, the communication helped us change priorities to get value into the product.

Unfortunately, "Agile" is now mainstream bullshit, and, as you say, its now used by the business to just bypass any kind of engineering mastery, and just hire a bunch of junior devs and tell them what to do. "Scrum masters" are just "yes men". Most times, when a company says "We do Agile" they mean "We hired a bunch of script kiddies on a constant death march".

Scrum is about empowering developers, but Scrum itself does not empower them. If the developers are already empowered, then I believe it's useful for communication and direction. If the developers are not already empowered, then Scrum is actively bad. Scrum cannot empower developers. Scrum with disempowered developers is just disempowered developers but now without any kind of SDLC safety net.

I agree with your statements.

But it has nothing to do with Agile or Scrum. It all has to do with company culture. It reminds me of my favorite Henrik Kniberg quote "If your company doesn't like the truth, than maybe Agile isn't for you". Very few companies realize value from script kiddies on a constant death march (great quote BTW) and that prevents no one from trying.

Agreed. In the current form, Agile is management's answer to "I have no idea what we're doing but I need to be seen doing something".

At my workplace they even invented a thing called "Agile Transformation Journey" and hired a bunch of scrum masters who call themselves "Agilists", because the whole org is falling apart on technical debt and clueless managers standing around pointing fingers. A few years into this "journey" and everything is exactly the same. Everyone knows this. The devs know this, the agilists know this, the managers know this but we all pretend to get along because it's an echo chamber. It's almost too fun too watch.

You-Can't-Fix-A-Broken-Culture-With-Agile.

> You-Can't-Fix-A-Broken-Culture-With-Agile.

Agile is just a set of cultural values. If you can't fix a broken culture with it, what is it good for?

You don't fix a broken culture by throwing more "culture values" on it. You fix it from within.

What is it good for? In the current form - nothing. Sounds good, doesn't work.

Correct. That's one of the reasons why I am looking to leave my current job. Ultimately management has no appreciation or understanding of software development so most projects have more managers asking "insightful" questions or asking for status than people doing the work.

You're not alone.

I hear a lot of complaining on HN about Agile development but few proposals for something better. In my experience I have found that Agile is the least-worst development process, broadly speaking. I find it difficult to imagine a productive development environment that does not have at least a significant number of aspects of modern Agile thinking. Could you give some examples of Agile development practices you would replace, and with what?

> Programming in C/C++, Java, Javascript, that's easy, anyone can write code. But having the skill of standing in a circle and saying what you've been working on, what you will be working on, and if you have any blockers, that takes pure talent.

That may be the dumbest thing I read all week.

It's sarcasm

Consider that the writer of the comment to which you replied already knows this, and stands by what they wrote.

This is a website written in PHP by someone who doesn't like how their scrum team is being run.

I'm going to assume that based on the tone of this site, the author is a very junior developer -- mostly because I think a mid-to-senior software engineer would be brutally embarrassed to publish and share something like this with a wider audience.

Everything there is to be said about agile has been said. Good teams adopt the right take on the process for them. Teams with poor cohesion, who would likely struggle with or without project management, may have some cookie-cutter version of the process forced on them. This is usually a sign of a dysfunctional team -- not necessarily a dysfunctional process.

The author may actually be the bad apple derailing a process that works for the team as a whole. Look at all the complaints! Assuming it's actually a team of seven, you're talking about one seventh of the team probably visibly seething at every standup because they feel put upon by someone forcing a process on them. I imagine that's a lot of tension for the other six people to bear.

Look, I've written plenty of things I'm embarrassed by -- particularly in the beginning of my career. Blog posts and the like are a great way to let off some steam about how unsatisfied you are with your job. But if you're anything like me, you're going to look back at stuff like this and regret how bad your attitude was.

My advice straight to the author: You probably spent more time writing this site than the amount of time you've actually lost to your daily standup. If you're not happy with your job, then quit it.

But I've got to warn you: odds are you're not going to be running the show at the next job either. I can tell from this site that you're just really mad that people are telling you what to do. Answering to someone else is a part of literally any job. It's a pretty fundamental part of participating in society.

You're going to end up being just as miserable wherever you land if you don't take a look in the mirror and invest some time into improving your attitude and focusing on positive, productive interactions with your co-workers.

Since it sounds like you very much favor agile, I'm curious about your take on the following questions:

- What adaptations to classic agile have you seen successful teams make that you think were very smart decisions?

- What sort of project is agile best for? worst for?

- How can agile help to find product-market fit? Or is it completely separate from that?

- What sort of alternative project management approach do you think has failed so often that Agile became necessary as a fundamental rethink of the old way?

I really hesitate to say I'm in favor of agile. It's just a flexible tool for getting things done which prioritizes team empowerment and short feedback loops over top-down command-and-control project management.

Some good adaptations I've seen are largely around handling distributed collaboration, and favoring out-of-band communication practices over regular interruptions. For many teams benefit from replacing a daily standup with a status email. A good compromise is also a daily status email with standups every other day. Having a mid-sprint status meeting and a regular standup time in slack is also a good compromise.

I think engineers in particular get caught up on the rituals they're asked to attend because they view it as invasive. The rituals are just part of it, but in my opinion, the end goal is to provide regular feedback loops for measuring progress and actively communicating. This way, teams can react to changes and blockers before they prevent a group from delivering on its commitments.

Agile is good for teams that are matrixed and highly empowered. If there are strong dependencies on external teams, then it's hard to get out of the proverbial waterfall.

I don't think agile is appropriate for handling questions around product-market fit, but it does help a team to iterate on a product in measured paces in response to the product / sales cycle.

In terms of an alternative project management approach, I think maybe the question needs to be framed differently. Other approaches don't need to fail; agile just needs to be different in a useful way. Agile has a focus on self-organization and measuring progress in short intervals. It suits the increasingly distributed and technological ways in which groups perform work, specifically because it's up to the team to implement the process in a way that works for them.

The real problem with agile (even well-done agile) is the interface with non-agile upper management. Sooner or later you usually run into someone who wants to see your detailed project development plan and timeline, or some such. Answering "Why would we need one of those? We just talk to each other" does not go well, even if it's true that you actually don't need one of those because you've addressed the problems the document is supposed to address simply by regular informal communication. (Been there, done that.)

If upper management doesn't "get" agile, at some layer you have to transition to non-agile. There's an impedance mismatch at that layer. If someone doesn't actively translate things into upper-management terms, they can decide to kill the project, simply because they can't tell what's going on.

This is why middle management exists -- to insulate working groups from hard-and-fast commitments and timelines. They do this by using their professional experience and understanding of the capability of their teams to know what overall product to promise under what kind of timeline.

I don't know about many companies with 50 or more people where the CEO "does agile" personally, for instance.

Everything there is to be said about agile has been said.

Really? haha

When most people say Agile they mean Scrum. Scrum great up around the culture of web consulting. That makes it a good way to do web consulting, an alright way to do web development, and a pretty bad way to do anything else.

I wonder if any of these Agile haters ever had the pleasure of working with RUP (Rational Unified Process) and endless UML diagrams.

Agile was a response to that trend, cutting the BS and recommending teams would focus more on software quality and collaboration and less on worthless processes. It was a cultural shift more than anything else, and a very welcome one.

Sure, lots of people tried to "sell Agile" by pushing sticky notes everywhere and replacing "Project Manager" with "Scrum Master", as if these changes alone would solve all their problems. This does not mean that Agile itself was a bad idea, it only means that anything that goes mainstream is bound to be misunderstood and misused by a lot of people.

"Agile" should have stopped at the Agile Manifesto. Everything else just made it worse.

Whenever a movement takes root, an ecosystem jumps up that attempts to productize and commoditize it. We're seeing the same thing with DevOps, which is being sold as CICD, ignoring the cultural bits that make CICD effective (in fact, if you do the cultural bits, you'll probably end up recognizing the need for CICD at some point, regardless of whether you included it initially).

Peeling back the layers, a lot of these philosophies include principles that have been found in high-performing organizations for decades:

1. Transparency

2. Seeking input from all levels of the org chart

3. Involving stakeholders early and often

4. Constructing incentives around desired metrics

5. Fast feedback

6. Rapid iteration

7. Reproducible processes

8. Constant, systemized reassessment

That last one is where "Agile" has lost its meaning: Hiring certified ScrumMasters® doesn't make you agile. Scrum and the like can be useful frameworks, but if you don't absorb the above principles into the core of your organization (including outside of the IS department!), you'll end up with AgileScrumFall at best.

The same happened with OOP and design patterns. It will happen with FP too. As soon as something works and is useful, "gurus" and consultants appear who make it digestible to mediocre devs and upper management but in reality they are just caricatures of the original intent.

IT always entertains me that Agile companies tend to be so focused on process, and yet the agile manifesto specifically de-emphasizes process.

Agile is almost always a process. It doesn't focus on improving the people and interactions. That's unfortunate.

I think the flat hierarchy in the Scrum religion is an oversight. When designing a religion, what you generally want is a sense of accomplishment as you climb the ladder towards alumni status, with knowledge revealed in rituals such as commercial lectures and materials along the way. This is what gives people a sense of achievement, keeps people stick to a religion, and makes a decision to drop out increasingly hard. L. Ron Hubbard did know about this aspect of human nature all too well.

Is the term SCRUM trademarked? Asking because I'm still seeing a business opportunity here for selling "official" SCRUM master certificates. Believe it or not (and reflecting on non-engineer's desire for status symbols of even the most absurd kind), there are people who, when asked what their profession is, will without irony answer "scrum master".

That business idea already exists...

https://www.scrumalliance.org/certifications

My company implemented SAFe. You might have competition with those guys!

> Thou shalt spread the word about Agile to everyone I know.

Probably shouldn't be "I". Only posting this on the off-chance that the author reads HN comments.

He forgot the mumble talker in his list of people that come to the Daily Stand Up.

A nice desecration, as I hoped it would be. The bit about git hit the spot.

Reply on news.ycombinator.com