A methodology for everyone: how I learned to stop worrying and love Agile — Part I

Now that the world is still affected by the global pandemic and is functioning in remote and hybrid work environments, more and more industries are seeking ways of working that are more compatible with it. No wonder, these other industries are turning their gaze towards Agile methodologies — the tech sector adopted remote working long before any other “office” job and it seems to turn out more successful than the traditional approach to planning. But is it the right way to go about the way of working for 2022 and beyond?

In a series of posts, I’m going to explain why I think it is fully justified to try out Agile methodologies now no matter what industry you work for, provide you with examples of practices that you can adopt, and, of course, try to back up myself with data. This particular one is an intro, where I’m going to give some definitions and argue why it’s not that easy to tell for sure if Agile methodologies actually work.

Illustrations vector created by storyset — www.freepik.com

What is a tech company, anyway?

I started the story by comparing the tech companies with other industries. But how do we define the tech companies in the first place? According to this article, a tech company is the one that uses technology (no matter if proprietary or carefully assembled from partner solutions) as its competitive advantage, in other words, such a company wouldn’t survive if you took it away from them. I personally like this definition a lot, as it allows to distinguish a company operating in an industry and relying on technology from a company that disrupts the industry they happen to operate in with their tech.

What is Agile?

Now that we know what the tech companies are, let’s revise the definition of Agile methodologies. Atlassian, one of the leaders in productivity software, emphasises that Agile methodologies are about an incremental approach to building things. With Scrum being more focused on fixed iterations resulting not only in the product improvement that can be directly demonstrated, but in various statistics on team performance, and Kanban valuing the continuous process and work efficiency by narrowing the team focus and work in progress.

Scrum Vs Kanban created by Addteq

According to the State of Agile Report of 2021, Scrum remains the most popular Agile methodology with over 66% of teams surveyed preferring it and its derivatives over other frameworks. Thus, I might be using the terms Scrum and Agile interchangeably for simplicity.

Are we sure it works?

Most of the sources list getting more things done with less stress and prioritising people over processes as the main benefits of Agile development. Is it enough to justify this way of working for your management though? Here Agile evangelists tend to come up with data on increased developer happiness and productivity. However, after a quick literature review, I realised there’s no credible data on Agile methodologies' impact on it and here’s why:

1. There’s no agreement on how to measure Agile effectiveness in teams. Amount of work done in a period of time measured in number of projects/story points? — But what if this work wasn’t needed and occurred only due to poor prioritisation and overlooked bugs? Team happiness measured as churn of employees? — How would you isolate it from other factors in the organisation? And so on and so forth. Various sources I found were relying on different metrics to showcase either Agile success and failure and there seemed to be almost no overlap. This brings me to my second point.
2. Although often applied to tech teams, the research in work organisation belongs more to management or social studies that tend to have more difficulties with standardisation of research practises, and, as a result perhaps, have less impactful journals measured as JIP factor or h-index of the authors publishing there. For example, both papers on Agile teams productivity I found are published in journals with an impact factor of less than 1 that have just a few citations. For comparison, a fundamental paper on relational databases by Codd (although database design, just like Agile methodologies, is an ongoing topic of debate) now has more than 5k citations, among which 1.8K in the last year. I would expect a similar volume of interest in the scientific community to something as fundamental as Agile development.
3. Finally, we rarely see an unbiased opinion on Agile methodologies. The state of Agile report itself, my main source for this blogpost, is an interested party, as 4k respondents in their latest survey claim to work… as Scrum masters or internal coaches in their organisations!

Long story short, if you’re considering switching to Agile it’s a leap of faith and you should be surveying your own teams to figure out if it makes things easier in your particular case. But the good news is that in my opinion, trying out Agile is not a fundamental shift and, as the name suggests, there are a couple of tactics up its sleeve that you can adopt safely. I’ll talk about it in my next blogpost, stay tuned!