Stick along long enough in software development, and you may have come along the ride for Agile software development practices, methodologies, and/or frameworks. Stick along long enough in that community – ok, that might be a reach too far, given that community only exists about 30 years or so. All of the above said, I notice some developments lately around the term Agile, and need to get my thoughts down. Not that I think I have a particular relevant perspective to start with. But maybe I can offer some perspective to one or another reader.

If you know me, you probably know that I have a tendency to look back on where did we come from to better understand things happening in the present. If you are not that kind of understander, maybe this blog entry might not be for you. So, be warned before moving on.

Approaches and Frameworks

Starting from the early days, with Scrum, eXtreme Programming, Feature-driven development, Pragmatic Programming, DSDM, Crystal and Adaptive Software Development joined by the Context-driven testing school of thought forces joined together to discover a commonality among them. I once heard one of the co-authors say that he thought the particular meeting in Snowbird, UT in February 2001 was probably the only point in time when the 17 people attending the event was able to agree on something.

Some years past, and eventually at some point I also became aware of this particular group of people and the writings. It was the where things felt still engaging – at least to me. I also started to hear concerns from the originators of the Agile Manifesto. Take for example Brian Marick’s AR⊗TA keynote, or the missing fifth value pair. It was the time close to the emergence of the Kanban community as well.

In hindsight I consider the approaches that came out of all those efforts, like the Craft community and the Lean Kanban movement as sort of a 2nd generation of approaches. Some never really took off, ,though they shared the sentiment I experienced back in the day, and they had some really great ideas floating around. But some of them wouldn’t stick, but the whole Agile movement continued.

Value systems and Methodologies

Something similar happened when it comes to value systems alongside guiding principles in my view. Let me try to explain. Early on, the principles behind the context-driven testing school were a clear driver for my work as a tester – back in the days. After experiencing first-hand how the ideas behind XP, Scrum, and so on came to fruition and actually worked, thought it seemed counter-intuitive on first read-throughs, I was convinced there is a better way to work than the models I had experienced up until then. I became addicted – and still am.

Skip forward a few years, and the initial methodologists starting to publish new models of their then-current understandings of the market situations. It was the times when Joshua Kerievsky started to share his Modern Agile thoughts, Alistair Cockburn wrote about his Heart of Agile, and I’m sure there are many that I missed. In fact, I recall reading from Alistair Cockburn back in the day on a social media platform that was still known to be Twitter, that lots of original methodologists were publishing new things, and he appeared curious to me on the things to come.

I think this uprising was the 2nd generation of methodologies that was coming along. A second wave for the folks in the early and late majority of the technology adoption curve.

Scaling – or what about more than one team?

Another re-appearing topic over the years has been the question: “But Agile favors development of a product in one team. What do I do when I have larger products?”

In the beginning there was one initial publication on the topic: the Crystal family of approaches (I hope Alistair bears with me on calling the Crystal family approaches). You had Crystal White for smaller developments up to Crystal Red for larger product development groups.

In my eyes, the downfall started to appear whenever some large business consultancy coined the phrase “Spotify Model” deriving it from the 2013 presentations and write-ups on how Spotify worked then, combined with the up-roar of what Mike Beedle always called S_Fe, since it never had a grounding in the missing letter. That was also the time when Large-scale Scrum got a name (even though their approaches were floating around way longer than that), Scrum@Scale started to appear, and I got involved in the ScALeD principles and the Agile (De-)Scaling Cycle. Those appeared to me as a 2nd generation of scaling approaches.

Skip forward a few years, and the neglected two years of a global pandemic, and approaches like UnFix and FAST among others started to appear. By my counting those would the 3rd generation of scaling approaches.

Given we appear to be in the 3rd generation of the scaling approaches, while still being on the 2nd generation of methodologies and frameworks, I dare to raise the point that folks in the late majority are now trying to think Agile from the perspective of “many teams first”. And I assume they will soon start to rediscover the forgotten lessons of the things that came earlier, like test-driven development, software teaming, and internal open source.

So, where are we heading to?

Honestly, I really can’t tell. More and more I hear from companies that got disappointed from the gap between early Agile adoption promises and the results they see now. Maybe by a lack of understanding of the necessary investments they need to make (i.e. inspired from the Agile Fluency model). Maybe the companies paid a lip-service to these efforts anyways to check mark on things they tried. Maybe because they tried, and for reasons yet unknown they couldn’t get it working for themselves.

I still see things from the Agile movement that we will need in a potential post-Agile world, and there are some things that will be more likely to stick, while others may or may not go away completely.

No matter how I look at things, though, I have a strong belief in the value of the things I learned over the years, and the things I passed on, stemming from my experiences working in an agile way. I really don’t care too much whether we will continue to call it Agile in the future or not. But given how many companies have a negative association with that term right now, we might be on the brink of discovering a new name – alongside with some more generations of ways of working that I am sure will be helpful to the generations of product developers yet to come.

I look forward to that. And maybe it will be the time when we stop fighting over a particular item in the Definition of Done, or whether to use Scrum or Kanban, and just know how to work in an effective way.