I mean it – your methodology does think you’re dumb. It doesn’t trust you, doesn’t believe that you can think for yourself, and doesn’t want you to inspect and adapt based on your current circumstances.
A methodology is a prescribed series of steps that must be completed to encourage the successful completion of a goal. Think of a methodology as a recipe that is to be followed based on certain circumstances without exception. While this definition is innocuous at face value, its impact is far more nefarious when applied to product development. A methodology assumes that it can boil down all of the volatility, complexity, uncertainty, and ambiguity associated with product development in the 21st century to a simple set of repeatable steps, documents, and meetings.
A methodology also assumes that you will do as it tells you to do. How many times have you heard the following statement, ͞I followed the methodology. We need to improve it. It failed, I didn’t.͟ Following-through on this call-to-action leads to extending the methodology to become larger and more intense. Documents, roles, sign-offs, phases, meetings, and hierarchies are added in the hopes of addressing the endless scenarios that emerge when developing a product in a complex world. The burden of these additions is born by the next person or team to use the methodology. And the process of adding to it every time it fails, in an attempt to address that failure, repeats until the methodology becomes so bloated that no work moves through it or the organization.With the methodology clogging the flow of work, an organizational ͞heart attack͟ and the death of any value that the organization created is certain.
A framework is different. A framework defines the boundaries of the game to be pursued by a person or a team. It is minimalist and gives you the freedom to determine the correct moves to make based on the particular instance of the game that you are playing. Consider the game of Chess. Chess provides a set of rules that define it. For example, a Bishop can only move diagonally. How an individual player applies this rule to the game that he or she is playing depends on the skill of the player, his or her objective and the corresponding moves that his or her opponent is making.
Most importantly, a framework, like Scrum, trusts you to make the best decisions for you based on your unique circumstances. Under a framework, there are no best practices. There are only practices that worked in my instance of the game and that may assist you in your instance of the game, but only if you believe that they will assist you do you use them.
Your methodology thinks you’re dumb, why not consider trusting yourself and the smart people with whom you work and try a framework like Scrum?