Hi Rob,
not a professional game dev team here, but it's some years now that we're into our adventure and in the last 18 months we got serious about it.
Your question, to my understanding, had more to do with the process than with the tools and I totally get your point... where to start? I can just give you our totally-non-pro experience.
First of all my advice is to scan the interweb for valuable sources. Ron Gilbert's blog is definititively a must-read and the Thimbleweed Park dev blog is another goldmine of information on design and conceptualization.
We started with a quick subject (a few lines, like the one you read on the back of a DVD for a movie) then started defining the "parts" or "acts" of our adventure.
Each act has a clear ending point, a goal to reach. It is that moment in the timeline that sums up every open thread together. For example, take Monkey Island: the goal of the first act is to be appointed as a pirate. The goal of the second act is to find Monkey Island. The goal of the third act is to enter LeChuck's hidden cove to rescue Elaine (there is a setback here, nice trick to keep the player engaged). The final part has the goal to kick LeChuck's butt ending the game.
Each part ends with a specific fullfillment and the events take a strange turn, to propel the story forward.
Now that you have a "pace" of intermediate goals, like checkpoints on a pathway, you can go ahead and define the actions or better, the puzzles the player must overcome, walking backward from the part's goal. To be appointed as a pirate, Guybrush must overcome three challenges, so they become the intermediates goals. For each of them, think backward: "what has to be done to achieve this?" and put one or more obstacles to the achievement of that step.
Ex. to beat the swordmaster you must: find it (the old merchant puzzle), be ready (the trainer scene + the insult fighting puzzles), get a sword (...) etc.
Here is where things get tricky. There is a lot of literature on game puzzles. Search around a take the time to learn. Analyzing your favorite games also helps a lot. It's important to master concepts and devices like proper signposting, puzzle structure, etc. There is no such thing as a good puzzle, but there are bad ones and learning how to structure them to avoid pitfalls will bring you to a level where at least the audience can say your puzzles are too hard or too simple or a bit boring... but not flawed/frustrating. This makes the difference.
Back to the game structure: a mindmap is a great tool for this "working backward". Create nodes on the mindmap, each of them a "goal/step" to be overcome, and write the description of the action, funny scenes, key dialogues, in the node notes (we use Mindmup for that, nice and free if you connect it to GDrive).
When you have your puzzles drafted, you can jot down a Puzzle Dependency Chart (google for it, you won't regret) to depict your overall structure and make sure it is balanced.
In the meantime, if you can afford it (or if you have the talent for it), sketching concept art is a BIG boon. If you suck at drawing, commit anyway to draft your idea while discussing the puzzles with your team. Visualizing gives a wealth of information, gets everyone on the same page and helps spawn new ideas. Visualizing is foundamental (they are GRAPHICS adventure, right?!

). Google Jamboards are a free (albeit limited) tool that helps in this remote times, but Miro or other online whiteboards gie you more features. If you can spend 40 bucks for a pen and tablet (like a small Wacom or Huion), it will change your life for the better, accelerating your ability to sketch your ideas, save whiteboards of useful stuff and transfer your concepts to your team-mates.
With some drafts and concept art, plus the bulk of the puzzles (at least the "happy path"), it's time to start doing some programmer's art, wireframing or sketching the locations and characters, even if not animated, and wire the game together. This phase gives you a lot of perception of the effort necessary to actually finish a game... after getting a hang on how fast you are in specific activities, you may decide that (for example) those 377 locations are a bit too much since each one required you 33 weekends of work to be at a decent stage...

Also, wiring up your game and locations helps a lot placing red-herrings and additional false-tracks in the making, since you have the physical real estate to place elements on the scene, making them interactive and having your creative juices flow as you "see things".
And you really WANT to have extraneous elements, dead-ends and red-herrings or your game will just railroad the player to the solution, that's boooring.
Moving on, if you have musical skills (if not try out Musix Maker Jam) you can stub some background music to set the mood of the scenes and see how they work out. Music is really important in conveying emotions and feelings to the player. The same scene with or without music can pass from (say) a desired creepy mood to just ludicrous.
I wrote a lot and hope it all made sense. As I told, none of us is a pro and we are still discovering things as we go, so any further advice may be a bad one.
Being not professional devs I may have said a lot of stupid things, so keep in mind that's OUR experience (the first btw) and in our opinion, it all boiled down to this:
- Set clear goals: for the player (in game) and for your team
- Shrink your scope: creating a demo game with three locations and a simple big puzzle is a good way to see the whole production flow happening in months instead than years and it gives you a lot of experience
- Build in iterations: don't aim to the perfect graphics, there is time to retouch it. Don't aim to build all the animations, you may want to change the scene while you go. Don't worry that much about authoring your music, most of the time the player is not "listening to it", it's just influenced from it, so you can do it in the end or just put it together with simple arrangers. Leave space to adapt and grow as you go and try to keep yourself engaged with small but frequent successes, instead of working for years on the perfect game, piling stress over an unachievable goal.

Hope this helps

Cheers