8 ms·

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 an

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

l_camacho84 7y ago
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.
notus 7y ago
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
- jdmoreira 7y ago
  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
  - notus 7y ago
    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.
    - jdmoreira 7y ago
      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
bamboozled 7y ago
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.
collyw 7y ago
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.
- jdmoreira 7y ago
  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!
  - AnimalMuppet 7y ago
    > 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.
  - wan23 7y ago
    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 https://agilemanifesto.org/principles.html ) every once in a while and consider whether their process is actually working for the team.
  - JohnFen 7y ago
    If that's the case, then I've been doing agile for decades before agile was a thing! So I guess waterfall is agile...
  - 7y ago
jjtheblunt 7y ago
I suspect that your second line, "No estimates. No sprints. No Jira. No bullshit!", is why "help one another" works.
jczhang 7y ago
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?
- mpfundstein 7y ago
  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
ljw1001 7y ago
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.

l_camacho84 7y ago

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.

notus 7y ago

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

jdmoreira 7y ago
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
- notus 7y ago
  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.
  - jdmoreira 7y ago
    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

bamboozled 7y ago

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.

collyw 7y ago

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.

jdmoreira 7y ago
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!
- AnimalMuppet 7y ago
  > 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.
- wan23 7y ago
  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 https://agilemanifesto.org/principles.html ) every once in a while and consider whether their process is actually working for the team.
- JohnFen 7y ago
  If that's the case, then I've been doing agile for decades before agile was a thing! So I guess waterfall is agile...
- 7y ago

jjtheblunt 7y ago

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

jczhang 7y ago

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?

mpfundstein 7y ago
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

ljw1001 7y ago

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.