The lines of thoughts in this post started with Peter Antman inviting to a meeting to discuss a new thing called #notest - a very interesting subject clearly. I felt an urge to rant a bit about this #no trend and thus this tweet:

the new thing after agile is to put "no" in front of standard practices: #noestimates, #notest, #noprocess, #nomanagement but never #nocode

— Fredrik Rubensson (@froderik) November 20, 2013

Normally when I rant on twitter I get no responses but this time my tweet spawned two separate threads that merged together after a while. Both threads questioned that agile is something of the past. And maybe they are right. I don’t know. What I do know is that everyone wants to be agile these days. Agile has won. But at the same time agile has lost its controversy. When I look at the agile manifesto today I just feel that “yeah - this is how I work - this how I react even”. And I am sure many developers feel the same way. The manifesto was hugely important when it came. It summarized a couple of good process oriented movements in 4 points. These 4 things is not much more than common sense really. The reason it was needed was due to the monstrous processes that had grown in strength during the 90s and that threatened to suffocate the entire business. Now agile has been embraced by many. I consulted for a large organisation some years back that claimed to aim for being best in the agile class yet they had no agile practices whatsoever in sight. I then deduced that the word agile for many had come down to just mean good. We work in an agile/good way. And no one wants to work in a bad way. Suddenly some of the old bad practices also makes it into the agile portfolio.

Nowadays I just want to get things done. If the process stays in the way it has to go. Agile or not.

We now live and work in a postagile world. Agile has won and now we have to find out how to improve our work within that mindset. We also need to protect the gains that has been made over the years. Lets have a look at each part of the manifesto.

Individuals and interactions over processes and tools

The morning meeting and the retrospective has won. Most team work in this way now. We have to beware of getting value out of the morning meeting. In my last team we tried to talk about each thing on the board rather than walk through all the persons. It worked well with a senior team. With a new team it may be better to just go the round. A tight team may decide to skip morning meetings altogether. They are just there to make sure that communication happens.

Sadly enough we are more likely to find morning meetings in a team than retrospectives. The tool for continuous improvement that takes place outside the daily loop is of course very important to get anywhere. In the postagile world we need to make sure that we don’t miss out on retrospectives and the opportunity to improve our process continuously. We also need to guard against the agenda of tool vendors. I recently heard that one of my old clients were about to implement a planning to tool to help them with their agile process. Sigh…

Working software over comprehensive documentation

I have seen one case where a scrum-by-the-book team ended up with no documentation at all. I was asked to do an architectural review and the only material to use was source code and tickets. That was fun! In a postagile world we need to produce the artifacts that is needed. This will always be mostly source code but occasionally we will need to write a couple of documents. These documents are likely to be system overviews. How does things fit together. I like to think of this need as maps. Maps to help navigate the system and the surrounding world of users and other systems. This metaphor works much better than architecture for me.

Customer collaboration over contract negotiation

This really is about trust. If there is no trust between the customer and me I am lost anyway. It probably is scary as hell to buy custom software since so many projects still fail so badly regardless if they are based on customer collaboration or not. In a postagile world we need to give and receieve trust and we need to educate our customers in demanding visible deliverables continuously. Still many teams are reluctant to deliver things soon and many customers don’t want to get that involved. That need to change. Customers must involve themselves in the delivery rythm of their software team and the team need to be verbose about their progress and more importantly about their obstacles. There will be no true dialog about a piece of software until it is there to look at and use. It happpens all the time that the first time there is any real feedback is when the piece is in production.

Responding to change over following a plan

This one is a bit tricky. While it is normally no point in planning the future many organisations need to manage expectations about the future in some way. Plans for what features will get into future releases may be necessary to keep business. You may see this also as responding to change but it is likely that the business side of things would like to call it a plan. In a postagile world we need to make long term plans that can be abandoned when we respond to change. We need to be good at communicating this dilemma.

What is this postagile thing anyway

Duckduckgoing for postagile gives a bunch of interesting hits. I guess people started talking about postagile even earlier than the infoq post from 2007 that asks “Is Post-Agile Just Agile?”. The answer is yes. So the idea of something postagile has been around for a while.

My twitter ranting lead to an interesting dialog with Woody Zuill and J. B. Rainsberger to start with and then Henrik Johansson and Yves Hanoulle joined in. After that I felt the need to rant a bit more in this post. To sum it up - this is what I have found:

Agile is the consensus we have reached. Postagile is the task of improving our work on an agile foundation.