Welcome to post-agilism.com.
The term “post-Agile” was simultaneously and independently coined in 2006 by Jonathan Kohl (Canada) and Jason Gorman (UK):
- Kohl’s blog: Post-Agilism: Process Skepticism
- Gorman’s article: Post-Agilism – Beyond the Shock of the New
Values and Themes
These are some overarching themes we have observed in post-Agilism:
Post-Agilism puts the onus on individuals on teams to determine their own destiny when it comes to their unique mix of technology, tools, and software development processes. Teams can give themselves permission to do whatever they like, they don’t have to answer to experts, coaches, books or articles. They are self-determining, and unique. No one has the right to tell you what to do, and how to develop software. That doesn’t mean you ignore experts, but you take different ideas and use the ones that fit, and ignore the ones that don’t work, or stop working over time.
A parallel of post-Agilism is in postmodern architecture. You solve a problem and get a result, but you use a combination of things to get the job done. Post-Agile projects tend to have a fluid, changing mix of processes, tools and practices that don’t really fit. You may see elements of Scrum with some older practices such as software inspections or defensive coding in one project. There is a fusion of processes that changes over time.
Determining a mix of technology, tools, practices and processes to help solve a problem right now, rather than looking for a process and following it doggedly, hoping everything else will turn out ok.
Dogmatic belief comes about when someone refuses to look at evidence to the contrary, and believes that their belief system, or software development process or tool is necessarily good, in all situations. Any thoughts to the contrary tend to be met with bigotry, blaming the victim and personal attacks. Post-Agilists tend to be against dogmatic belief, because the world is a complex place, and things change in our environments, so no one system can be right for everyone, every time. Attacking people with ideas because they are different, or don’t meet the popular thought of the day is not valued. Attack ideas, not people is part of the human-centered values of a good post-Agile debate.
Embracing Change (In Software Processes Too.)
Things change over time. The software process that worked really well may get stagnant, or certain aspects may become obsolete due to environmental factors, such as changes in the economy or market, changes in technology, or in team make up. Processes need to change too, not just the factors around them.
One overriding concept is that whatever mix of tech, tools and processes a team has, they need to help create value – valuable software for end users, a great company for stakeholders, and a good working environment for the people doing the creating. All processes must serve that end result, without sacrificing our product quality, our customers, or ourselves.
Teams that want to create something are less worried about process purity. They want to change the world, even if it is in some tiny way, so they look at technology, tools, practices and processes as things to help them solve problems and do something great with software. They do not seek to be the ultimate practitioner of a software development process, rather, the process is useful to the extent that it helps them solve a problem and achieve the vision of the team, such as a great software project. If you have a great process implementation, but you’ve created a lame, or unreliable/unusable product no one wants? Who cares? What matters is the over-arching vision – to create something with software that does some good in the world, even in a small way.
Treating people with different ideas with respect, and imagining and respecting the views and context of another person. That includes people with different views on how problems should be solved, whether they are to do with technology, processes or tools. This also includes the people that we create software for. Their needs are upheld, and we want to make sure we create software that enables people solve problems and achieve their goals without harm or onerous difficulty. People come first, and are not blamed when the tools, technology, software practices and development processes fail them. All those tools, software processes included, are there to serve people, not the other way around.
There was no manifesto created for post-agilism, but after a lot of queries, Jason Gorman created a tongue in cheek “post-agile manifesto” using an image from the dada art piece: Duchamp’s Fountain, which is often seen as a symbol of the rejection of strict rules in the art world at the time. Dada was a radical movement that was a precursor to postmodernism. It and other movements caused a lot of controversy at the time, but now postmodernism is commonplace. Check out the
Post Agile Manifesto here.