The Good, Bad, and Ugly of the Popular Agile Frameworks

If I were to ever write an article that would prompt an argument online, this is the one. There is so much noise and hand-wringing about the one true agile framework that it is impossible to make sense of things. Sadly that puts our community in a position where it looks like we’re more interested in seeing everyone lose than helping anyone succeed. It also puts leaders in a terrible position of having to wade through the online sludge of before trying to make a choice. So, with that, I am going to give my short, no-nonsense guide to Scrum, Kanban, and SAFe.

Scrum

Scrum, or at least something like it, is ubiquitous now. It’s simplicity allows for quick adoption, and the industry has created hundreds of thousands of Scrum Masters that are eager to prove themselves.

Now, Scrum is a great framework in that it is quick to adopt and can often help with many issues that organizations face. If you’re struggling with inter-team communication and adapting plans, Scrum is a good choice.

Having said that, Scrum is very incomplete. It doesn’t tell you how to do many of the things that teams and companies need to figure out. It assumes you and your peers will figure that stuff out. In practiced hands, this freedom is a good thing. In the hands of the inexperienced, Scrum will turn into the same results with more meetings.

When do I recommend Scrum? Anytime I need to help teams improve rapidly and have a bigger impact on a product. When do I not recommend Scrum? When the work is very recipe oriented and known.

Kanban

While not strictly a framework, it gets lumped in enough that I might as well address it here. Kanban is really about taking your work process, visualizing it, and figuring out how to move things through it better.

Similar to Scrum, it has very little to say on how to make things move better and relies on you and your teams to figure that out. It assumes that if you visualize things well enough, the right conversations will happen.

And they will.

Kanban is great when you have work that can be shaped similarly or operationalized similarly. It also works well, oddly enough, for truly abstract work.

I tend to use Kanban with groups that need to rapidly fix process-oriented problems, and with leadership teams who need to visualize initiatives across their organization.

If you want to use Kanban, resolve yourself to becoming data-oriented in how your teams behave. Once you visualize the work it will be impossible to ignore what it screams at you. When you do Kanban well, it will seem backwards and unintuitive to what most people understand as effective or efficient, but the results will speak for themselves.

SAFe

Any organization that has more than a dozen teams feels a pressure to have a unified method of how things get done. While I’d say this is a dangerous belief to act on, SAFe markets it self perfectly for this case.

SAFe exists to help organizations coordinate across any number of groups and teams.

The way it accomplishes this is by taking Scrum and then adding larger and larger cycles to more and more people higher and higher up in the organization. So where a single team may have planning and review, in SAFe you have teams doing that, release trains doing that, and organizations doing that.

SAFe has a lot of process that comes with it and if you’re willing to go all in on it, including new roles, positions, meetings, etc. it might help you with complex products that are built by many component teams that otherwise do not talk.

Having said that, I don’t typically recommend SAFe to anyone. It’s too much for too little. It’s promise to unify everything, once fulfilled, often leaves a lot to desire in terms of effectiveness.

Now, why do I take a position that one unified method is a mistake? Well, consider a support team and an R&D team. They both exist in a software lifecycle, but have unique problems and needs. Cramming them both through the same grinder doesn’t make sense.

Conclusion

If you can’t tell, I don’t swear by any one framework. They all have a place in the right situation. Even SAFe.

Now, if you’re a leader what I recommend is that you start small with a few teams to try something. Pay attention to where what you’re trying rubs against the way the rest of the organization works. Project plans are going to be one of these. Look at this as a border between the new and the old. Instead of trying to break one side to fit the other, find a way to translate from one to the other.

Grow from here. What you’ll find, is that these border problems are where people struggle. This isn’t a framework problem though, it is a communication one. So find a way to improve that communication on the border.