Are You Actually A Post-Agilist?

Have you heard that term? I happened upon it purely by accident about a year ago and after reading and learning a bit about it I found that I could identify with it quite a bit. You can read Jason Gorman’s post Post-Agilism Explained (Pretentiously) as well as Jonathan Kohl’s massive post – Post-Agilism Frequently Asked Questions for a great discussion of what the post-Agile movement is all about. Jonathan and Jason independently coined the term at about the same time so they are an authority on the term if anyone is. I am going to attempt to give my humble views on the topic and hopefully you will identify with some of what I say.

For those of you who’ve decided to learn about post-Agilism after they finish reading this post (thanks!), post-Agilism is basically a movement in the software development community of people who see themselves as moving beyond Agile methods. They have used Agile and not-so-agile methodologies and have moved beyond both to using an amalgamation of tools and methods that best facilitate them doing their job. Post-Agilism is not about evangelizing a particular process or a set of practices or even the Agile Manifesto, it is about getting to the core of the issues that process in general tries to address and solving them in the best ways possible. At least, this is the way I see it.

Post-Agilism is not about rejecting the Agile practices, it is about not limit yourself by Agile practices. I think the original spirit of the Agile movement has now become the spirit of the post-Agile movement as Agile is becoming less about the spirit and more about pushing a particular Agile process as the best one (there are so many to choose from now). At first it was Agile vs heavyweight; now it is still that, but it is also Agile vs Agile (we are an XP team we are the best, no we are clearly superior for we are a Scrum team!).

I for one get extremely annoyed sometimes at process vs process discussion (be they Agile or not), I see them as completely pointless. One of the core ideas behind Agile which most often seems to be forgotten is the fact that you’re meant to adapt, to ‘bastardise’ the process and practices until you get something that works for you. This makes any kind of process/practice purist argument meaningless. This very agile idea of being adaptable, of chopping and changing to fit your needs is now also at the core of the post-Agile movement.

To me, the most important thing about a process is the ‘spirit’ of it, not the practices. Quite often these days Agile teams seem to loose sight of the agile spirit and I think the post-Agile movement is more about the spirit. When I say spirit I mean things like:

  • respecting the individual
  • communicating effectively
  • doing work (writing code) that you could be proud of
  • not getting bogged down in minutiae
  • having some backbone when dealing with those around your team (i.e. stakeholders etc.)
  • etc.

And all of these at the same time, not one by one.

If these sound suspiciously like the Agile Manifesto, they are meant to, the spirit of the Manifesto is very sound. If some of these sound strangely unlike the Agile Manifesto they are also meant to, the Manifesto is not the be-all, end-all of commandments that we live by.

This I think is also at the heart of the post-Agile movement, it is not about the process, it is not about the practices, it is about the spirit of agile, it is about the ideal. Use your knowledge to select the most appropriate tools, processes and practices, whatever they happen to be. There is no best length for an iteration, there is no best retro format, pick whatever works and discard it if it doesn’t, as long as you stay true to the ideal, you won’t go too far wrong.

Here is an example that might help make my meaning a little bit clearer. I’ve been interested in distributed Agile for a while now. So, what do you do if you ever find yourself working in a distributed environment with multiple teams that are not co-located? Trying to make the best of a bad situation while all the while moaning about how much better things would have been had the teams been located in the same place. That is NOT staying true to the agile spirit (alright, you can moan a little bit, good for the soul and all). Trying to find ways to effectively collaborate, to make things work better, to innovate solutions, to get to know the people on the other teams (rather than complaining about their ‘crappy’ code). That would be living up to the ideal, staying true to the spirit of agile, or post-Agile as the case may be.

I found myself in very strange territory of not being able to find the words to adequately get my point across with this post (I can usually express myself pretty well, and loudly, just ask anyone who knows me). Parts of this post seem overly existential to me while others just seem to tread over the same ground. I guess it comes from trying to express ideas that are almost subconscious for me. Hopefully this will have resonated with people on some level or at the very least given people some food for thought.

Perhaps some comments might help clarify matters for everyone. I’ve tried to explain my thoughts, so what does post-Agilism mean to you? Would you consider yourself a post-Agilist or are you still firmly in the Agile camp (or god-forbid, heavyweight)? Any relevant thoughts would be appreciated.

  • Andrew Blain

    Hi Alan,

    I’m in the camp that believes that Agile has some worthwhile ideas but that no methodology is applicable for all situations. Agile works well when deployed in an environment that has a lot of unknowns but is a resource intensive methodology when requirements are reasonably stable.

    Depending on the situation that you’re in, a combination of:
    – medium intensity requirements analysis and solution design
    – thin(ish) vertical slices delivering core capability as priority
    – effort broken into reasonable length iterations and releases
    – use of agile coding techniques such as pairing for the more complex areas, and
    – incorporating elements of test driven development;
    seems to work for me.

    I’m really not a fan of:
    – refactoring for the sake of it
    – prioritising software quality over business value
    – pairing on all tasks
    – automating every test scenario that you can possibly think of, or
    – minimal effort in requirements analysis, software design and architecture.

    If that makes me post-agile, well and good. If that makes me heavyweight, well and good. I certainly don’t buy into agile as the be all and end all in software development.

    Hope you’re well,


  • I’ve always thought one of the tenants of Agile was to adopt what you need and discard when it exceeds. That aside, you raise some good points and I agree that in most situations, Mike Cohn’s strict adherence to all of the facets of Agile, can prove counterproductive.

  • Andrew,

    I don’t think constant pairing is necessarily an agile edict, but there are significant issues in software quality that the pre-agile world hasn’t understood well yet and is still resistant to. The loss of productivity and waste that comes from design flaws is much more egregious than the pre-agile world yet understands.

    Automating everything that can be automated, AND doing it expertly in a sustainable way that is informed by the economics of waste and continuous improvement is still a significant post-agile tenant.

    Test automation and merciless refactoring done for their own sake may very well be wasteful. Doing them with specific understandings of which testing and refactoring techniques and approaches increase productivity and decrease waste remains beneficial and desirable.

  • Dan

    I always thought agile had lots of good ideas, and I’ve taken from it many ideas and they’ve helped me improve as a developer. But the agile movement itself is too cult-like. I guess when the masses started adopting it they didn’t really understand the problems agile solved, and thus took it over and turned Agile into “Rigid”.

    Oh well what can you do?

    • The only way to change a pervasive mindset is one person at a time. This is why I try to explain what I believe to the people I work with as well as to the world through this blog :). Of course you don’t want to preach, but developers are smart people (mostly :)), if they have the information they will hopefully draw the right conclusion eventually.