Live data from Hacker News

Manifesto for Async Software Development

asyncmanifesto.org

31–40 of 62 posts

Re: Manifesto for Async Software Development

#31

> Product owners can replace planning meetings by simply filing issues in the issue tracker, assigning priority, assigning them to people, and setting a release milestone. People will know what to work on by simply working on whatever the highest priority issue is in their queue. This goes against approximately everything I've learned about process in the last 10 years. In fact, I think there's literally nothing corr…

I've worked on teams that do precisely this and, and it's worked remarkably well - sometimes. It varies a lot by team; some combinations of people just absolutely fly with this process, they're happy and extremely productive, while others flounder around unsure of what to do. Some of my observations from it that hopefully answer some of your concerns: 1.) This only works when you have a team full of self-motivated en…

There is, just out of reach, a dream of unifying methodology and effectiveness and decent life outside of work - Agile that demands collocation starts to hurt teams that want people with families in central London.

I can almost reach the goal.

Re: Manifesto for Async Software Development

#32

Earlier quoted context omitted.

It seems the opposite to me. There's nothing stopping you from continually improving processes under the async model. On the other hand, Scrum retrospectives are token at best because they assume the premises of Scrum. You can't adopt any reforms unless those reforms fit into the narrowly-tailored practices of Scrum. As such, any reforms that involve replacing the daily standup meeting, the sprint planning meeting, o…

> You can't adopt any reforms unless those reforms fit into the narrowly-tailored practices of Scrum. I don't think Scrum is nearly that dogmatic in its posture or that inflexible in its prescriptions, but even if I'm wrong, maybe you should consider adopting Scrum-but-without-the-rigidity-you-think-it-has. Of course you can do as you please; you don't need a new capitalized term to make that true.

Anecdotally, whenever I try to suggest Scrum-but-without-the-rigidity, I just get dogmatic "that's not Scrum" responses.

Re: Manifesto for Async Software Development

#34
post #6

First of all, both agile manifesto and this new one annoy me, mostly because the statements are far too open ended and vague to be of use. I like them because they're clever, but when employed by someone who takes everything literally they are at best a pain and lead to all the crap out there they try to label as agile/scrum. Anyways, for anyone trying to grok this: Agile: 1) Individuals and interactions over process…

... Manifesto for Async Software Development ...

Although they could have simplified to down to one rule by saying "We value working the way we want to over the way you want us to".

One of those successfully trolled and truly believing is going to reinvent Fred Brooks using javascript and claim he's been drastically improved as a result.

Re: Manifesto for Async Software Development

#35

This misses on the most important part of agile/scrum/lean... retrospectives. To understand lean, you have to understand its roots in operations management and lean production methods at Toyota and other companies. The whole purpose is not predictable planning, it's continuous process improvement. It's the process of improving your process. If you were doing agile or async right, you would start with a process or man…

So here is my Manifesto of Eventually Awesome Development of Anything:

1. Write down a process (Waterfall, Agile, Cowboy, whatever)

2. Regularly reconsider and improve the process

Re: Manifesto for Async Software Development

#37

> Product owners can replace planning meetings by simply filing issues in the issue tracker, assigning priority, assigning them to people, and setting a release milestone. People will know what to work on by simply working on whatever the highest priority issue is in their queue. This goes against approximately everything I've learned about process in the last 10 years. In fact, I think there's literally nothing corr…

> this manifesto seems built around the idea of minimizing communication

Of course, because communication is expensive (as in time wasted, brainpower wasted, decreased focusing-ability etc.). But I think they get it wrong with meetings: A few time boxed stand-up meetings are great instead of "full-time IM-ing" for distributed teams or "anytime possible interruptions for collocation ones.

I think the OP dreams of an "interrupt-less" work-mode, as opposed to the "interrupt-driven" ones most of us have now. In this view, rigorously time-boxing communication would serve the purpose better than avoiding all meetings.

Re: Manifesto for Async Software Development

#38
post #6

First of all, both agile manifesto and this new one annoy me, mostly because the statements are far too open ended and vague to be of use. I like them because they're clever, but when employed by someone who takes everything literally they are at best a pain and lead to all the crap out there they try to label as agile/scrum. Anyways, for anyone trying to grok this: Agile: 1) Individuals and interactions over process…

... Manifesto for Async Software Development ... Although they could have simplified to down to one rule by saying "We value working the way we want to over the way you want us to". One of those successfully trolled and truly believing is going to reinvent Fred Brooks using javascript and claim he's been drastically improved as a result.

Sure it was a troll? and not just reference to the design style parody of the original? (ie the 1990s design)

Re: Manifesto for Async Software Development

#39
post #38

Earlier quoted context omitted.

... Manifesto for Async Software Development ... Although they could have simplified to down to one rule by saying "We value working the way we want to over the way you want us to". One of those successfully trolled and truly believing is going to reinvent Fred Brooks using javascript and claim he's been drastically improved as a result.

Sure it was a troll? and not just reference to the design style parody of the original? (ie the 1990s design)

They haven't publicly put names to it and the domain is WhoisGuard Protected, so I guess so? Either that, or their trolling level is so artful they're even self-decepting.
Post reply on HN