In my opinion, agile methodologies are not black and white; you can choose to incrementally adopt parts of scrum, or choose parts of scrum that benefit your team the most while leaving everything else the same, if it works well. Each team, and each development environment, is different.
The point of process isn't in mindlessly following the process, it's a guide to improve the underlying work. Ideally, you can wake up one day, decide "no more scrum", and hopefully, if the process you've been following wasn't a facade, you'd continue to keep doing more or less the same thing if it actually works.
I don't strictly follow any one agile methodology but I agree with the points OP mentioned in his article. Two of the most useful things I've taken from scrum is: a definition of ready, and, braking up large tasks into "1 day" tasks.
Establishing a definition of ready is a huge success when it comes to communication. It allows you to actually establish what you need to do to deliver value, and facilitates breaking up the task, if needed. I've been on the wrong end of tasks that kept seeing scope creep, and kept getting stalled because after each hour of work we'd reach a point where we needed more clarification.
I also saw great benefit in breaking up large tasks. This allowed for more accurate estimates and working on features in parallel. One thing I learned is that you shouldn't break up a large task arbitrarily. Pick logical "seams" in the task, so that each unit of it still delivers value.
Very well put. I couldn't agree more!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.