Labs begin with a challenge. Let's take a simple one:
Reducing the number of vulnerabilities in your code.First, schedule your Lab with people who will engage in the topic. It does not matter if everyone is an expert on the question's topic. The only thing that matters is that you have a highly engaged team. You should always have at least one expert in the room but different perspectives leads to a better result, so diversify! Schedule with plenty of time in advance so the thinkers can get their gears turning. Keep the meeting to a time frame that is the absolute minimum necessary to solve the issue. In my Lab sessions I have found that many business challenges can be resolved (conceptually) with 30 minutes of focused conversation. The time crunch maintains focus and prevents distraction down rabbit holes.
So for our challenge I would setup a 30 minute meeting with a few developers and good thinkers in my company like people in Operations.When the Lab actually begins start by making sure everyone knows the goal. Do this by writing it on a surface that is displayed prominent during the Lab session. Do not write it before hand. Write it when the meeting starts and read it as you write. I don't know why but this seems to get people more interested in what you are writing. Maybe they are watching for you to screw up.
For our sample, the goal is: "To reduce the number of vulnerabilities produced by developers by 90% over the next six months."Now to get the gears grinding ask a question that opens the world to the Lab participants. The question must get them thinking about the challenge in a different way. Here are three techniques I use and how I would use them in this scenario:
- Identify As-Is system: "What is the current process we use to reduce our vulnerability counts?"
- Reversing: "I want more vulnerabilities in our code! How can we do that?"
- Fantasy land: "What would it be like if we didn't have any vulnerabilities in our code?"
- It must bring closure to the Lab. You cannot continue the discussion because all the energy that got you here will need to be rediscovered and might be lost. Do not plan on a part two of the discussion. If something came up that is a hanging question table it for a different Lab. In the case where an issue arises that will push the Lab out of its time frame, stop the Lab. Assess the business challenge to see if you are addressing the real issue or a symptom of the issue.
- It must define time bound follow up actions. The Lab must end with a conceptual prototype so when will you begin implementation or discuss implementation? Set a date and stick to it.
- It must clearly define who is doing what. Make sure everyone who has a task when the Lab ends knows their task and provides an estimate on its completion.