Like most things a little planning goes a long way, and typically our planning takes less than four hours to complete.
- The first thing you need to do is identify an inception leader. This person should not be involved in the project and be independent and impartial. They will run the event and keep everything on track.
- Based on the project, setup an agenda with all the activities time blocked, do not forget breaks, lunches, snack time, etc. An inception can be between 1 and 5 days.
- Determine who the participants are. You need your subject matter experts and those individuals who are empowered to commit to timelines.
- Find a location. Everyone needs to be physically in the room for an inception, it is way too hard to perform the activities over telephones or even video conference. Make sure you have lots of wall space!
- Purchase Post-It Notes, lots of them! Inceptions are analog, you may use a projector during a break-out session or the initial kick-off, but all the activities are based on collecting and rearranging post-it notes.
- Create a blank timeline of the weeks that will contain the project. Mark any holidays and other events that would keep the team from working or deploying deliverables.
The timing of the inception should occur right as a project is going to start, it is the start of the project. Holding an inception too early and your participants have time to lose focus and forget what the agreements were. The energy you create during the inception is lost.
Each inception is slightly different, and each inception leader will have their own style, and will prefer a certain order to the activities. The activities are listed below in the order I prefer them to be run, but adapt as you see fit.
Even if the team knows each other and works together every day, we always do an icebreaker activity. This is done at the beginning of each day as a way to create a “mental break” between the attendees commutes, e-mails and events of the morning and get them prepared and focused on the day ahead. They typical icebreakers we use are:
- What was your favorite vacation?
- What was your worst vacation experience?
- What is your favorite place to eat?
- What are you most afraid of?
- Where were you born?
Every event needs some ground rules, it’s important that everyone agree to the rules and always allow the group to add rules as they see fit. Our base rule set are:
- Vegas Rules
We leave this room with one voice, what happens in the room stays in this room. Disagree and Commit.
- No Screens
No computers, phones or other devices it’s important that everyone is present for the entire event.
- No Levels or Titles
We are all equal in the room, no managerial or leadership fiat in the room.
- One Conversation At a Time
We all need to be present, we all have insights so we all need to hear the conversations.
- Take Care of Yourself
Need to use the restroom, go. Need a drink, go get one.
We have a simple punishment for breaking the rules, you sing a song or do push-ups.
We use a senior level leader in the organization to kick off the event, providing business context to the project we are working on and informing everyone that their contributions to the effort are appreciated. In essence this is a nice pep talk to start the event! Depending upon your organization and leadership you may need to provide some talking points to the leader that will be kicking-off the event.
PROJECT TEAM PRESENTATION
The Project Team Presentation is designed to get all participants to the same baseline of knowledge on the project, any technologies or data points that are going to be used in the inception. They may also present a “preferred option” or “strawman” design for the project. This typically takes fifteen to thirty minutes.
Sliders represent the levers that a team can move when making decisions about scope or milestones. All projects contain the standard triad of scope, cost and schedule, but sliders are more than that. A few sample sliders are below:
- Customer Experience
Are we willing to sacrifice the customer experience to make the timeline? Are we willing to take add or remove scope based on the customer experience?
Development pipelines may be impacted by the project, are we willing to increase the timeline? Are we willing to sacrifice a feature or security control to preserve or increase velocity?
This activity will require participation from everyone, nominating slider topics and then narrowing them down to no more than five. These sliders should be stack ranked and should be visible in the inception room for the remainder of the event. Agreeing on these now will make conversations later on much easier when push comes to shove on scope items.
All projects come down to this at one point or another, what’s in scope and what’s out of scope. This activity must be done after the sliders exercise!
Have all the participants work in small groups and write down scope items on a post-it note (or card), then as a group come back together and determine if items are in or out of scopes. If the project team created scope items as part of preparation they should be presented here and voted on. The scope sheets should be visible for the remainder of the event.
ANCHORS & ENGINES
The anchors and engines exercise is a fifteen to thirty minute thought exercise. Have all the participants work in small groups and write down engine items (people, process, technologies, etc.) that will help the project succeed and anchor items that may pose roadblocks or create a drag on the project success. Make sure to have the participants label the post-it or cards with an “A” or “E”.
Now have the inception leader should be gathering these as they are available and grouping similar items together. At the end of the exercise, the group comes back together and looks at the themes and determines if there are specific risks or asks that may be needed to resolve some of the anchors.
User stories are perhaps the most important portion of what the team needs to create during the inception. Just like in software development, you need to understand what the requirements of your customers and users are. Each team in an inception should come up with the user stories that need to be accomplished for the project to be successful. If the project is infrastructure based, I have found some resistance to this, don’t skip this step it’s important! A user story always has the following structure:
As A ____________,
I need to be able to _______________,
so that I can ______________.
A few examples:
- As an Ops Administrator, I need to be able to access Active Directory Users and Computers, so that I can add service accounts for application teams.
- As an Developer, I need to be able to access our source code repository, so that I can access our code base and add new features to our software.
The examples are extremely high level, but you should end up with a mixture of high level and detailed depending upon your project.
The user story activity is normally done in break-out sessions, allowing each discipline and team to go off and create their own stories. The group then gets back together and reviews the user stories for completeness, adding or removing stories as needed.
Epics are groupings of user stories that fit a common theme. Let each team go off and create their epics after they’ve created their stories. This is for them to start thinking about the high-level themes of the project. The group then gets back together and reviews the epics against the stories for completeness.
This activity is where the rubber meets the road. Each team will now turn their user stories and epics into deliverable milestones. The project team needs to provide guidance on how detailed they want the milestones if this is a large project the team may only care about tracking major deliverables leaving the individual teams to track the minor components of the deliverables. Based on the guidance the teams create their milestones and begin laying them on a calendar grid marking any dependencies on the post-it (or card).
Once all teams have laid out their milestones the group comes back together and reviews the entire timeline. Once again we are looking for completeness, but also the following:
- Are there dependencies that aren’t marked?
- Are the dependencies in the right order?
- Was there an assumption of something existing in the environment?
- Do the participants and teams understand their deliverables and interdependencies?
During this process, the inception leader should be pushing to bring in dates and make sure that the overall volume of work is achievable.
After the review, take a picture of the milestone mapping, and mark each post-it with the week number that it was assigned. At the end of the inception, the teams take their milestones back to track and enter into any project system you use (JIRA, Mingle, Trello, etc.).
EXECUTIVE READ OUT
Now that the team has created a plan, agreed upon scope, created project sliders and created risks (remember the anchors!) its time to bundle this up for an executive read out. This activity is maybe fifteen minutes and it is not a formal project plan, instead it’s a high-level overview for the executives to understand the volume of work, timeline and key risks they can help with.
We have a single person (volunteer or voluntold) cover one of the activities of the inception and present it to the executive or senior leadership team. This is using all the artifacts that were created during the session.
Agile inceptions are a great way to kick-off a project and get buy-in from all the project teams. It scales both up and down based to accommodate any size project or effort. Try it for your next project, and if you have any questions let me know!