A Paper Tiger Manifesto

Someone recently brought the Manifesto for Async Software Development to my attention.  I was intrigued and curious because I believe there is a role for some async aspect to development in our hyper connected world.

Alas, this manifesto is completely empty because it isn’t rebelling against anything real.  If it’s satire, bravo — you sucked me into your illusion.

The “this over that” format is the only similarity I see between this and the Agile Manifesto.  The historical context of the Agile Manifesto is important to better understanding it.  The “over that” clauses in the Agile Manifesto represent real things that occurred in software development of the 1980’s and 1990’s (I was there).  People really were writing comprehensive documentation and advocating for it before creating any software.  People really were selling tools and monolithic processes as the saviors of software development instead of having people actually talk to each other.

I don’t get the Async Software Development Manifesto because I don’t see Agile or Scrum arguing in favor of useless meetings and office hours, detailed planning, or tribal knowledge.  If people think Agile and Scrum are in favor of those things, that’s because of a mis-adoption of the principles or just bad management.  Bad management is still bad management, regardless of the approach used to developing software.

A manifesto needs something legitimate to rebel against in order to have meaning. I just don’t see it in this case.  It feels like the Async Manifesto created a mirage against which to argue.

I’m not sure whether to read the set of “Meetings only as a last resort” principles as satire or seriousness.

  • Product owners can replace planning meetings by simply filing issues in the issue tracker”?  Really?  Nearly every developer I know would have a stroke if they weren’t involved in the creation of the backlog.
  • “Product owners can ascertain status by reading the comment threads of issues currently being worked on and posting questions as needed.”?  Really?  Someone actually thinks a potential multi-day back-and-forth in comment threads is better than a five-minute conversation?
  • “Call a meeting only when all other channels of communication aren’t suitable for a specific issue.”  Well, duh.  But it’s a lot easier to have a planning meeting on a regular cadence than it is to try to schedule an ad-hoc meeting.  See principle F9 in Reinertsen’s seminal “Principles of Product Development Flow” for the statistic and economic proof of this.

Most of the “Flexible Work Environments” principles contradict the first stated principle of “creative professionals need long stretches of uninterrupted time to get meaningful work done.”

The “Document everything” principle is too absolute.  It takes us back to the 1990’s.  We don’t need to document everything and we don’t need to document nothing.

I understand that there’s a role for async work in today’s distributed, hyper-connected world, but it’s not the end all and be all solution.  It’s also not completely contradictory to Agile methods, including Scrum.