Hacker News Reader

Comment by jdmoreira | Hacker News Reader

It works pretty well for me but that’s because we refuse to engage in bullshit.

No estimates. No sprints. No Jira. No bullshit!

What we do? Retro, grooming and planning. Standup everyday in front of a Kanban board with post-its. And we help each other. That’s it!

Seriously, how hard can it be? Building software is not the same as a Ford model T assembly line

View on HN

As usual no one can agree what agile actually is. Is what you are doing agile? Some would say no. Some would say yes.

Someone will likely says agile is a lot of shit and someone will reply saying "you are doing it wrong" without giving any indication of how to do it right.

again here is my opinion... The minimum requirement for doing agile IMHO is to have retros and to iterate the process all the time until it works. That’s it.

But what agile is or is not is just semantics. It’s irrelevant I think. Who cares if we all follow the same set of rules? People selling certifications that's who!

> and to iterate the process all the time until it works.

YES! If you aren't able to hack the process, then you aren't agile. Any rule-book driven "agile" isn't agile.

The problem is, to do agile, you need managers that don't have to have a rule book to follow. Those are rare. If you don't have them, then you get somebody's rigid "agile process", but not much actual agility.

Same! Whenever I have to explain what agile is I start with retrospectives. It's the one rule that is mandatory. Standups, sprints, JIRA boards, grooming/refinement sessions and everything else in a heavyweight framework like scrum is there to support the principles of agile, but none of it is actually necessary. IMO every software developer should read the Agile Manifesto ( https://agilemanifesto.org/principles.html ) every once in a while and consider whether their process is actually working for the team.

If that's the case, then I've been doing agile for decades before agile was a thing! So I guess waterfall is agile...

Agreements with gates. Usually short term.. iterate and improve.

This is because the naive mental model of development processes is bullshit: the techniques introduced and used should never be some rigid dogma. This applies to "agile" or whatever flavor-of-the-year we're talking about.

Agile is best thought of as an ecosystem of tools used to shape software (and knowledge) work. Am I "doing it wrong" when I get out my toolbox, use the #2 Philips head screwdriver, but not the torque wrench? NO! Not if I didn't need the torque wrench!

And that's a massive source of pain with "agile", or what I think of as "kitchen sink agile" where the goal becomes, explicit or not, to apply as many processes from as many books as possible – instead of picking just the right ones.

I've literally never been on two teams with the same process needs in my entire (now long) career. Even those teams year-over-year evolve their needs as the members, organization, and business change. Why should the process therefore be a static entity? One of the very few fixed rules I've learned hits to the GP's theme: it's critical to have the least necessary process, just as it's ridiculous to break out every tool in the box just to tighten up a loose screw.

Much like communism, agile is only agile while it is working well.

I suspect that your second line, "No estimates. No sprints. No Jira. No bullshit!", is why "help one another" works.

Yes for me this is also the case. The WIP on the Kanban is very important. Is not a question of deadlines, is more a question of doing as little as possible at the same time.

the massive popularity of "agile" otoh, is based to a large extent on the fact that it turns engineers into automatons and offers management unprecedented visibility into their work.

As an IT exec if sprints and work broken into 2 hour deliverables makes sense.

Then ask them if they tell their boss every day what they're going to do for the next 24 hours in two hour increments.

Same approach also adopted here, except we don’t bother with daily stand-ups just on demand “regroups” once we finish tasks or someone requests help. We also don’t write a whole lot down, rather we just learn and internalise lessons as we go. We just define and evolve some key team ethos.

Limiting work in progress is the game changer for me.

I can see how this could work, however do you think one would feel similarly confident in hitting quarterly goals / OKRs without such estimation/sprints?

Why would you want to work at a place that does such bs in the first place? Do that with your mba buddies and define okrs or whatnot but please let us just build awesome stuff. Thats my okr at least. Dont need some manager breathing down my neck that the estimate was wrong

what happens if a post it falls off the board or someone steals one? Also how do you write acceptance criteria on a post it

if a post falls of a board and no one notices. did it really fell?

Acceptance criteria? That’s BS! We are all adults where I work

I don't think it is a maturity thing. It's a you have customers and business requirements to satisfy and if certain criteria are not met than the feature is kind of useless. I work at an org with around 5000 people and there is no way any engineer could know all of the business requirements for an application, there is just too much to know.

Well... I will try to put it in a different light. A cross functional product team must have all the knowledge to complete the tasks they are given. There is no way agile is going to work for you if there are 5000 people with a saying on your day to day tasks.

If there are a few stakeholders outside the team it's really the PO's job to represent them. If you need to know if the task is complete you ask the PO and she should made the call. It’s simple really

Reply on news.ycombinator.com