Agile and Scrum are actually two different domains, that tend to overlap a lot.
In addition, they are refinements of other software development processes, and lean heavily on a philosophy that supports a particular kind of approach to solving large, often poorly defined, hard to manage problems.
That said, they do not guarantee success, nor do they even prescribe a specific fixed path to use as a template for success. Rather they prescribe a set of rules and a means of modifying those rules to meet your business needs. This means that your Agile process will adapt to your company's needs, and will be slightly different than another company's process.
This is why there are checkpoints and values listed in these approaches. The checkpoints stop the team and (hopefully) make it reflect on the the work done in light of seeing if the values are still being honored. How does a team do this? They have some experience developing software, and (hopefully) some experience estimating if their actions uphold the values.
This means that there is not a really good "blueprint" for launching a successful Agile team given no experience in the software field. My recommendation is to hire a few experienced software developers, who can import some of the background knowledge, with a keen eye on if they seem to value (in your estimation) the values that are promoted by Agile and Scrum. After all, you can estimate if their values align with the ones published in these methodologies, even if you don't have years of software development experience.
And as for the "for real" part? I'm guessing you mean "not on paper, but in my company", and the only way to really start doing it "for real" it start doing it (hopefully not too) badly and then improve.