Agile Myths Exploded

One of the few good things about the current pandemic is that it forced people to rethink some of the most rigid 'agile' practices, such as:

Co-location

It turns out that development teams can function perfectly well in an agile environment without being physically located in the same space. We kind of suspected that due to the pre-pandemic success of many remote-working companies, such as Basecamp, Zapier, Moleskine and many others. But now most of us found out that -with a few workflow adjustments- any team can be productive when working remotely. Not only that, but the lack of commuting and workplace distractions means that many people can be more productive away from the office rather than in it. It also means that we can include people who would find it hard to commute to an office every day, such as disabled ppl or ppl with parenting/caring commitments.

Stand-ups

These were short meetings where attendants would be literally standing up. The idea was that this would encourage short and focused meetings. The end of co-location also meant the end of stand-ups. People discovered that they could have short, focused meetings on Zoom or Skype. Turns out, the duration and focus of meetings depends on the attitude and culture of the participants and organizers, not on everyone standing up together in a room. Who would have thought?

"No documentation needed", a.k.a "You just need to have a conversation"

This is one of the most abused notions in agile. One of the Agile principles is that

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This is absolutely true. Sure, you may need to repeat the same thing to different people many times. And, yes, some information gets lost through verbal transmission, as the 'telephone / chinese whispers' game demonstrates. Also, some ppl are much more receptive to visual info, rather than verbal.

But, overall, talking to ppl is the best way to convey information. However, it should never be the only way. The Agile Manifesto doesn't state that we shouldn't be documenting things. Just that we prefer working software over comprehensive documentation.

You have to realise that at the time the manifesto was written, working code was the last thing a software team was meant to produce. First it needed to deliver documentation: SDDs, STDs, SRSs and other horrible acronyms, were some of the bureaucratic documents we had to deliver before even stating to think about coding (I know, I used to do this, I'm that old!). An analyst would write a requirements document and then hand it off to the development team and forget about it. The agile founders said: "This is stupid and counter-productive. Stop it!". For that, I am eternally grateful. But they never said to not document what we do.

The pandemic exposed the weaknesses on relying on conversations and omitting documentation. Before, if we needed some information we could just turn round and ask the person at the next desk. It was easy to just shout out something across the office so that everyone would hear. It is no longer that easy. The immediacy of response is lost. Now, putting a message on the team slack channel does not mean you'll get back an immediate response or even acknowledgement. Also, talking about something is much quicker than writing. If I have to write a response to the same question again and again, I may as well paste that response in a document and link to it.

People have to rely on documents and diagrams much more now, to ensure that information is conveyed reliably and accurately. This is how it should be. Documentation is persistent in way that verbal communication can never be. It is more resistant to corruption. It also helps clarify or enlighten in ways that verbal communication can't (try explaining complex/parallel workflows without sequence diagrams, for instance).

Conversations should form the core of information flow, but they must always be supplemented by proper documentation.

"UML is not agile/too elaborate/old-fashioned/...etc"

A side-effect of the "no documentation" fallacy was this myth. UML was a 'waterfall' thing. Only old ppl use UML. It's not needed in agile world.

The thing is, UML is just a notation. Yes, it's been used as the basis of rigid and complex methodologies. But that's not UML's fault. One of the pandemic consequences of ppl starting to use more diagrams in order to convey information (see previous section), was that the lack of common standards became exposed. What does that dotted line in your diagram mean? How is that rectangle different to that oval shape? Does that thing represent a class or a database table? If only we had a universal notation so that we can all express our designs in the same way. If only we had a ubiquitous visual 'language' understood by all.

....hold on. We do! It's called UML. It helps us communicate our thoughts visually and uniformly.Good communication is critical to an agile workflow, so UML is too, as many more people are beginning to realise.

Epilogue

Often, certain practices may not make sense to us but we are reluctant to call them out because of peer pressure and cultural acquisition. Sometimes it takes a universal and external event to expose the weaknesses or irrelevance of these practices. The pandemic is making us rethink much of the way we work and live our lives. But despite the many negative effects, it can also help us change some things for the better. Stay safe and keep productive everyone!