The problem with stuff like sprints and agile is that you - the organization - need to understand why they are useful. If you don't then it is just cargo cultis

The problem with stuff like sprints and agile is that you - the organization - need to understand why they are useful. If you don't then it is just cargo cultism. There are some great, as in large, problems with software development, as a result of having multiple parts developed by different groups, or even by one person at different times. The parts have to work together. It is easy, and I have seen this happen in multi-million dollars companies (plural) for groups to go off, develop their parts and for the parts not to work together. Boom. A sprint is designed to ensure that detecting this failure happens early rather than late. Can you have a sprint that does not help this situation? Yes. And if you do then the sprint is just foofaraw. The other problem is that it is easy and somewhat natural to write 90% of the code. Which does nothing. 90% of the code is meaningless. What works is the issue. No one needs or wants code. They need or want functionality. I have written some really really cool code that does nothing. It was 90% of something, but unfortunately had to be rewritten in order to be functional. The second use of a sprint is to show functionality. A sprint to have 92% code completed is nothing. Can you show (to me or yourself) that 90% of the functionality is there? The difference between 90% of the backend API's being functional (and being able to prove it) and 90% of the backend code being written is monumental. There is a final use of sprints. As a manager you can appear to know what you are doing by organizing sprints, when in reality you have no clue whatsoever as to what you are doing. If you want to be a good programmer, you will use sprints with yourself. I'm a sole developer and when I use sprints by myself I am much more productive. Much. [updated for spelling and clarity]