It is often said: You can’t blame a methodology for not being used properly. Well, yes you can. Consider the fact that everybody’s intention when using one is to succeed. Nobody wants to fail in delivering a software product. The promise of any methodology, even any waterfall methodology, is to deliver value sooner or later. Any failure starts with a choice of using one or multiple of these methodologies and buying into their promise.

Some say, one should have enough knowledge to apply a certain methodology. If not, one is responsible for the failure and not the methodology itself. This does sound tempting until you consider the fact that people who preach this are paid a lot to explain others how to properly apply the methodology. Nevertheless, even after applying methodology according to every recommendation, failure is still there. Ironically, very often because of huge effort being put into doing methodology in a proper way at cost of delivering actual value as soon as possible.

Some say, software development is like manufacturing. Therefore we have all kinds of Software Development Factories. Software developers are factory workers with limited focus and knowledge and therefore need a process, which will guide them towards delivering a product. I guess anyone who does software development in today’s complex world has found out that treating software developers as factory workers constrained by a strict process is a recipe for failure. Besides, it would be more realistic to consider software development same as trying to land a jet fighter on aircraft carrier for the first time than a factory.

It is the fault of a methodology when people use less creativity and less improvisation to deliver value, because methodology discourages them to deviate from rules. It is the fault of a methodology when people are only concerned about their always limited set of tasks and responsibilities assigned to their role.

Some might say, no methodology says we should be restricted in any of these aspects. True! Still, mere existence of a methodology introduces certain limitations by definition. Bigger, more complex methodologies tend to be more limiting than simple ones. Even if everything described in a methodology is called only a practice; and each of the practices can be used but can be skipped too. When used, people will call these practices: the best practices. Who can argue the usage of a best practice? People are discouraged in adjusting the process. Not because it is not allowed, but because of the assumption that they are less capable of setting up a process in their situation than people who spent a lot of time and effort in creating this great methodology.

Does this mean we should not have methodologies in software development? No, it does not. Certain guidance is always needed, and we definitely need ever improving and new practices. But, there is a difference between having rules defined by people who use, change, improve these rules; and imposing these rules on people. There is a difference between having a methodology as a mean to help people deliver more value and hiring people according to roles defined by a methodology.

Every methodology or framework has this problem. Even XP, Scrum or Kanban. The most important reason why these are so much simpler than others is to encourage people to think and be more creative in every possible way. In fact, there is so little really described or prescribed in these that for successful teams methodology is just a detail, a sideshow. Doing scientific research on how successful Agile methodologies are proves to be very difficult. Why? It is same as trying to determine wether Mandarin is successful language in doing business. To have a common language is crucial when doing business, but rather irrelevant detail in the whole process. This is different for large methodologies, where methodology itself is an important factor. Agile brings us more success not because of better methodologies, but rather because we have less methodology.

Still, many organisations are imposing Scrum on people in same way as they did with previous methodologies. Suddenly, many of often used practices have become the only way to do e.g. Scrum and XP properly. User stories, poker planning, TDD, specific meetings, burndown chart, Scrum of Scrums, pair programming. It gets much worse when extended by DAD or SAFe. LinkedIn forums are full of discussions about which of these are better or how to use them properly.

Don’t get me wrong. I give trainings and coach teams in these practices because they are so great. Nevertheless, if we keep giving methodologies the front seat at cost of people, we will keep blaming methodologies for failures. There is a huge difference between giving a “why” behind each practice and simply explaining how it should be applied properly. A team can only become Agile if team members understand “why” behind every practice they use.

So, the next time you say “Scrum has failed in our organisation!”, ask yourself what exactly did you or did your organisation do. What or rather who is to blame?