A friend of mine recently pointed me in the direction of a video by YouTuber No Boilerplate that argues that Scrum is not Agile and that developers should not estimate their work or plan their work out, and the only metric they should use is functioning software. While I agree with the idea that we should try to minimize distractions that take away from developers doing their work, I believe that the video’s creator is far too idealistic in their approach.
I recommend watching the video as I do think No Boilerplate makes some good points in it, but I have some significant problems with how idealistic the presentation is. The video argues that Scrum is not truly Agile because it is too focused on planning and estimation. According to the video, Agile is about being able to quickly adapt to changes and deliver working software without concern for failure, and Scrum gets in the way of this by requiring teams to estimate their work and plan out sprints. No Boilerplate vehemently argues that all of these things are not truly Agile as they get in the way of developers doing their work. What actually matters? Working software, argues No Boilerplate. Fair enough.
While I can see where No Boilerplate is coming from, I think it’s important to remember that “being Agile” doesn’t mean that you can’t plan or estimate your work. It’s about being able to adapt to changes and deliver value quickly, but that doesn’t mean that you can’t plan out your work and figure out how to do it ahead of when you’re actually doing it. In fact, having a plan and estimates can be crucial in ensuring that you’re able to deliver value quickly. Prioritization is part of planning, and that’s where you figure out what’s the most valuable thing to do next.
Additionally, No Boilerplate’s argument that the only metric that should be used is functioning software is problematic to say the least. While functioning software is obviously important, there are many other metrics that can be useful in ensuring that you’re delivering value. For example, if you’re building a product that needs to be scalable, you may need to focus on metrics like response time and server uptime in addition to functioning software. Ever heard of stakeholders? Working software is great, but the needs and expectations of “the customer” are a huge part of the equation that No Boilerplate neglects to address completely.
Furthermore, the video’s argument ignores the fact that some projects are simply too large to be created without planning and coordination between many different teams. For example, imagine trying to develop a large-scale enterprise application without any planning or coordination between different teams. It’s simply not feasible. In these cases, a framework like Scrum (or dare I say the big scary word SAFe?) can be incredibly helpful in enabling teams to have a good balance between agility and structured planning.
Of course, that’s not to say that Scrum or larger frameworks like SAFe are perfect. They both have their drawbacks and can be difficult to implement effectively. Obviously. But the idea that we should abandon all planning and estimation in favor of simply focusing on functioning software is simply unrealistic. To me, it’s just as naive as saying “we have more than enough resources, let’s solve world hunger.” Wonderful thought, until you actually have to get around to doing it. You’re never going to get there if you start by handing out Hungry Man meals to whoever you can find on the street. You need a plan.
To illustrate this point in a software environment, let’s imagine that you’re working on a project to build a new mobile banking application. While the goal of the project is to deliver a functioning mobile app, there are a lot of different pieces that need to come together in order to make that happen. For example, you may need to integrate with different payment processors, implement strong security measures, and ensure that the app is scalable to handle a large number of users.
If you were to simply focus on delivering functioning software without any planning or estimation, you would likely run into a lot of issues. For example, you might end up spending a lot of time trying to integrate with a payment processor that doesn’t meet your needs, or you might not realize until late in the development process that your security measures are inadequate. That’s a big problem when you’re dealing with a lot of honest people’s money because “it’s not a big deal to be wrong as you can just fix it later.”
You need to use a framework like SAFe or Scrum in this and many other real world cases. (Even waterfall would be better than the purist Agile mentioned in No Boilerplate’s video because of the high risk of failure inherent in that idealistic viewpoint.) With Agile frameworks like Scrum or SAFe, you could break down the project into smaller pieces and plan out each sprint to ensure that you’re making progress towards your goal. You could estimate the amount of time and effort that each piece will take, and adjust your plans as needed based on your progress. And most importantly of all, you’re not doing things all willy-nilly and hoping for the best.
While many of the criticisms made by No Boilerplate are good points and I happen to agree with many of them, Scrum or any other Agile framework are the better choice, by far, in most real world examples. You can have a plan and estimates to help guide your work, but you can also adapt to changes and deliver value quickly in the spirit of the Agile Manifesto. It’s all about finding the right balance for the project, the stakeholders and the organization involved. There’s no “one size fits all” approach to solving these problems, and that’s why multiple Agile frameworks have been developed over the years.
In the spirit of not being overly critical of No Boilerplate’s video, I do agree with the message presented that we should try to minimize distractions that take away from developers doing their work. The points made do fall flat in real world scenarios, but that’s not to say that everything No Boilerplate said is invalid.
The most valid thing I am taking away from this video (especially after reading through its comment section) is that there really is a lot of waste that we introduce in the work cycle of developers. Excessive meetings are the big offenders that I as a Scrum Master can help deflect, and I’m going to be even more vigilant in the future to ensure that waste is not introduced into the schedules of developers whenever I can.
Maybe I’ll schedule a series of ART-level meetings this week about how we can best avoid scheduling unnecessary meetings in the future.
