I have actual ADD, and I'm going to suggest something you'll hate: waterfall. Identify your MVP and some obvious desiderata, and then break it down brutally into small, small chunks. Build pieces each day, set cutoff points, and then troubleshoot for a little while at the end of every day over a beer on how to adjust for the day's successes/failures with minimal changes to your overall schedule.
This is how it works in film production where I make my living and where a very high percentage of people also have ADD - it's an asset in that context because you need to be able to focus on detail issues for many hours at a time, but also to be able to pivot rapidly in response to changing requirements of environmental constraints or unexpected problems.
Now it's true that you can sit down with the idea to write some code and just start doing it. And I love to work that way on things a lot of the time. But it's also a trap because without a Big Plan then you just end up bouncing around like a pinball between different problems. Now, the Big Plan is not that much fun because planning is actually kind of a tedious grind.
For a film you go through the script just doing a ton of data entry on every goddam thing that gets mentioned on the page, and adding in things that aren't, eg if there's a scene where a character is eating dinner you realize you have to make ten records for knives, forks, plates, napkins, wine glasses, bottles of wine, fruit juice to replace the actual wine, real food, fake food, yadda yadda yadda. The script here is analogous to your user experience map or functional specification or whatever you want to call it.
I have no idea what your product/service is but I assume that the more closely you try to document it the more the entries on your task list multiply...the header files, the libraries, the makefiles, the VCS, the blah blah blah. You're sitting there thinking 'damn, let me just write some code already, get something up and running here, when it gets a bit messy we'll pause and sketch out the next stage...'. And of course you can, if you're smart and creative - same way if you get a bunch of actors and creatives, a bunch of props, and a camera package, you can start shooting some fun sketch comedy or improvisational work...but you'll very rapidly hit a wall in terms of the amount of complexity you can juggle on the fly. So to get anything done, you and your team sit there and plan, and plan, and plan. You pick tools, do some rough tests to see if those tools will hold up, and then design around them, but you also plan for a back up tool and plan for who to call if your toolchain collapses.
You sit there and plan and allocate time and argue about it, which is intensely frustrating because it's not as much fun as actually doing it, and you work for days with no more output than an ever-expanding to-do list on an ugly spreadsheet/project management file. But the good part of this is that the structure of your project and your pain points gradually become clear before you start production work, and you go into that phase knowing what your priorities and constraints are. I can't stress the importance of this enough, because when you run into problems, it's that intimate knowledge of priorities and constraints that will help you to make decisions about when to press on, change tack or abandon something.