A blasphemous question?

My question is, what if you don't have the complexity in your projects?  For example, most of the projects for the last few scrums were all making changes to program logic to account for new situations. 

Don't those "new situations" introduce uncertainty, through which product complexity then increases?

too few people? What does that mean?

Going to pull some passages from the Scrum Guide before I answer. Any emphasis was added by me.

From Definition of Scrum

Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

From Uses of Scrum

Scrum has been used extensively, worldwide, to:

1. Research and identify viable markets, technologies, and product capabilities;
2. Develop products and enhancements;
3. Release products and enhancements, as frequently as many times per day;
4. Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
5. Sustain and renew products.

Scrum proved especially effective in iterative and incremental knowledge transfer. Scrum is now widely used for products, services, and the management of the parent organization.

From Scrum Theory

Scrum employs an iterative, incremental approach to optimize predictability and control risk.

Scrum doesn't have to be used only in the case of complex work. It can also be beneficial in the more mundane because of it provides cadence, visibility and predictability. I do encourage you to read the entire "Uses of Scrum" section because it describes what is meant by "complex work" and it isn't work that is difficult and risky.

So if your organization is seeing benefit from using Scrum then keep going. You never mentioned a specific problem with the way the organization works so why are you questioning the use of Scrum. Is there something other than your curiosity in play?

Thank you all for your insights.

@ Ian - So in the last scrum, items that were covered in a 2 week sprint - Program 1 - Add a tier between 15 days paid and 30 days paid where customer gets 8.5% discount on said invoice (10% for less than 15, and 4% for 30-45 days paid)....Program 2 - check for Feb having 29 days and if so, adjust count (coding bug since that should already be checked)....Program 3 - check database field to make sure that there are no null or non-numeric pieces of data in column (failed config, which to me should be the project (root cause) than the occasional checking itself)...etc.

Each is not very collaborative, not something that the programmers need to develop new skills for, and does not take a very long period of time.  Scrum has become a case of bounded work but not a place to grow or exchange ideas on how different people would have handled the small recoding required.  I don't see where we save time having the scrum events if all we are doing is filling up the Sprint Backlog with non-related bug fixes and the like.  To me, the efficiency is handing out all of the items, distributed by amt of time to complete and then say you have 3 days to get this done.  All projects, but not requiring a team or collaboration.

@ Sherwin - scrum dev teams are intended to be cross functional and between 3 and 9 people.  I was referencing the number of the Development Team members as being too little to work according to the Scrum Framework.  I apologize for not being clear.  The point, if there is a time where you don't scrum because of too few resources, might there be a time when you don't scrum because the increments are minor, the work not very complex, and collaboration is not needed?

@ Daniel - I question the use of scrum because spending time in meetings (Planning, review, retrospective) does not seem to be as efficient as saying..."Do this by tomorrow noon". I appreciate you highlighting the points you found relevant to my minor question, so if I might:

you can continuously improve the product, the team, and the working environment - Without complexity, improving the team doesn't seem possible.  Improvement of the product...check, but many methods besides Scrum will do that. But with such small simple changes and each developer working on a individual product, the need for teamwork is non-existent.   

Release products and enhancements, as frequently as many times per day - The work I am referring to could be released in a day...so should sprints be a day?  As stated previously, if efficiency is key, handing out the assignments with a time limit for delivery seems easier than Sprint Planning 2 wks of work. Thus I question the need for Scrum in this instance. 

effective in iterative and incremental knowledge transfer - Again, another good point, however, not much knowledge is transferred reporting to the group, "I added an ElseIf line to the program logic", or "I wrote a function that checks for the leap day", "I ran a SQL query to pull data for review". Are we not putting enough of a description to get value from this review?

Again, thanks everyone for the viewpoints, which helps me grow in understanding Scrum.

Minor increments are still increments. If the team resources are "too few" meaning, less than 3, check with your management if there is direction for the team to grow, it should not stop you from using scrum though... 

We are currently creating a new scrum team and we started with 1 developer and 1 developer lead from another team that assist this 1 developer. We are still looking for other resources and yet we still implement scrum. The outcome of this new team will be smaller compared to our other scrum team simply because it is new and still looking for resources.... we still do all scrum ceremonies so the new dev which has a minor experience in scrum get familiarise on scrum...