In a series of blog posts I am discussing the question: What went wrong with Agile? If you have not read the introduction blog post already (What went wrong with Agile?) I suggest you go there first before continuing reading here.
When I started applying Agile methodologies in 2006 there was one dominant framework. It was Scrum and to be honest, in the beginning I thought that Agile was Scrum and Scrum was Agile. How wrong I was. Back then there was a dominant saying: “Scrum is simple but hard to do.” I think they were right. But raising questions about how to ease the hard parts, the answer seemed to be variations of: “Do it by the book! Repeat it over and over again until you get it right, because if you do not follow the Scrum Guide to the letter, you are not doing Scrum, you are doing Scrum-but!”
I was really struggling with this, because at that point in time I, with a number of great peers, were trying to implement Scrum in full stack development of various audio products – just like Nonaka and Takeuchi suggested (we just did not know their work at that point in time). It was really hard for us to have a potential releasable guitar pedal, bass amplifier or computer recording interface each third week. We had to go Scrum-but. We succeeded in making a turnaround of the company and many jobs were saved. From then on I did not care where either doing Scrum-but or not, as long as it makes sense and works.
My learnings from this was not to ignore frameworks and thinking that anything goes. Absolutely not! It was rather that frameworks can give you guidance. However, the ones who have defined the framework, do not know everything (even though some of them almost claim to). They especially do not know the details of your context – only you and your peers do – so therefore you must adapt, and sometimes that even means bending or breaking the rules of the framework. “Individuals and interaction over processes and tools” as the first value in the Agile Manifesto states.
Over time various Agile frameworks have been introduced. Most of them are related to when the work goes beyond one team: LeSS, Nexus, Scrum @ Scale, SAFe and the latest unFIX. Some have even been convinced that there was something called the Spotify model. There is not.
Marketing-wise SAFe has been the most successful, but when it comes to providing results, I have not seen any proof that one of them is particularly better or worse than the others. I am not particularly in favour or against any of them either.
There has been a tendency that especially SAFe has been a subject for do-it-by-the-book implementations where all roles, artefacts and events have been blindly implemented according to some manual. I am not sure this was the initial intention with SAFe, so why did it come to that?
Well, some consultancy companies sell Agile off the shelf, following the illusion that transforming an organisation into agile can be done according to a predictable plan. Their customers like that idea, because it gives them a sense of control. To do the implementation, they follow an approach with clear deliveries, and they invoice according to that. They are ironically enough using a waterfall approach to implement Agile, based on output rather than outcome.
Implementing Agile is nothing you can outsource to somebody else. It is something that you must own yourself. Why? Because to have a lasting change, things must make sense to people, those doing the work and those leading the change initiative. For the latter, their understanding of organisational dynamics and culture is essential for success. See one of my previous blog posts for a discussion about this.
Besides being owned by yourself, your agile implementation must also be done according to your context. It must be a balance between challenging your context and adapting to it. There is no blueprint you can follow. You must find the way yourself. You can of course be guided by consultants who have extensive experience with the process of transforming organisations, but stay away from those who with enormous confidence state that they know exactly what to do. Look instead for those who have a skillset that is larger than their ego – those that know that a job like this must first of all be addressed through humbleness.
In my coming blog post I will address another agile mishap which is related to today’s topic: All frameworks are wrong but mine. In that we will address the growing numbers of frameworks, the reasons why so many appear and are they actually relevant. Stay tuned and remember also to subscribe to our newsletter for a monthly goodybag of agile inspiration.