Agile frameworks, such as Scrum, Lean, and Kanban, are both easy and difficult to implement. They require a deep understanding of the principles that govern them. Some people tweak these beautifully designed frameworks to come up with fancy ones to serve their environments. These tweaked frameworks then become marketing gimmicks for some companies and consultants.
I believe that developing these tweaked frameworks doesn’t serve their purpose; rather, the tweaking creates confusion among framework adopters. Existing Agile frameworks (Scrum, Kanban, Lean, etc.) themselves are lightweight and well structured, such that any modification or customization kills agility and deviates (perhaps) from the Agile Manifesto.
Some of the reasons for customization might include:
- Agile is treated as a process rather than a culture. I market "Agile as a Culture (AaaC)."
- Leadership teams are not on a journey to agility. They still want to manage projects in traditional ways. Shu-Ha-Ri stages or Management 2.0 is missing.
- Instead of embracing the change, we try to retrofit the old way of working into the new or modified way, thereby causing even more confusion.
- You can liken the tweaked framework to the Student Syndrome (see my article "Avoiding Student Syndrome in Sprints").
- The product owner and business are not educated enough, thus putting extra effort into forming value stream mappings and forming value streams (project teams/feature teams). They are not developing vertical slices of user stories, and they're missing the mark on the release planning. Hence, they want to see a place for their inter-sprint Waterfall.
- Extreme programming (XP) practices are ignored in the Agile journey, when in fact XP should be regarded with the utmost respect. Whether you follow Scrum, Kanban, or Lean, or you're scaling using the Scaled Agile Framework or Disciplined Agile Delivery, "cycle time with quality" is key. XP must be ingrained into the culture. It can’t be retrofitted in the project execution.
- Decision making has not been decentralized yet, hence the guidelines and rules are laid out in different ways by means of frameworks. With these additional rules, teams forget to innovate, seek faster feedback, and fail to retrospect in the right direction.
- Everyone wants to see their space in the framework (i.e., they want to save their jobs, not move away from their comfort zones).
- Fierce competition among IT companies (due to project bidding processes and a strong drive to win projects at any cost) kills the true spirit of the Agile implementation. Think of customers’ needs to understand the Agile principles, and be flexible in awarding projects to IT vendors for whom Agile is their culture, not a process.
Agile teams and customers will negate the need for custom frameworks if they:
- Work in a positive way, without looking for immediate wins in the Agile journey.
- Spend time together to understand the Agile principles in the true spirit.
- Implement in the right direction.
- Inspect and adapt as frequently as possible.