It is fair to say that Agile is an extremely fragmented community. An Agile practitioner is often confused about which “camp” I should pitch my tent.

For example, if I like Scrum, should be aligned with the Scrum Alliance or Ken Schwaber’s
Is Scaled Agile good or Large Scale Scrum for scaling Scrum to large project environments?
Are Lean/Kanban really Agile methods? When should I use these?

What about Extreme Programming, DSDM, Crystal, FDD, AUP, APM and about half dozen other methods which are being mentioned in different communities?

The truth of the matter is (and I think the proponents of all the methods mentioned above would agree) that the methodology has to be tailored to what your project and your organization needs. There is no silver bullet, so let us start looking inwards for solutions rather than outwards.

That said, here are some guidelines that I have discovered over 12 years of practising Agile in real world projects (both large scale and small) – in different industries, product development as well as services.
1. Scrum is probably the most popular framework out there and disarmingly simple to start with. However, it will quickly lead you to a blind alley and require you to search for answers to other questions like “how to I make my product near releasable every Sprint”?

2. Scrum has to be supplemented with highly automated and efficient software engineering practices like Test-Driven-Development and Continuous Integration. The best guidance for these and other methods comes from Extreme Programming.

3. DSDM offers some simple but powerful ideas that might help you plan releases (I can imagine some Scrum purists frowning at the term “release”, but most teams that I know do releases). For example DSDM fixes time and cost up-front and requires Scope to be variable, and applies MoSCoW prioritization effectively.

4. FDD is extremely good for scaling to large teams where multiple feature teams work in parallel to enhance a complex, enterprise product. Scrum coupled with FDD is probably much more meaningful than other complex methods that give a lot of jargon but little else.

5. Crystal provides wonderful guidelines about Osmotic communication and enhancing collaboration, the lack of which can hold up progress of a team. Read up on Crystal if communication is a problem for you, and you want to get ideas about designing an Agile work space.

6. None of the Agile methods will work well if more than 30% of the work in your project is of a routine nature and hard to predict (e.g. enhancement, maintenance and support). Lean and Kanban methods are better suited for this environment.

7. If you have highly evolved DevOps practices that allow you to deploy in real time, you probably do not need any Agile method at all. A simple Kanban based work management system will be sufficient.

I know some of these opinions may be contentious and subject to interpretation. But don’t take my word for it. Do your own research and experimentation and find out what works best for you.
In other words, stop pretending that you have become a “master” of any sort just by attending a 2 day course and parading a certification.

True agility is a journey. In all humility, I am still learning it myself. Get in touch if you want to become a fellow traveller on this journey. Intellectual stimulation and curious questioning is the only thing that I can guarantee, though. The solutions to your problems – is probably already inside your brain somewhere.