I have sometimes described my ideal development process as scrummerfall. I use it as a rebuttal when a developer or team that I’m working with says that something isn’t Agile. I don’t care about Agile except as a mechanism to more effectively deliver awesome products for our customers. If there is a problem that is best solved by something other than Agile best practices then I will prefer we deviate to solve the problem in front of us. Since there are no scrummerfall advocates or evangelists nobody cares about doing it the scrummerfall way. That freedom is powerful to avoid ending up in a cargo cult scenario where we do things because that’s the way it’s been done in other companies.

Waterfall

I don’t advocate for waterfall development. Waterfall development is categorized by doing all of the requirement gathering up front, then all of the design, then all of the code, then all of the testing. It’s dangerous because it pushes a lot of uncertainty and risk to the end of the project. If you miss an integration impedance mismatch then you don’t find out until you are in the coding phase. If you find a critical bug in testing you may have to rework a large section of code.

However, I do advocate for doing light up-front requirement gathering. Talk to your customers. Have a clear hypothesis about what features are required to hit your business goals. Vet these assumptions with real customers. It will make your delivery and outcomes much more predictable, and having one person doing true due-diligence on the feature before investing a full feature team means that you avoid burning money paying an entire team to do experimental work. I compare it to making a movie. You can spend years writing a script and doing story-boarding to sketch out what the final movie will look like. It’s enough to be willing to place a multi-million dollar bet. And you can do it with a small team of writers and artists. Once you decide that you understand the movie that you are going to create then you start shooting. That’s when you start burning money. You have to pay actors, camera operators, locations, etc. If you realize that you are shooting the wrong movie it’s going to be expensive to figure it out with the entire cast on-scene.

We will never have a perfect plan. I don’t ask teams to understand every line of code that will be written before moving into implementation. It’s too expensive. Finding the right amount of planning to eliminate the major sources of risk is an art and skill that you should develop with your technical leads. Once you have enough confidence that you can deliver what customers want in a reasonable time frame then start working in a traditional scrum fashion. Build out the core of the feature first. Eliminate areas of high risk. Do testing in parallel with coding. Deliver to production behind feature flags from day one.

But don’t be afraid to understand the requirements, technical design, and implementation plan before writing a line of code. A good plan for a quarter-length project is worth the time and effort.