In which I tweak the Manifesto for Async Software Development.
Tweaked Manifesto for Async Software Development
It's time for a 21st century successor to Agile and its most popular incarnation, Scrum.
After many years of developing software using Agile methods like Scrum, the time has come to value:
- Modern tools and flexible work environments over meetings and office hours
- Flexibility in prioritization over detailed planning
- Continuous delivery over timeboxed sprints
- Comprehensive documentation over tribal knowledge
That is, while there is value in the latter items, there is more value in the former items.
Principles of Async Software Development
- Each integrates version control with issue tracking with low friction.
- Each offers sufficient prioritization and assignment features.
- Each wraps all that up into a thoughtful user experience that anyone on the team can use, including nontechnical people.
Meetings only as a last resort
Meetings are very costly. It's not just the time spent at the meeting itself.
Most of the cost is in depriving creative professionals of the long stretches of uninterrupted time needed to get meaningful work done.
Thus, async communication should be your default, because it better enables participant choice of when to interrupt.
Forget the planning meetings.
Product owners can replace planning meetings by simply filing issues in the issue tracker, assigning priority, and drafting release milestones. People will know what to work on by simply assigning themselves whatever is the highest priority issue in the queue that they're prepared to add value to.
Rather than planning sprints, continually release ready change. Production release is the "Definition of Done".
Skip the daily standups.
Everyone can ascertain status by viewing
- the issue tracker, and its activity feed
- the source code, and its activity feed
- the latest builds, continually available in non-prod tiers
- the production product, because the point is to continually ship change to production. The product is the status.
Retire the backlog grooming sessions.
Product owners should own the issue queue and frequently reassess priority on their own. They should loop in other people on an as-needed basis for advice. Everyone should loop themselves into the items in the queue as they see opportunities to add value.
Call a meeting only when all other channels of communication aren't suitable for a specific issue.
No sprints, so no sprint reviews.
Rather than gathering for a Sprint Review meeting, continually review progress with stakeholders (and continually do user testing, too). Progress more changes asynchronously rather than waiting for a big sprint review meeting.
Flexible work environments
Since modern tools and async communication makes 1950s-style meetings-centric office cultures obsolete, we can enjoy much more flexible work environments now.
Adopt a hotelling policy at your office.
Don't assign desks to anyone by default. Anyone who requests an assigned desk should get to choose whether it's a private office or in a communal space.
Discourage one-size-fits-all space management. Some people work better in crowds, others work better at home. Let people decide for themselves.
The better documented your workflow, the less your workers will need to interrupt each other to seek out tribal knowledge.
A question answered in a FAQ or some other form of async communication is much better than one answered by a shoulder tap.
People assign themselves; managers do not assign people. The line in the original Async Manifesto about Product Owners assigning issues to team members is what drove me to fork. Product Owners manage products, not people, not work assignments.
I'm not sure I fully believe in this post-Scrum model. Scrum works pretty well and it's better than what came before. But I'm totally sure I believe in people assigning themselves issues rather than a manager assigning them to people, and I needed a forked Async Manifesto with this feature.
Highlights of my changes:
- People assign themselves. More generally, spiffed up more bottom-up-ness. (For example, Product Owners don't just loop in people; people loop in themselves as they see opportunities to add value.)
- Added content, e.g. about sprint review meetings
- Added mention of continuous delivery opposed to sprints.
- Dropped mention of BitBucket.
- Tweaked some word choice, tone throughout, generally to adjust emphasis away from gee-wiz-slick and towards thoughtfulness.