Agile: Embracing change

For almost all of my career I have been involved with agile teams. For the last few years, I have been helping to build agile companies.

Like most good ideas, agile, at its core, is deceptively simple, but spend any time at all with the agile community and you will soon be given a list of practices and procedures that you “absolutely must” follow. You’ll certainly find no shortage of consultants who are prepared to guide you through this complex and hazardous migration.

After nearly two decades of building and coaching agile teams, here is my formula to adopting agile process management:

  • Meet regularly as a team to discuss the challenges you are experiencing. Propose, adopt, alter and abandon elements of your process. Treat nothing as sacrosanct save perhaps the practice of having these meetings themselves.

That’s it. There is no step 2.

This is not to say that there are not very good and worthwhile practices that form the elements of a codified agile process (i.e. scrum), but it is important to recognise that these things are simply the output of somebody else’s ‘retrospective meetings’. They have just turned out to be so successful in solving a commonly experienced problem that they have been added to the collective agile conscious as part of the toolset.

It is easy to imagine some hypothetical team who, in their retrospective meetings, highlighted a problem related to communication and proposed the solution of a daily morning meeting. In a subsequent retrospective they may have decided that while this meeting was useful, it was becoming too long and tedious and needed to be held to a time limit. Later perhaps, somebody proposed that ‘not getting too comfortable’ was the key to ensuring a timely completion. The daily standup was born.

Another hypothetical team may have highlighted the very common problem of, “too many priority 1 work items in the backlog”. Anybody who has ever worked on a project that utilises the old trope of classifying work as P1, P2, P3 etc will have experienced a problem like this. The P1 classification quickly loses meaning when 70% of all issues are prioritised as being P1. The proposal from this team would have been to organise all outstanding work into a single, linear, prioritised list such that all things have a priority relative to all other things. The linear backlog appeared.

These practices, and many others like them, are very good solutions to common problems, and it is a good idea to learn about them and the problems they solve (an endeavour with which Learnerbly can help), but the key is to be like these hypothetical teams. Allocate time for these discussions and don’t be afraid to experiment. The beauty of the agile approach is that any new practice can be adopted quickly and if it fails to solve the problem it was designed to solve, it can be altered or dropped just as quickly. Your processes are always a work in progress. They are constantly “in beta”.

It is no great surprise that agile as an idea has found the greatest steam within the software development community. We software engineers have been going through this process since the birth of our relatively young industry. We considered ourselves engineers, and while software engineering was a new idea, other forms of engineering were more familiar. We borrowed from these disciplines.

So it was then, that we set about building our software. We spent huge amounts of time, painstakingly designing every element of our digital products before we even considered writing our first line of code. This was after all, an engineering project.

Bridges, as it turns out, are hard to change once you are half way across the river. Software need not be. As we began to learn that the most successful software projects were those that took advantage of this malleability, we started to devise new ways of designing and building systems. The movement towards a more agile approach was a natural outgrowth of this realisation.

A collaborative process working towards any goal (software delivery or otherwise), shares many of the characteristics of software development. Processes are themselves malleable. Where they are not, this restriction is almost always artificial, the result of dogmatism. The worst reason to continue to act in a way that is non-productive, or even counter-productive is because, “it’s the way we’ve always done it!”. Being agile means banishing that excuse and that way of thinking. Continuity of destructive practices is not a virtue. Embrace the change!

Like what you read? Give Wesley Hall a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.