Art of Organizational Refactoring
I am doing some thinking about what it takes to implement Scrum in an organization that is not used to or even familiar with agile concepts, let alone Scrum. When you start a new team or a new company implementing new methodology is rather easy – you select people based on what you believe the required roles and functions are, there is no legacy to overcome and everybody is open to whatever process you are installing. There is no inertia, there is no resistance and there is no conflicting interests you need to account for.
Of course the exact opposite is true when you are attempting to implement Scrum (or whatever else) in an organization with strong waterfall culture. It’s not just about telling people about how in Scrum you do so and so, go to this meetings, here is how product backlog should look like – and then you are done. It is much more challenging because of “that’s not how we are used to do things around here” – so not only you have to be able to teach what Scrum is, but also be able to overcome years of practise of doing something else.
And that is not the hardest part. It is impossible to make all the changes overnight – this stuff takes a long time to get absorbed and interned and used to. So there is going to be some time where organization is not going to be very “organized” for the lack of better word. And yet, there are customers and sales and support and contracts that need to be taken care of, and that cannot be “pushed back” until we can figure out how to do the Scrum stuff properly.
And this brings me to the concept of refactoring. In software engineering, refactoring is the art of taking an existing piece of software that maybe is using some old technology that is a bit obsolete by now, or maybe it is written in somewhat inefficient way and taking that piece of software and rewriting it in such a way that from the outside it keeps looking exactly the same, performs exactly the same function (but better) while inside it gets completely overhauled and made more efficient, with less bugs and easier to maintain. And I call it an art because yes there are some practices and tricks which help you do that refactoring, but in the end, every software is different and what might have worked on a previous project wouldn’t work on the next one, so to be able to do this and succeed requires some flexibility and creativity.
And I think similar art form should be developed for implementing Scrum in organizations that are currently stuck in the old ways. The similar challenges apply – keep the outside interface, support clients, make the sales, while in the same time transforming the entire organization to much more efficient, flexible and adaptive proceses. And yes, even though some techniques are probable shareable, in the end every organization is different and it will take each one a unique path on its road to agile success.