Don't Let Mandatory Developer Meetings Suck You In

Don't Let Mandatory Developer Meetings Suck You In

Last century’s way of doing things isn’t just annoying; it’s dangerous.

Anything Made into a Ceremony Sucks

For instance if a particular organization likes group code review that’s fine. Now imagine all software development teams require group code review meetings to fulfill an “agile ceremony”.

  • There would be an impact for distributed work, remote work and depending on the time of the meeting, additional rush hour commutes.
  • You would sometimes be blocked waiting for the next group code review meeting.
  • Work per iteration limited to what can be reviewed in the code review ceremony
  • Meeting skills more important, and some developers fail to make the agenda.
  • Reviews done in the meeting suffer from time constraints and group think.
  • A meeting kills more than just the time it takes - maker’s schedule problem
  • Entire team must know what everyone else is doing in detail!
  • Code review tools would not exist.

CI/CD is another example of developers and asynchronous tools used instead of meetings. Where once there were regular meetings to approve batches of changes now many organizations have automated testing and continuous releases.

Current agile meetings are no different - exclusively synchronously batch processing project management lacks the flexibility to succeed.

Clustering Doesn’t Help Much

No meeting Wednesday or scheduling as many mandatory meetings on the same day as possible are not really solutions. Back to the code review example, converting an activity that’s continuously performed with the help of a tool to one done point in time without help will always cause issues.

Diverge

Only in the case of agile project management you probably have never seen the continuous, tool assisted version so did not fully realize how inadequate meetings are.

Mandatory is not Self-Organizing

The craziness of a forced group code review ceremony doesn’t happen because code reviews are self-organizing. Developers decide for themselves when asynchronous is sufficient and when to call a meeting.

As you can read in our blogs, that’s not the case for planning, retrospective, daily and Sprint review ceremonies. Even if a development team takes all ceremonies as suggestions, they will still need the right asynchronous tool to explore alternatives.

Self-organizing is not all or nothing. With the right tool, each of the above ceremonies represents a different area that can be self-organized as code reviews usually are.

Not self-organizing fails the demands of the future, and technical and non-technical skills fall behind.

Coding and Managing

Diverge

You can have your technical skills and greater responsibility as well, but it requires being smart with your time. Meeting driven process is too time-consuming to allow for much leadership.

Plus a team that is spoon-fed its process is likely to expect everything to be decided for them or even regress to needing constant attention.

The Right Tool

Meeting driven process interconnects. So instead of a tool per meeting, find one tool, like Uclusion, designed for your entire process. Without that tool you are stuck on mandatory meetings and so is your career.

David Israel
David Israel Co-Founder of Uclusion