There are 50+ different agile frameworks of varying popularity and many questions about them. Some common questions include: What are the frameworks? Where’d they come from? Which one is best?
Which framework should I use?
Answer: None of them or all of them.
Agile frameworks all seek to define a processes behind delivery of something. They seek to bring order to disorder. They offer varying degrees of insight and contingencies. And in many cases, agile frameworks introduce a lot of extra cost & waste.
The Problem with Agile Frameworks
The problem with pursuing a one-size-fits-all approach to using a define agile framework is complex, but it can be distilled to two main points…
Implementing a pre-packaged or defined framework will not expose organizational or process issues. It will AMPLIFY them.
Don’t get stuck trying to fit a square peg into a round hole. An organization and its teams are unique. It is important to utilize an agile methodology or framework that is both a “best-fit” and scalable.
Agile frameworks have, in many cases, veered so far from the core tenants of agile delivery — that they’ve become anti-agile. In many cases, work is done, but potentially not shippable… handed off… reviewed. Cycles are spent… new sub-teams are created. Process oriented meetings occur… and so on.
Does it make sense for a small software startup to use the same agile practices as Toyota? — No.
Should a highly effective organization go through an agile transformation to a framework like SAFe, just to introduce contingencies such as “release trains” — Absolutely not
I am not saying that all frameworks get it wrong. In fact, some of the frameworks excel in their scaleability! Again, frameworks define a processes behind delivery and seek to bring order to disorder. Frameworks are necessary.
The issue is the starting point… the way of selecting & using the right framework. A “silver bullet” framework does not exist. And, what works for one does not work for all. So, in selecting a framework, it is imperative to fully understand what it means to be “agile”.
Being agile does not mean playing fast & loose. Being agile means focusing on delivering value; even if that means making adjustments. A framework can help facilitate delivery & define the related processes.
The main guiding principles of the “Agile Manifesto” are:
- “Individuals and interactions over processes and tools” - “Working software over comprehensive documentation” - “Customer collaboration over contract negotiation” - “Responding to change over following a plan”
Using a Pre-packaged Framework… or not.
Using the wrong agile framework can be detrimental to success. It is important to consider the following:
Will the framework help the organization & teams adhere to the meaning of agile?
Does the framework help promote, or offer outlets for, the analysis of team performance?
Is the cost of implementation/overhead of a given framework feasible or worth it at this time?
Will the scalability of the framework positively affect organization or teams over time?
If you answered no to any of the questions above, then you have two options.
Shop around. If you are intent on using a pre-packaged or pre-defined agile framework, there are plenty to chose from. There are also plenty of accompanying training courses & “certifications” available to take your money.
Build your own. Why not build your own framework? It could be a small framework, or a large/complex one. It could be totally original, or use parts of other frameworks which make it “best-fit” your organization or teams!