I started programming around the time people published the Agile Manifesto. My manager at the time handed me the first edition of Extreme Programming Explained. I was also lucky to work in an environment where I could see the first hand problems agile set out to solve.
Fast forward many years later and agile is “mainstream.” Others defined new agile methods. I want to use this article to capture my understanding and share my opinion about these methods. This means you may not like what you read. Consider this your warning. 🙂
The original agile methodologies
Scrum
Scrum is today, sadly, synonymous with Agile. Founded by Ken Schwaber (now with Scrum.org) and Jeff Sutherland (now with Scrum Inc). I see this agile methodology as an improved project management process. It brings rhythm and synchronises people all working towards the same goal. I like how Scrum provides a simple starting framework that builds trust through incremental delivery. Plan a bit, deliver a bit, inspect and adapt.
What I don’t like about Scrum is the cult-like behaviour driven by commercialisation. Subscription “certification” for sitting in a class for 2 days anyone? Like all typical corporates, the Scrum Alliance has expanded to offer ~10 certifications. NOTE: Scrum certifications do not (for me) equate to competence or experience
My usefulness rating: 7 out of 10
Extreme Programming (XP)
I’m definitely biased because I started off with this methodology. Invented by Kent Beck, XP builds on Scrum practices and adds in technical practices. Even these technical practices bring value without necessarily following XP. Examples include Continuous Integration, Pair Programming, Refactoring, and Automated Testing including TDD.
I like how XP highlights technical practices that make agile software development work.
My usefulness rating: 9 out of 10
Feature Driven Development (FDD)
In my experience, FDD is not heavily used in the industry. It’s iterative, focuses on domain modelling and used dynamic teams to create features. I like how there is an explicit design phase for features and a focus on unit testing.
In opposition to XP, FDD encourages individual class/feature ownership. I feel this trades-off consistency within a feature against consistency in the application. I used FDD as an inspiration for delegating to Feature Leads.
My usefulness rating: 6 out of 10
Adaptive Software Development (ASD)
ASD stems out of the Rapid Application Development (RAD) methodology. It grew from the work of Jim Highsmith and Sam Bayer. This methodology is super simple. Small cycles of Speculate, Colloborate and Learn.
ASD is not prescriptive with its practices, instead providing guidelines. I like how it highlights Mission, Vision, Leadership and People. This will specifically appeal for those in management roles. It was one of the first books to recognise software as complex adaptive systems.
My usefulness rating: 6 out of 10
Dynamic Systems Development Method (DSDM)
I have never experienced this methodology in the wild. I see DSDM as another project management framework fitting with the spirit of agile. I like the emphasis on modelling and the invention of MoSCow (Must Have, Should Have, Could Have).
I like less that it’s “owned” by a consortium, which limited its adoption to mostly the UK.
My usefulness rating: 3 out of 10
Crystal
Crystal is a meta-methodology. Alistair Cockburn, who thinks deeply about the process of building software, invented Crystal. Crystal is the methodology to help define a specific methodology. Cockburn describes a process to “tune” a methodology to fit its context. Cockburn created specific methods (e.g. Crystal Clear) for different contexts. Some cater to larger groups. Others consider the domain characteristics (e.g. safety or life critical)
Like other agile methodologies, Crystal focuses on collaboration and communication. In his book, I liked how Cockburn described osmotic communication. It was also one of the first methodologies I read that focused on personal safety. Google’s research demonstrated how important psychological safety is for high performing teams.
My usefulness rating: 6 out of 10 (It would rate higher but I scored it less because it’s a meta-methodology)
Second-wave agile methodologies
I refer to the following as second-wave methodologies. They emerged as more people connected with the agile values and community.
Lean Software Development (LSD)
The Poppendiecks created LSD by importing lean manufacturing ideas into software development. LSD focuses more on principles and, to me, feels less concrete compared to other agile methods. I really liked the ideas of value stream mapping and trying to follow and reduce waste.
I was never able to reconcile one mental model. Product discovery is naturally exploratory in nature. Except if you are digitising a manual process. As a result, there is some natural waste in the system that you can’t get away from.
My usefulness rating: 7 out of 10
Kanban
David Anderson created the official “Kanban Method”. He took the Theory of Constraints and applied it to the flow of software development. This method is simple and is a super useful Getting-Things-Done (GTD) technique. I’ve heard of weddings and house moves planned with Kanban boards. I’ve even used one myself for Christmas meal planning.
The method is easy to get started and immediately practical
My usefulness rating: 8 out of 10
Scrumban
Loosely attributed to the evolution of teams as they move from rigid Scrum to Kanban.
My usefulness rating: 7 out of 10
Scaled agile methods
As agile went mainstream, large organisations wanted to “adopt agile at scale.” The result is a plethora of methods that cater for the “enterprise.” I have yet to experience any of these successfully work at creating a truly agile organisation. Many of these feel like rebranding existing dysfunctions as “acceptable agile.”
Scaled Agile Framework (SAFe)
Many leading agilists have written enough about SAFe for you to make up your own mind. I have witnessed a poor enterprise choose to go down the SAFe path. They found it didn’t help them solve many issues. I feel SAFe allows mediocrity. I find it doesn’t put enough emphasis on the continuous improvement. Nor does it emphasise a shift of values (e.g. “People over process”).
I do like that it touches upon topics such as Portfolio Management and Architecture. I don’t think that makes SAFe agile.
My usefulness rating: 2 out of 10
Large Scale Scrum (LeSS)
I know Bas Vodde personally from the retrospective community and I have a lot of respect for him. Bas Vodee and Craig Larman (creators of LeSS) also wrote a book about Scaling Lean & Agile Development. The book acts as a case study from their experiences.
I haven’t personally experienced LeSS. I feel that LeSS is more in the spirit of agile than SAFe. It is a starting framework (the authors say it themselves) about how you might apply Scrum to very large groups. LeSS focuses on 1-8 teams and LeSS Huge focuses on 8+ teams. This is a simple starting framework that organisations might use as a starting point.
I find the LeSS website rather confusing to navigate.
My usefulness rating: 7 out of 10
Scrum@Scale
One of the founders of Scrum (Jeff Sutherland) first published the guide for Scrum@Scale. The guide is free, simple and very Scrum focused. Scrum@Scale doesn’t simply target agile software development, so is very process focused. It doesn’t mention any technical practices that are also needed at scale.
It feels like it tries to keep the agile spirit, by being lightweight, simple and iterative. Scrum@Scale introduces more complex terminology (e.g. Executive Action Team, Executive MetaScrum). I can see how this might help large projects involving lots of people.
My usefulness rating: 5 out of 10
Nexus
Nexus is Scrum.org’s answer to scaling Scrum. Ken Schwaber (the other Scrum founder) defined Nexus. Nexus attempts to create more alignment via its Nexus Integration Team. Nexus also applies many Scrum practices to this central group. Examples include the Nexus Daily Scrum, Nexus Sprint Planning & Review and the Nexus Retrospective.
I like how Nexus reuses many of the Scrum concepts to try to provide consistency with its scaling method. It feels lightweight enough. Nexus aligns with core agile ideas. It focuses on transparency, iterating and the constant flow of value.
I don’t like how Nexus (like Scrum) fails to include any technical practices.
My usefulness rating: 6 out of 10
Disciplined Agile Delivery (DAD)
The people behind the, IMHO complicated, Rational Unified Process did it again. They invented Disciplined Agile Delivery. DAD appears to define a solution for the entire organisation. This choice adds a lot of complexity to try to address everything.
DAD feels less prescriptive than other scaled methods. It still feels to me overly complex. DAD prescribes no single lifecycle for synchronisation. They even map how other practices map to different lifecycles in their view.
Trying to do too much without being prescriptive? A good starting point but its complexity makes it less accessible.
My usefulness rating: 5 out of 10
Back to basics
Agile started with a simple set of values and principles. Second-wave methodologies connected ideas from other fields to name new practices. When agile crossed the chasm, people tried to “scale” agile and it got excessively complex. Many of these, IMHO, feel like snake-oil. Many focused on selling consulting or training instead of delivering value early. It’s only natural that early agile practitioners tried to bring agile’s core back.
Modern Agile
Joshua Kerievsky invented Modern Agile. The ideas refocus people’s attention away from complex methods. Instead of practices, Modern Agile focuses on four simple principles. It encourages people to be agile instead of simply doing agile. I have a lot of respect for Kerievsky. He is an ideal role model in the agile community. He applies agile values and principles to his company, Industrial Logic. He is also super generous in sharing his knowledge and lessons learned with everyone.
I like how Modern Agile is so simple. I like how accessible they make it and how they’ve built up a strong community that shares generously. The Modern Agile community shows where to start and how to continuously improve.
My usefulness rating: 7 out of 10
Heart of Agile
Alistair Cockburn started the Heart of Agile to, once again, focus on principles. I feel this emerged as a result of of “scaling agile” and including “all the practices.”
I like how the Heart of Agile is a simple set of principles that guides people to think with an agile mindset. It reminds me of the Deming Plan, Do, Check, Act/Adjust (PDCA) cycle of continuous improvement.
My usefulness rating: 7 out of 10
Conclusion
I am amazed at the emergence of new “agile methodologies.” From a positive note, it demonstrates how wide agile has reached. It also demonstrates how the Agile Manifesto did such an effective job. A simple set of statements brought a worldwide community together. It provided an umbrella for people to share ideas, knowledge and practices. Agile catalysed improvements in the state of software development.
This list is my attempt to better understand some of the newer methods. I admit this list will never be complete. It also reflects my own, limited and biased views of the methods above. YMMV.
I wanted to provide a simple overview of what’s out there (as of this writing). I challenge you, the reader, to start small and iterate. In the true agile spirit, pick something that adds immediate value. Improve your situation and continually inspect and adapt. It will never be perfect but you can continuously improve.
