It seems like the consensus is that, yes, it certainly can be done, though of course it'll have its challenges.
As a counterpoint though, you could just as easily pick out, say one or two core features, build up a prototype with those features, and then slowly add content that way. So, you don't have to chunk development spatially (in terms of levels), you can break it down in whatever way will be most convenient given your development plan (e.g. if you expect it to take only a few weeks to build the game world, but many months to build the graphics engine, then you might split up rendering components instead).

The only way to make a big game is to start small. Noone starts writing the first line of code and testing it the first time once the whole picture is done.
You start simple, "Hello World", game loop, getting a map on screen, handling inputs etc etc.
Constantly testing, and when satisfied, moving on to the next milestone adding features as you move towards the end goal.

To answer your question on whether you can build a big game by starting small. Of course you can, just look at Microsoft Word and its multiple incarnations over the years more and more options for document editing were added, and now cloud based documents, etc. So it is entirely possible to make a big game by starting small and planning big.

As for the method for doing it depends on the size of your team (1 person? 5? 10?), the experience of your team (Beginners? Programmers out in the working world?), the commitment of the team (full time? hobbyist?) and where are the team members located (everyone is located at the same place?).

If you have a small team, say 1-5 members with little to no experience doing this as a hobby. I will recommend the traditional waterfall method. It is simple and straight forward when compared to agile development.

Don't get me wrong I like the idea of agile development and have personally been involved with quite a number of them, but agile development does requires the team to be highly disciplined (simple things like regular sprint meetings may not be possible if everyone is doing this as a hobby), and led by people who have experience in it (e.g. a good scrum master and product owner to write the stories).

At the end of the day, no matter what method you chose, spend time to properly plan this out. For a good plan will let you know what is achievable in what time frame, and most importantly let everyone in the team knows how far to go to achieve the final objectives.

Thank you, all of this has been really helpful,

You mentioned creating the game level-by-level. I just want to note that, depending on the specifics of the game, the bulk of the work may be involved in getting the basic functionality/foundations in place which are required by all levels.

Often agile approaches focus on adding features as you go, and the design of the game may mean that most technical features need to be complete before you can have a full, playable level. On the other hand if up-front work is less significant and most of the effort will be in creating level content/artwork, or your game design allows mechanics to be implemented piece by piece as you progress through the levels, then this may be a viable approach.

A proof of concept before investing a tremendous amount of time in a game, sounds reasonable.