“Doing Agile” is no more appropriate than “doing French”: Steve Pitchford will argue at Devoxx UK. Agile is a long-abused term in some businesses, a force for good, and sometimes a force for bureaucracy. We asked Steve what “Doing Agile” is, and why we should stop it.
What is ‘doing Agile’?
For me, it’s a cardinal sin of cargo cult proportions! There appears to be constant debate and re-interpretation of “What is Agile?”. For me the easiest definition of Agile is that it represents the conclusions of some of the leading experts in software development following an meeting of minds back in 2001.
These conclusions are hosted here and comprise three main documents. The first is The Agile Manifesto (which most have heard of). The second is a list of Agile principles. The third is an interesting document called “History” (AKA “About the Manifesto”) which explains the context of the meeting – for me, that’s the interesting part.
When I read the history document, I saw it as a description of Agile as not a set of things we do, but instead as a cultural feature of well performing workplaces. To me, that makes a significant part of agile “cultural” in nature. That is, we could think of Agile as something that we are rather than something that we do.
What are some of the worst crimes committed against Agile that you’ve seen?
There are so many! One only needs to look at comments on the Michael O. Church “Why ‘Agile’ and especially Scrum are terrible” blog post to read of horror story after horror story. Whilst I cannot agree with much of the post, the comments serve as a repository of agile sin and bad practice.
I think a lot of bad practice comes from naivety on two fronts. First, naivety of the impact of change. Then confusion as to the destination. Agile still seems to represent a leap of faith, which seems inexcusable since it’s now over fifteen years since the manifesto was written.
So we see a lot of organisations seeking to become Agile without any understanding the journey. This is both in terms of the processes of change management, and also ignorance of the form and function that a well run Agile team possesses. This can lead to an organisation embarking upon the agile journey – only to find themselves lost in a change process they don’t understand, travelling to a destination they have never seen, unqualified to seek help. Also, potentially victim to potentially expensive third party “help” that isn’t guaranteed to help. Small wonder the agile journey is such a minefield!
One tale springs to mind – I heard of a workplace which attempted to “go agile” and instead implemented anarchy. All roles were removed, creating a flat structure. A lack of experience was no barrier to decision making on an architectural level. Fortunately, the organisation had sufficient foresight to make some contingency arrangements. They were able to recover from a very costly experiment!
Should developer organisations be focusing on methodologies like Agile?
I think it’s an essential part of any organisation to appreciate the environment in which their members operate.
For me, the project-centric orientation that Agile methodologies encourage is helpful. By enabling developers to focus on delivering well formed outcomes, and the business focusing on communicating these goals effectively, I believe we see greater alignment between business need and developer output, a more efficient use of talent, and a happier, healthier workplace as a result.
Many of us have witnessed the onset of dev-ops, and microservices. The workplace culture seems to be an essential part of this greater movement. It’s almost like Conway’s law is entering a period of inversion – we are witnessing the creation of technologies which facilitate better communication structures within the organisations which adopt them.
These new technologies facilitate a changing role for developers. To me, they underline the importance of developing and maintaining a “what/how” split: in terms of developer teams taking responsibility for how to deliver, and the business providing a clear roadmap of features and opportunities to explore ( the “what” ) .
So I’d argue that as developers, we not only need to try to understand “Agile” and other issues impacting the software development domain, but also have a sense of appreciation for the problems space our non-developer colleagues operate in in order to foster respect and communication. I think it’s the responsibility of any developer-centric organisation to help with this journey.
How do you implement a methodology without missing the main aims/diluting the message?
There are tiers of complexity. It’s very important to ensure any proposed methodology is compatible with the organisations goals and regulatory environment. A methodology that is appropriate for a webshop may not be appropriate for development of a fighter jet or medical equipment, for example.
I’ve heard the argument that any methodology imposed onto an organisation needs to be compatible with the organisational culture of said organisation. This is if it is to have any chance of success. It implies that effective internal marketing of any change is essential – all parties involved need to be able to buy into, and potentially contribute to the vision of why change is necessary and what outcomes it will enhance.
This buy-in for change needs to be maintained. It’s not just the case of creating an upfront change plan and running with it. The change process represents an ongoing overhead. The impact on staff time should be considered before an organisation attempts to manage it’s own change management program. It’s unreasonable to expect the same team to perform their day job whilst simultaneously managing a complex change process.
I think the main thing is to be pragmatic. There are no guarantees of success, and a degree of failure and back-tracking is inevitable. It’s very easy to get lost. If we keep the aims foremost in mind, we have less risk of implementing a methodology for methodologies’ sake.
For more, see Steve’s talk at Devoxx UK 2017: