Because dojos can be so broad (literally about anything related to testing or coding or software), it's important to figure out where to go first. For the first few in particular, they're going to need to be really awesome, so that people who have given it a chance go away excited and talking about it to other people. For the rest of this, when I say "dojo", feel free to substitute a less trendy word, like "lesson" or "session".
For the first dojo, I would attempt to do something that:
1. is fun
2. addresses an area that a lot of people complain about (translation: something the group as a whole agrees could be improved)
3. can be done in 1-2 hours, tops
4. has a very concrete lesson
5. involves everyone
For the "is fun" criteria, it's going to depend on what your learners generally like. Some people respond to things like "let's build a balloon bouquet" because, hey, loud bangs are pretty hilarious. I did one once that involved drawing faces on balloons and seeing if we could get them to blow up into a face that looked like something we had drawn on the board. It was about learning iterative processes and scaling behaviors. We put a face on the board, handed everyone balloons, and said, "draw something so that it looks like that face when we blow up the balloon." Everyone cracked up at all the different faces we made on those balloons. Some groups won't respond well to that, though. They're very concerned about being software professionals and so really only see training and learning in the context of software. For those groups, you're going to want to stick to software-based dojos and lessons (or risk the "this has nothing to do with my job, this is stupid" dismissal).
Addressing an area that a lot of people complain about is a way to help make the learning feel relevant. If your message is, "this will help you with that thing you were complaining about last week", more people will think it's worth their time than if your message is, "this can help you be better". So listen for a while and find something everyone complains about. Then structure your first dojo around that.
Time is important. Unless management is forcing people to be there, you want to keep it relatively short. An hour, maybe two, isn't a lot of time commitment. It'll also force you to keep things moving.
You're seeking relevancy here. Part of that is addressing something people are complaining about (see above). Part of it also is about giving them something they can actually do about it. Make sure the lesson is highly concrete and that it's something they can go away and do. Maybe it's a new trick, or a new utility they get as they leave the room. Don't make it something that uses a tool that they'll have in a month; by then they'll have lost the tie between the learning and the reduction of their complaint. The goal is to make the reward for the time they're spending immediate. This is something we can talk about more as you get into specifics.
The death knell of a lesson is a lecture. It's a bunch of people sitting there, checking email, and going, "wow, that was a boring meeting." Have everyone in the group do something, and have the group as a whole doing things as much as possible. You'll need to provide guidance and a little bit of introduction and conclusion, but make the practice and the discussion as large a portion of the session as you can. Split into small groups if possible (2-5 people is good), so that everyone gets a chance to try things, and no one can hide in a corner.
In short, when you're starting to learn, the emphasis has to be on immediate benefit and on having a good time doing it. You're not just helping people learn. You're creating learning evangelists. Excitement and effectiveness are key.