Will it work with…?
Since a while back, I have a new assignment: introducing agile methodology in a major organization. I’ve also recently been in contact with other organizations, interested in replacing their current methods with agile. Now, these aforementioned organizations do not have that much in common, but they all voice concerns about making the transition to agile: ”will it work?” is an obvious question, while another – but just as common – is the extension ”will it work with our existing methods, roles and processes?”
Now, I find the latter question more interesting, because somewhere in there is a bigger issue. It indicates a conservative desire to keep everything as it is, while benefitting from the new. Perhaps that is human nature. But more serious is that it, when probing with follow-up questions, indicates an organization where several such method initiatives have come and gone over the years. Each such initiative have been preceeded by discussions on effectiveness, communication, structure, tools, etc. From many co-workers point-of-view, there is no difference between ”introducing RUP” or ”introducing agile”. It is just another one of a long line of changes supposed to improve their process, driven by consultants (such as me), after a while being replaced by another intiative when the results did not live up to the hype.
The question ”will it work with…” thus also implies, that the employees have to live with a large flora of more or less related methods, roles and processes, sometimes being forced to perform tasks that belongs to a role long since obsolete. They still do them, because they always have done them, or sometimes, put bluntly, it might be a bit unclear as to what their current role actually are supposed to do.
You might by now see where this is going, but here it is spelled out: there is no point in blaming your existing methodology for its supposed short-comings, when you are actually not doing what the methodology tells you to. The same is true for agile. You could with some effort apply Scrum, do it by the book, and still not be very happy with the result. You could with much more effort apply SAFe – or some other agile scaling framework – after which you would throw your hands up in frustration since nothing has improved. The only thing you achieved was more confusion.
Inspect and adapt
Here is the catch: you do not ”apply” agile. You are agile. There is no agile ”method”. You inspect and adapt. And this is the difference between ”introducing agile” and all those other, previous initiatives: agile is all about attitude and mentality, and really very little (or nothing) about a preset number of documents and rituals.
Since nothing is a very tough starting point, there are a number of methods or frameworks that previously have proven to be successful that you can start off with. But they are not intended to be used as-is, and they are certainly not intended to be the ultimate agile goal. ”Introducing agile” is thus, in itself, a large exercise in inspect and adapt.
When done correctly, the people in the organization will start to think agile, which in turn might lead to it actually making the necessary changes in order to achieve the desired effects. By inspecting and adapting, we can make agile working with just about any other method (if truly necessary, otherwise our agility allows us to remove the obsolete obstacles).
Now, the road to agile is not easy. It requires quite a lot of work, inspiration, education and perseverance. I know a consultant that might help you with that. 🙂