Manifesto for Async Software Development(asyncmanifesto.org)
asyncmanifesto.org
Manifesto for Async Software Development
http://asyncmanifesto.org/
61 comments
Exactly, and when you ask people who "have done Scrum and it was terrible!" if they raised their problems with the process in a retrospective and if so, what happened, that's usually what identifies the issue. Seems like a lot of people don't take retrospective seriously, or don't speak up during one, or their organisation completely ignore the outcomes of it.
And as you say, they've missed the biggest point - consider your process, and iteratively improve it.
And as you say, they've missed the biggest point - consider your process, and iteratively improve it.
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
1. Write down a process (Waterfall, Agile, Cowboy, whatever)
2. Regularly reconsider and improve the process
[deleted]
That's exactly right. The only thing you ever know for sure is you can always improve the process.
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, or changing anything about how Scrum works at all are not open to discussion. How is that "Agile?"
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, or changing anything about how Scrum works at all are not open to discussion. How is that "Agile?"
> As such, any reforms that involve replacing the daily standup meeting, the sprint planning meeting, or changing anything about how Scrum works at all are not open to discussion. How is that "Agile?"
Its not. Scrum is a collection of practices (many of which may have been developed through an Agile-like attitude wherever they originated) dictated, adopted, packaged, and sold as exactly the kind of processes-over-people-and-interactions manner against which the Agile Manifesto is a reaction.
Almost all of the individual practices of Scrum are good ideas to consider (whether or not they should be applied is organization-specific) in Agile/Lean organizations, but Scrum, qua Scrum, is not Agile.
Its not. Scrum is a collection of practices (many of which may have been developed through an Agile-like attitude wherever they originated) dictated, adopted, packaged, and sold as exactly the kind of processes-over-people-and-interactions manner against which the Agile Manifesto is a reaction.
Almost all of the individual practices of Scrum are good ideas to consider (whether or not they should be applied is organization-specific) in Agile/Lean organizations, but Scrum, qua Scrum, is not Agile.
> 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.
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.
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 processes and tools
2) Working software over comprehensive documentation
3) Customer collaboration over contract negotiation
4) Responding to change over following a plan
Async:
a) Modern tools and flexible work environments over meetings and office hours
b) Flexibility in prioritization over detailed planning
c) Comprehensive documentation over tribal knowledge
Whats changed:
(a), and (1) are at complete odds.
(b) is (4) restated
(c) is some kind of patch of (2)
(3) isn't mentioned.
Also if you're wondering about the crappy design, I'm guessing its a pisstake of the original http://agilemanifesto.org/
Anyways, for anyone trying to grok this:
Agile:
1) Individuals and interactions over processes and tools
2) Working software over comprehensive documentation
3) Customer collaboration over contract negotiation
4) Responding to change over following a plan
Async:
a) Modern tools and flexible work environments over meetings and office hours
b) Flexibility in prioritization over detailed planning
c) Comprehensive documentation over tribal knowledge
Whats changed:
(a), and (1) are at complete odds.
(b) is (4) restated
(c) is some kind of patch of (2)
(3) isn't mentioned.
Also if you're wondering about the crappy design, I'm guessing its a pisstake of the original http://agilemanifesto.org/
...
</head>
<body>
<main>
<section class='agileParody'>
<header>
<h1>Manifesto for Async Software Development</h1>
...
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.
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.
I noticed lacking names, and the whois. My first guess was guerilla marketing by gitlab.
> 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.
The Agile Manifsto isn't supposed to be "of use" in the sense of a canned methodology, its supposed to be a starting point for thinking about what works for you rather than adopting canned methodologies. So, that's as designed.
(The Async Manifesto doesn't really seem vague -- it dictates specific practices as well as general principles. So I think its unfair to ding it for vagueness, and better to ding it for the specific practices being generally ill-conceived.)
The Agile Manifsto isn't supposed to be "of use" in the sense of a canned methodology, its supposed to be a starting point for thinking about what works for you rather than adopting canned methodologies. So, that's as designed.
(The Async Manifesto doesn't really seem vague -- it dictates specific practices as well as general principles. So I think its unfair to ding it for vagueness, and better to ding it for the specific practices being generally ill-conceived.)
"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."
I hate useless meetings as much as the next developer, but there are certain issues that can be much more efficiently resolved if you have all the parties sitting around the same table (or video conference, for remote workers). Especially if you're working on a complex product where it's not immediately obvious how something should be designed or implemented.
For the record, I'm not a fan of daily stand-up meetings. Most of the stuff I work on is complex enough that there isn't that much measurable progress to report after one day. Day to day status can be posted in an issue tracking system. My theory is that the daily meetings were designed to instill an artificial "sense of urgency" in workers.
I hate useless meetings as much as the next developer, but there are certain issues that can be much more efficiently resolved if you have all the parties sitting around the same table (or video conference, for remote workers). Especially if you're working on a complex product where it's not immediately obvious how something should be designed or implemented.
For the record, I'm not a fan of daily stand-up meetings. Most of the stuff I work on is complex enough that there isn't that much measurable progress to report after one day. Day to day status can be posted in an issue tracking system. My theory is that the daily meetings were designed to instill an artificial "sense of urgency" in workers.
Daily meetings are a starting point to get people accustomed to progress meetings. The idea is to get an idea of what else is going on within the project and finding out when and where people need help early.
As a team adapts their process, the frequency of the meetings is likely to drop. After working in a few different environments with frequencies varying from daily to almost never, it feels like the less often you have meetings, the more urgent they become and the more likely they are to be both necessary and useless at the same time.
As a team adapts their process, the frequency of the meetings is likely to drop. After working in a few different environments with frequencies varying from daily to almost never, it feels like the less often you have meetings, the more urgent they become and the more likely they are to be both necessary and useless at the same time.
"Call a meeting only when all other channels of communication aren't suitable for a specific issue."
The page addresses "necessary meetings" further down.
The page addresses "necessary meetings" further down.
Seems more like a manifesto for Autistic Software Development.
Take scrum, cut out everything that involves direct human interaction and replace it with tools and documents.
God forbid us developers should waste time communicating with other human beings. Who needs the bandwidth of face-to-face interaction when you can just do a pull request?
Take scrum, cut out everything that involves direct human interaction and replace it with tools and documents.
God forbid us developers should waste time communicating with other human beings. Who needs the bandwidth of face-to-face interaction when you can just do a pull request?
Cut everything that requires direct human interaction, because synchronous human interaction does not scale. Getting 4 people meet at a time convenient to each is hard enough in one office. Try doing that when people are in Moscow, Tokyo, and LA respectively: there's no convenient time at all. (I'm speaking from personal experience.)
If your problem is best solved with a direct talk, using the full bandwidth of a face-to-face interaction, go on and hold a proper meeting. But such problems are relatively few.
And yes, one should not waste time communicating with other human beings, both oneself's time and others' time. If something can be done without breaking the flow of your fellow developers, it should be done so.
The time freed by the improved efficiency can then be spent enjoying interaction with others.
If your problem is best solved with a direct talk, using the full bandwidth of a face-to-face interaction, go on and hold a proper meeting. But such problems are relatively few.
And yes, one should not waste time communicating with other human beings, both oneself's time and others' time. If something can be done without breaking the flow of your fellow developers, it should be done so.
The time freed by the improved efficiency can then be spent enjoying interaction with others.
"Take scrum, cut out everything that involves direct human interaction and replace it with tools and documents."
Do you really want to know what the developer three rows down is working on every day?
The next shift in management will likely include group calisthenics followed by corporate dormitories.
Do you really want to know what the developer three rows down is working on every day?
The next shift in management will likely include group calisthenics followed by corporate dormitories.
Do you really want to know what the developer three rows down is working on every day?
Unequivocally yes.
Unequivocally yes.
Interesting, I've been working with my teams like this for years, never had a name for it though. But it makes sense for my context of very tiny teams of all remote people, I can see where losing the scrums could cause issues with larger organizations
> 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 correct in that whole paragraph. It's a perfect caricature of precisely what I think doesn't work.
* Priorities are complicated. What if a high-priority item is going to take a really long time, compared to other items? Maybe the "product owners" would want it earlier. They won't know until you tell them. What if the ticket is actually technically impossible? Establishing priorities requires discussion.
* Related: how can you possibly have the product owners establish the milestones without figuring out what it's going to take to accomplish? Sometimes milestones have external drivers for functionality or deadline, and sometimes they're just checkpoints. But either way, it would be crazy to assume they're fixed relative to how long or hard their constituent items are. There are probably a million ways to construct a milestone, but I can't think of one that would be useful without a discussion with the developers.
* What's the correct granularity for a ticket? How would the product owner know how to break that down into specific work items? You need to own your own work queue.
* What the hell is a product owner, anyway? I understand there are various stakeholders and people whose job it is to play proxy for those stakeholders, and perhaps you have even formalized a PM role for managing all that. But invariably one of the stakeholders is you. That's partially because you're involved and presumably have applicable experience building products, but also because as the developer you care about aspects like infrastructure quality, and you need to represent that in the discussion of priorities. In my experience, everything works better with developers involved in the "what are we building?" process, not just getting work thrown over the wall to them.
* Why does the product owner, whoever they are, get to assign who works on what? What if I don't want to work on that item, or have a good reason why it should be assigned to someone else?
* How could this level of detachment from the why of the product ever make you happy?
More generally, this manifesto seems built around the idea of minimizing communication. That's a really bad idea. Building things is complicated and you need to have a process that's willing to face that, not bury its head in the sand and tell everyone to just create and assign tickets. Look, I don't disagree that meetings are painful and I'm always the jerk who wants a crisp, actionable agenda and gets pissy when things drag on. But replacing real planning with "just assign me stuff to do" is crazy talk.
This goes against approximately everything I've learned about process in the last 10 years. In fact, I think there's literally nothing correct in that whole paragraph. It's a perfect caricature of precisely what I think doesn't work.
* Priorities are complicated. What if a high-priority item is going to take a really long time, compared to other items? Maybe the "product owners" would want it earlier. They won't know until you tell them. What if the ticket is actually technically impossible? Establishing priorities requires discussion.
* Related: how can you possibly have the product owners establish the milestones without figuring out what it's going to take to accomplish? Sometimes milestones have external drivers for functionality or deadline, and sometimes they're just checkpoints. But either way, it would be crazy to assume they're fixed relative to how long or hard their constituent items are. There are probably a million ways to construct a milestone, but I can't think of one that would be useful without a discussion with the developers.
* What's the correct granularity for a ticket? How would the product owner know how to break that down into specific work items? You need to own your own work queue.
* What the hell is a product owner, anyway? I understand there are various stakeholders and people whose job it is to play proxy for those stakeholders, and perhaps you have even formalized a PM role for managing all that. But invariably one of the stakeholders is you. That's partially because you're involved and presumably have applicable experience building products, but also because as the developer you care about aspects like infrastructure quality, and you need to represent that in the discussion of priorities. In my experience, everything works better with developers involved in the "what are we building?" process, not just getting work thrown over the wall to them.
* Why does the product owner, whoever they are, get to assign who works on what? What if I don't want to work on that item, or have a good reason why it should be assigned to someone else?
* How could this level of detachment from the why of the product ever make you happy?
More generally, this manifesto seems built around the idea of minimizing communication. That's a really bad idea. Building things is complicated and you need to have a process that's willing to face that, not bury its head in the sand and tell everyone to just create and assign tickets. Look, I don't disagree that meetings are painful and I'm always the jerk who wants a crisp, actionable agenda and gets pissy when things drag on. But replacing real planning with "just assign me stuff to do" is crazy talk.
> 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.
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.
In my experience, lack of communication is way more expensive. But I don't think the manifesto was about minimizing communication, I think it was about minimizing synchronous communication. Issues and comments and emails and chat are all asynchronous - people can ignore them until they have time to deal with them - whereas in-person conversations and meetings and phone calls are synchronous.
I think synchronous communication is incredibly important for big-picture items - here is what we're building, here is what we think it should look like, here is how we think it should generally work - and often necessary for working through tricky problems (pair-programming is a great example of this), but that asynchronous is better for pretty much everything in between.
I think synchronous communication is incredibly important for big-picture items - here is what we're building, here is what we think it should look like, here is how we think it should generally work - and often necessary for working through tricky problems (pair-programming is a great example of this), but that asynchronous is better for pretty much everything in between.
I once saw some meta-advice, that for almost all advice, there's people who need to hear it, and people who need to hear the exact opposite. I suspect that applies here; some teams communicate too much, others communicate too little.
(The original example I heard of for this is that people are usually advised to be less selfish, but some people have heard that messages so much that they think it's never ok to do things for themselves. If you're more selfish than you want to be, advising people to be more selfish sounds evil. If you're so unselfish that it's hurting you, advice to be less selfish might seem kind of unnecessary. So when advice to do more or less of something seems like bad advice, sometimes it's just because you're not the target audience.)
(The original example I heard of for this is that people are usually advised to be less selfish, but some people have heard that messages so much that they think it's never ok to do things for themselves. If you're more selfish than you want to be, advising people to be more selfish sounds evil. If you're so unselfish that it's hurting you, advice to be less selfish might seem kind of unnecessary. So when advice to do more or less of something seems like bad advice, sometimes it's just because you're not the target audience.)
Cool, I like that. It reminds me of the tension I've felt between two oft-cited phenomena: the Dunning-Kruger effect and impostor syndrome.
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 engineers that are each able to see the big picture (and they're all on-board with that big picture). Most successful startups have this team structure; occasionally big companies do (my positive experiences with this process were at Google), but once growth rates slow you typically start attracting people who just like to focus on one niche and do it well rather than worrying about the overall success of the project.
2.) It really helps to have the whole team colocated in one area. That gives everyone the tacit context that makes it all work. Yes, I know this goes against many of the other aims of the async manifesto.
3.) This works best on large projects where the deliverable is something that can be easily communicated. Visual redesigns and large refactorings are two good examples: you can say "You're done when the software looks like this interface mockup, with all the corner cases handled" or "You're done when all code conforms to the new API." It works worst on exploratory projects or things that require complicated algorithm design. I couldn't imagine using this to design, say, a new OS scheduler, and I tried using it (and eventually backed out) to develop Google's Authorship program but it was poorly suited for an exploratory project with vague success criteria. Oftentimes those projects are better off handed to a single developer, though.
4.) Priorities need to be rebalanced regularly - it was usually weekly or biweekly when I've seen this done successfully. And it has to be okay to just drop deprioritized work on the floor and assume it will never get done.
5.) Granularity isn't really a big issue. When you have a task whose granularity is too high, it becomes a cover bug: the person who takes it on treats their task as "Figure out all the subtasks that need to get done to achieve this", and pushes them onto the queue as dependencies with the same priority. Once this happens, the product owner may choose to deprioritize the whole lot of them if it looks like a lot of work for little benefit.
6.) The product owner is the point person, usually a tech lead or product manager. This does not preclude all the other developers from also taking ownership and responsibility for shipping the product; in a well-functioning team, that will happen. But there has to be someone responsible for interfacing with the rest of the organization or with the outside world, and responsible for ultimate delivery of the product. That's what they mean by "product owner".
7.) I've seen this work with both shared workqueues and personal workqueues, but it seems to work better with a shared workqueue, where pending tasks belong to the team as a whole rather than any one developer and people assign them to themselves only when they're actively working on them. The reason is because it load balances better and makes the team gel: instead of one person inevitably feeling overworked while another slacks off, you can get this amazing dynamic of people helping out and stretching themselves in any way they can. It makes it feel like the project belongs to the team as a whole rather than having someone tell you what to do. It also lessens the stress caused by having too much work to do or having personal issues get in the way.
8.) I'm a little surprised to see this in a manifesto on async development that explicitly discourages tribal knowledge. I've only seen this work in colocated teams with large amounts of tribal knowledge. I'm trying to think of what it would look like in a distributed team; the closest analogy I can imagine would be an open-source project with a public bugtracker, where product priorities aren't assigned by a "product owner" but rather by the number of people who say "When will this software package support feature X? I really need it to consider using this. Here's a patch."
9.) I've felt more engaged with projects using this style of task assignment than any other system I've encountered. It gives you rapid, immediate feedback on how fast you are progressing, a clear picture of what's left to do, and a sense of team camaraderie as you make shared progress together.
1.) This only works when you have a team full of self-motivated engineers that are each able to see the big picture (and they're all on-board with that big picture). Most successful startups have this team structure; occasionally big companies do (my positive experiences with this process were at Google), but once growth rates slow you typically start attracting people who just like to focus on one niche and do it well rather than worrying about the overall success of the project.
2.) It really helps to have the whole team colocated in one area. That gives everyone the tacit context that makes it all work. Yes, I know this goes against many of the other aims of the async manifesto.
3.) This works best on large projects where the deliverable is something that can be easily communicated. Visual redesigns and large refactorings are two good examples: you can say "You're done when the software looks like this interface mockup, with all the corner cases handled" or "You're done when all code conforms to the new API." It works worst on exploratory projects or things that require complicated algorithm design. I couldn't imagine using this to design, say, a new OS scheduler, and I tried using it (and eventually backed out) to develop Google's Authorship program but it was poorly suited for an exploratory project with vague success criteria. Oftentimes those projects are better off handed to a single developer, though.
4.) Priorities need to be rebalanced regularly - it was usually weekly or biweekly when I've seen this done successfully. And it has to be okay to just drop deprioritized work on the floor and assume it will never get done.
5.) Granularity isn't really a big issue. When you have a task whose granularity is too high, it becomes a cover bug: the person who takes it on treats their task as "Figure out all the subtasks that need to get done to achieve this", and pushes them onto the queue as dependencies with the same priority. Once this happens, the product owner may choose to deprioritize the whole lot of them if it looks like a lot of work for little benefit.
6.) The product owner is the point person, usually a tech lead or product manager. This does not preclude all the other developers from also taking ownership and responsibility for shipping the product; in a well-functioning team, that will happen. But there has to be someone responsible for interfacing with the rest of the organization or with the outside world, and responsible for ultimate delivery of the product. That's what they mean by "product owner".
7.) I've seen this work with both shared workqueues and personal workqueues, but it seems to work better with a shared workqueue, where pending tasks belong to the team as a whole rather than any one developer and people assign them to themselves only when they're actively working on them. The reason is because it load balances better and makes the team gel: instead of one person inevitably feeling overworked while another slacks off, you can get this amazing dynamic of people helping out and stretching themselves in any way they can. It makes it feel like the project belongs to the team as a whole rather than having someone tell you what to do. It also lessens the stress caused by having too much work to do or having personal issues get in the way.
8.) I'm a little surprised to see this in a manifesto on async development that explicitly discourages tribal knowledge. I've only seen this work in colocated teams with large amounts of tribal knowledge. I'm trying to think of what it would look like in a distributed team; the closest analogy I can imagine would be an open-source project with a public bugtracker, where product priorities aren't assigned by a "product owner" but rather by the number of people who say "When will this software package support feature X? I really need it to consider using this. Here's a patch."
9.) I've felt more engaged with projects using this style of task assignment than any other system I've encountered. It gives you rapid, immediate feedback on how fast you are progressing, a clear picture of what's left to do, and a sense of team camaraderie as you make shared progress together.
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.
I can almost reach the goal.
This is going to be a theme I will come back to a lot over the next fortnight. I am on the beautiful island of Kefalonia for a holiday and wondering why it is not a lifetime.
We work in a very fortunate society - rich enough now, connected enough now, to contemplate the almost impossible - having people far-flung work as well together as people in the same rooms.
We need to focus on the feelings of safety, of duty and comraderie, on the measurement of achievement and on the collegiate nature of lifting the less educated to par.
I can only achieve this dream if I throw out the nicieties of society and out reach others - or I can achieve this dream in the company of others - a harder task, but not impossible.
We work in a very fortunate society - rich enough now, connected enough now, to contemplate the almost impossible - having people far-flung work as well together as people in the same rooms.
We need to focus on the feelings of safety, of duty and comraderie, on the measurement of achievement and on the collegiate nature of lifting the less educated to par.
I can only achieve this dream if I throw out the nicieties of society and out reach others - or I can achieve this dream in the company of others - a harder task, but not impossible.
It's not about minimizing communication, it's about minimizing unnecessary communication and unnecessarily burdensome forms of communication when other forms suffice.
The examples you bring up are excellent examples of when to call a meeting. But those are the exceptions which prove the rule that you should call a meeting when needed, not by default.
Not every new feature or bug fix is so complex that it requires an hour long discussion to plan.
The examples you bring up are excellent examples of when to call a meeting. But those are the exceptions which prove the rule that you should call a meeting when needed, not by default.
Not every new feature or bug fix is so complex that it requires an hour long discussion to plan.
[deleted]
This is great if you work only with rock stars who care. In the vast majority of companies this is not the case.
Asnc communication is great for introverts who write well. I am a rarity in that I am a leader as a coder, Run teams Deliver products, but due to having Dysgraphia I write with great difficulty. No where in this set of guidelines is mentoring.
It could be summed up as RTFM
Asnc communication is great for introverts who write well. I am a rarity in that I am a leader as a coder, Run teams Deliver products, but due to having Dysgraphia I write with great difficulty. No where in this set of guidelines is mentoring.
It could be summed up as RTFM
There are people who are delivering creative solutions and there are people who are delivering never ending processes that creative people should follow to be creative and productive.
The chance of failure of a given project is directly proportional to the power of the second group.
The chance of failure of a given project is directly proportional to the power of the second group.
> Flexibility in prioritization over detailed planning
And who is going to do the prioritization - is that supposed to be strictly handed down from the top , top-down ? Also how is 'flexible' defined in this context ?
And who is going to do the prioritization - is that supposed to be strictly handed down from the top , top-down ? Also how is 'flexible' defined in this context ?
> Discourage one-size-fits-all space management. Some people work better in crowds, others work better at home. Let people decide for themselves.
I like this very much :)
I like this very much :)
I have found this to be true in my own experience both as a developer and team lead, and now as a CEO. But we are getting office space from our new investor, and I have to start coming into the office or we will seem ungrateful!
What are some of the most major benefits you've found from coming into the office every single day?
What are some of the most major benefits you've found from coming into the office every single day?
I droned on and on about it in a blog post once if you're interested: http://caines.ca/blog/programming/in-defense-of-the-office/ .
In my experience, it's waaaay more efficient for developers to be in the same room if you do it right, though I'm starting to think I might have a minority opinion on that.
In my experience, it's waaaay more efficient for developers to be in the same room if you do it right, though I'm starting to think I might have a minority opinion on that.
As a developer, a lot of my projects are not something that I need the rest of the team to do and most of the time the team doesn't need me. Hanging out in the office together is fine, but a lot of developers don't need to be in the same room to write great code as a team.
There are plenty of cases where better documentation, training, or other means of communication would provide a higher bus factor than always relying on pestering another dev. Also, with video chat, it's harder to believe that it is so difficult to meet or plan without being in the same building.
There are plenty of cases where better documentation, training, or other means of communication would provide a higher bus factor than always relying on pestering another dev. Also, with video chat, it's harder to believe that it is so difficult to meet or plan without being in the same building.
I literally write more than 90% of all code away from the office. People walking by, random questions/discussions, pointless meetings that make people feel like they accomplished something even though they didn't or someone just wanting to burn a few minutes. Office hours are the least effective and unproductive hours of my day and so I've avoided being there as much as possible because I'd rather show features more than showing face.
There are some big picture, architectural design discussions covering many interrelated components that can benefit form in-person meetings but those kind of meetings are the exception and not the norm in my experience.
There are some big picture, architectural design discussions covering many interrelated components that can benefit form in-person meetings but those kind of meetings are the exception and not the norm in my experience.
not in the sf Bay Area. I swear every company out here requires one to show face 10 hours a day.
I have made a habit of rarely using the phrase "I have to."
Because it's rare that you do.
Because it's rare that you do.
Is this for real? It can't be. Am I missing something here?
I sort of disliked the last point >Document Everything.
It's tough in an Agile project to keep up with all the stuff. Documenting everything wastes a lot of time.
It's tough in an Agile project to keep up with all the stuff. Documenting everything wastes a lot of time.
Documentation is (in my mind, although rarely in reality) really just a more presentable version of the spec, and that sufficiently well written specs provide 95% or more of the information required.
This also relies on the spec being updated with any changes agreed in the work process.
This also relies on the spec being updated with any changes agreed in the work process.
I think the main point here is:
Agile Manifesto - put together after lots of thought and signed by acclaimed industry professionals.
Async Manifesto - someone's opinion on a website.
Agile Manifesto - put together after lots of thought and signed by acclaimed industry professionals.
Async Manifesto - someone's opinion on a website.
I do wish people would reply with a decent criticism of my comment sometimes rather than simply downvote. I personally thought my comment was valid - it's not really a manifesto in the spirit of the Agile Manifesto if it's not agreed upon by lots of people, right?
Disagree? Then please say why...
Disagree? Then please say why...
Because you attacked the author, not the argument.
No I didn't. I attacked the premise. Someone is attempting to piggyback the agile manifesto to express their own personal opinion.
That opinion may or may not be valid, and is up for debate, but my point is that you can't just put up a website with your opinion on and say it's the "new" agile manifesto.
The rest of the discussion on here is about whether those opinions are correct - I was addressing the fact that the real, original, agile manifesto wasn't just "some bloke's opinion", it was the opinions of well known thought leaders that had distilled their experience and knowledge into an easily understood manifesto.
That opinion may or may not be valid, and is up for debate, but my point is that you can't just put up a website with your opinion on and say it's the "new" agile manifesto.
The rest of the discussion on here is about whether those opinions are correct - I was addressing the fact that the real, original, agile manifesto wasn't just "some bloke's opinion", it was the opinions of well known thought leaders that had distilled their experience and knowledge into an easily understood manifesto.
Attacking the credibility of the author doesn't address the merits of the argument. It's an ad hominem attack.
I thought HN had moved away from calling everything an "ad hominem" but anyway - no it's not. I feel that my point is directly relevant. The Async "Manifesto" is just one person's opinion, it's not a group of thought leader's opinions. There's a huge and relevant difference.
If he had called it, "my proposed new async manifesto" or something that would have been fine.
If he had called it, "my proposed new async manifesto" or something that would have been fine.
I thought it would be about async programming,i have no idea what the manifesto is talking about.Replace SCRUM? but what is their alternative?
A lot of open source looks like that.
I would add "docracy" - the person who is doing the work by default is making the calls.
I would add "docracy" - the person who is doing the work by default is making the calls.
can something this short and poorly argumented really be called a manifesto?..
anyway, sounds like the Chaos Model ( https://en.wikipedia.org/wiki/Chaos_model ), but with seating arrangements (?)
anyway, sounds like the Chaos Model ( https://en.wikipedia.org/wiki/Chaos_model ), but with seating arrangements (?)
Good content, but for the next manifesto, let's drop that vintage background and style. ;-)
Overall, this is a mixed bag. The general motivation and high-level concept is good, but even at the manifesto level some of the specific statements seem pretty bad.
Pros:
- General concept of leveraging asyncronous communication and minimizing disruptions to workflow; most organizations could probably benefit from considering this in their process improvement efforts, because its something that many don't do well,
- Preference for documented process (which is very important for team ownership of process and continuous bottom-up experimental and evidence-driven process improvement), and again its a place lots of organizations, of all types, seem to fall down on.
Cons:
- The idea that product owners can just assign priority; I think the best priority concept to come out of the agile tradition is that the product owner determines the value of a work item to a client, and the team estimates the effort of the item, and the priority is assigned in descending order of value/effort ratio.
- Related to the above, the idea that you can dispense with backlog grooming with no replacement. Backlog grooming is essential to get work properly divided into reasonably sized chunks (to avoid wasted effort on an improperly-scaled item) with independent value, and to assure that they are in a state ready to assess both independent value of the chunks and the work effort associated with them to set priority.
- Related to both of the above, the idea of skipping planning meetings, which aren't frequent so as to pose significant flow barriers, and for which (aside from shifting things that require the input of the team to being done without input by the PO) the manifesto provides no real alternative.
- skipping daily standups (proper daily standups should be scheduled so as not to be interruptions in workflow, and are designed to enable flow, not impede it, but providing both an important venue to address barriers and by constraining the disruption to other people that trying to do so by broadcast rather than regularly scheduled brief meetings would impose.)
- (mostly tangential, but, hey, its false and its right up at the top) the premise that "Scrum" (a top-down defined process-over-people-do-it-by-the-prescribed-Scripture-as-interpreted-by-your-centrally-Certified ScrumMaster®-or-you're-doing-it-wrong methodology) is implementation of Agile, which prioritizes, as the first element of the Agile Manifesto, people and interactions over processes and tools, is, while popular, dead wrong. Lots of the things in the Scrum guide are things that Agile organizations have found work for them and so do -- but Scrum is pretty much the opposite of Agile, and is the exact kind of packaged one-size-fits-all solution that the Agile Manifesto was a reaction against.
Pros:
- General concept of leveraging asyncronous communication and minimizing disruptions to workflow; most organizations could probably benefit from considering this in their process improvement efforts, because its something that many don't do well,
- Preference for documented process (which is very important for team ownership of process and continuous bottom-up experimental and evidence-driven process improvement), and again its a place lots of organizations, of all types, seem to fall down on.
Cons:
- The idea that product owners can just assign priority; I think the best priority concept to come out of the agile tradition is that the product owner determines the value of a work item to a client, and the team estimates the effort of the item, and the priority is assigned in descending order of value/effort ratio.
- Related to the above, the idea that you can dispense with backlog grooming with no replacement. Backlog grooming is essential to get work properly divided into reasonably sized chunks (to avoid wasted effort on an improperly-scaled item) with independent value, and to assure that they are in a state ready to assess both independent value of the chunks and the work effort associated with them to set priority.
- Related to both of the above, the idea of skipping planning meetings, which aren't frequent so as to pose significant flow barriers, and for which (aside from shifting things that require the input of the team to being done without input by the PO) the manifesto provides no real alternative.
- skipping daily standups (proper daily standups should be scheduled so as not to be interruptions in workflow, and are designed to enable flow, not impede it, but providing both an important venue to address barriers and by constraining the disruption to other people that trying to do so by broadcast rather than regularly scheduled brief meetings would impose.)
- (mostly tangential, but, hey, its false and its right up at the top) the premise that "Scrum" (a top-down defined process-over-people-do-it-by-the-prescribed-Scripture-as-interpreted-by-your-centrally-Certified ScrumMaster®-or-you're-doing-it-wrong methodology) is implementation of Agile, which prioritizes, as the first element of the Agile Manifesto, people and interactions over processes and tools, is, while popular, dead wrong. Lots of the things in the Scrum guide are things that Agile organizations have found work for them and so do -- but Scrum is pretty much the opposite of Agile, and is the exact kind of packaged one-size-fits-all solution that the Agile Manifesto was a reaction against.
Yes please.
21st century software development, early 90s web design.
It's in reference to this site, http://agilemanifesto.org/. Solidarity amongst manifesting people groups, I guess.
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 manifesto or whatever, and then you'd use it for some period of time, say a 2 week sprint, then at the end you talk about what works and what doesn't, and what needs to change to get better.
You try the changes and after 2 weeks you talk again, and again, and again until after a few months the process you have looks a lot different in big and small ways than it did when you started.
Nearly every criticism of agile feels hollow to me because they all bemoan the meetings or the planning or the cards or whatever and instead of having a team retrospective, fixing the process, and finding a better way... they trash agile.
If you are doing agile right, your processes will change and improve over time and that's a good thing. When your process stops changing and stops improving, you've lost.
Async manifesto is maybe a nice starting point for teams, but it's a woefully suboptimal end point for teams. We can do better than this.
Never stop improving.