Before you start a project, achieving team alignment is essential for efficacy and efficiency. If team members are not aligned on why the project is important to the sponsors, how it fits into the bigger picture for an organization, what the highest priority items are and what tradeoffs project sponsors are willing to make, then the project is likely to go off-track or miss sponsor expectations. Similarly, project sponsors that are not aligned with the team likely have unrealistic expectations for the capabilities, quality and timelines for project delivery. How can you get the extended team aligned?
Typically individual team members do not interact with the project sponsors very much in their daily routine. High fidelity interactions with the whole team are far more effective for aligning a team than many emails, documents, and conference calls. Usually it is not possible to have high-fidelity interactions with the whole extended team every single day due to geography, stakeholder availability, and schedules; but the entire extended team can certainly get together for a single day.
At Pivotal, and specifically the Cloud Foundry team, one effective approach we use to ensure team alignment is a single full-day meeting we call an Inception. Learn about the "why", "what" and "how" answers of this approach and review some concrete examples from real Cloud Foundry projects and teams that benefited from this approach.
What is an Inception?
An Inception is a meeting typically dedicated for the majority of a business day to prepare a team to start a new project. Inceptions may also be used to realign on an existing project that has been going on for several months. Ideally a development team can start work on prioritized, concrete and actionable stories the day after the Inception meeting. Sometimes an Inception results in the healthy early discovery that stakeholders and goals for the project are unclear and additional work needs to be done to refine and agree on the shared goals before the team can start working. Achieving clarity and alignment on issues before the team starts is far better than learning this after a team has been working for weeks or longer on work that is later thrown away.
Is an Inception related to other processes and methodology?
Extreme Programming has a concept called a planning game. Many elements of an Inception are inspired from this approach. However, at Pivotal we typically apply a very uniform agenda for the meeting that is effective for kicking off projects compared with a planning game agenda that may be loosely defined and is used throughout a project as opposed to a single day.
Some people may associate the word “Inception” with the Rational Unified Process (RUP) Inception Phase. The language or goals are similar between the Inception meeting and the Inception phase of RUP, but an Inception meeting is a much lighter-weight approach that accomplishes similar goals in a single day.
Why conduct a full-day meeting like this?
The main goal is to achieve team alignment and kick off the project well. Graham Siener says an Inception focuses a team on knowing what to build and where to start. My experience indicates that Inceptions result in aligned teams that start projects well, deliver value quickly, and do so without wasting time working on the wrong things.
Who should attend the Inception?
Inception attendees should include the core team doing the work and the sponsoring stakeholders or their designates. Typically this will include business, product, development and perhaps other teams like operations and support. It may also include representatives from upstream or downstream teams that are producers or consumers of this teams work. Practically the effectiveness of the meeting starts to diminish when the number of people is over 10 people because there is a lot of group participation and having 20 people all contribute effectively is difficult. If the invitee list is getting too large, the Inception facilitator or project sponsor may ask invitees with the lowest ongoing involvement on the team to have other attendees represent their views in the meeting. Sometimes larger sized Inceptions are unavoidable, but the tradeoff is lower participation from each attendee and the likelihood of lower alignment.
Project sponsors or stakeholders should attend or send a designate empowered to represent their views. If a sponsor cannot make the time to attend this single important meeting yet still wants to heavily influence or control the project decisions, then that is a signal that the team may not get the support and attention it needs and deserves both now and in the future.
It is important to enlist an experienced group facilitator that can impartially lead the meeting. This person’s ability to be an efficient master of ceremonies is extremely important. They are responsible for working through the agenda efficiently, ensuring the team is communicating effectively, sensing areas where the team should deep-dive for awhile, and figuring out which conversations that are going on too long should be paused so they can be worked out later with a smaller group.
When should the Inception meeting occur?
Ideally an Inception occurs immediately before a new project begins or before starting a new major stream of work for an existing long-running project. If a team has a significant number of people joining or leaving or if there is a major change in direction, then conducting a re-Inception helps align the team.
How should an Inception be conducted?
The facilitator should require the full attention of attendees and not permit open laptops and phone distractions except for dedicated breaks. Introducing the rule “If you’re here, you’re here, the whole time.” has significantly increased the effectiveness of our Inceptions.
Inceptions are ideally conducted in a large conference room with whiteboards and large sheets of paper. It is recommended to have multiple colors of marker, index cards of multiple colors, tape, and some form of snack or candy that can be used for voting. Breaks should be frequent; 5-10 minutes every hour.
In-Person versus Remote Attendance
The benefit of in-person attendance versus remote attendance cannot be overstated. Remote attendees have a tendency to get distracted and the fidelity of the communication degrades. I have seen inceptions conducted with several remote attendees before, but having participated in Inceptions remotely myself I got less out it and the team got significantly less out of my participation compared to in-person Inceptions. Sometimes remote attendance cannot be avoided due to real-world constraints. In these situations, try to use the best remote presence technology available such as high quality microphones and stand-alone video cameras. Using low-quality built-in laptop mics and cameras enable participants to get distracted with email and web browsing.
Typical Inception Agenda
Introductions - Keep the introductions brief as you will be spending most of the day together as a team and will get to know each other well throughout the day. It can be helpful to have the facilitator prompt each attendee for a few key pieces of information such as who they are and why they are here.
Vision and Goals - The project sponsor and product owner should deliver a succinct long-term vision for the project and indicate what the immediate goals are for the next few months. Allocate time for questions and discussion from the group.
Non-Goals - Just as important as the goals, it is important to explicitly state what are not immediate goals. Often times stating non-goals clearly is a way to constrain scope for the current work stream and give the team permission to deliver value faster by excluding certain things that may be wanted eventually, but not essential to have now. Make sure to allow time for group discussion on non-goals.
Risks - Everyone in the room should identify the main risks for the project using the index cards. Have each person write down one risk per index card using as many cards as they wish. The facilitator should categorize the related risks together in a stack of index cards, reading them off and providing a chance for people to explain the brief definition of the risk they wrote down. This is not the group discussion of each risk yet, this is just to understand what the risk may be. Then the facilitator should instruct everyone to use the candy or props for voting and give each person 3 votes to place on the categories with the highest risk to the team achieving the project goals. You may cast all 3 votes for one category of risk or spread out votes on up to 3 separate categories . After voting the top categories of risk should be discussed with the highest number of votes going first. Note the categorized risk ranking on the whiteboard or with a photo. The team should redo the risks voting exercise at the end of the day and see if anything has changed. It almost always does.
Roles / Personas - The facilitator should conduct a group exercise to identify either the roles or the personas that are involved in the project. I have observed the approach used to elicit the roles or personas vary a lot from simply having the product owner state who they are authoritatively to having the whole group do a brainstorming exercise. They key objective is that everyone on the team understand who the users are.
Activities / Workflows - The facilitator should work with the group to identify the activities or workflows for each of the user roles or personas scoped to the immediate goals of the project. The facilitator should pick an approach that is well-suited for the group dynamic. It can be as simple as asking the product owner to identify the key activities and allowing for group discussion or it can be something more creative like a game. These high level descriptions of how the user interfaces with the system to accomplish something form the basis for project epics and can typically be broken down later into stories. An example of a high-level workflow may be “Bobby the student searches the store catalog for a book, adds the item to his shopping cart, and completes the purchase”.
Stories - If there is time, break the activities and workflows down into smaller, concrete actionable stories. Do not worry about being too precise with the wording. The product owner can refine the language and details later. Sometimes there is not time for this activity during the Inception itself and the higher level activities and workflows are the granularity that must be used for estimation and prioritization. This is okay as it is the product owners job to work with the development team lead to ensure the stories do get written as fast as possible following the Inception.
Estimation - For the most important stories, quickly get a rough estimate from the developers in the room. If you estimate at a story level, try to use the point system and sizes your team will use during development. If you are at an epic, activity or workflow level then try to use a rougher estimate like developer weeks. Martin Fowler’s Thrown Estimate technique is very effective for quickly getting rough estimates. If you have a large number of items to estimate, my colleage Evan Willey recommends the Affinity Estimating. The important result is that client sponsors and the product owner receive estimates directly from the team responsible for the implementation.
Prioritization - Have the product owner put the stories in priority order and allow for group discussion and validation. The product owner should be able to justify the priorities to the team based on business value. Are these features “must-have” for this phase of the project or just “nice-to-have”? See if the estimates based on points can be roughly translated into to project weeks based on the team size. In almost every Inception I have attended, the estimates and priorities indicates the team must cut scope to deliver in several months. Now is a great time to have a discussion about trade-offs with the project sponsors and product owner since they are likely getting semi-accurate estimates from the team accountable for delivering the project for the first time.
Risks - Repeat the risk exercise from before and see if the risks have changed.
Next Steps - Have a group discussion about how the next few days and weeks will play out. This might be used to align and inform everyone on the process the team is going to use going forward for development and checkins. Usually the facilitator and product owner take pictures of the whiteboard, collect the index cards used for exercises, capture action items and agree on who should send out an electronic summary. Occasionally I have seen teams use Inception assets like flip-over sheets, index cards and whiteboard images displayed in the team work area. As time passes, the assets start to get out of date and have less value.
Retrospective - Use an agile retrospective to discuss the Inception meeting itself, what worked, what things people have questions or confusion about, what did not work as well, and any ideas for next time.
Fun - By now everyone is pretty tired from being in a room for most of the day. It’s likely toward the end of the day and it can be good for team to go have some fun outside the office by having an optional gathering somewhere socially. Often times people that were not able to participate in the Inception meeting want to know the outcome and interact with the team, so inviting people that were unable to attend is an option. Keeping this part optional is important for people on the team that need time to decompress.
Continued Alignment
The Inception is great for achieving alignment at a point in time, but other types of recurring feedback loops should be used on the project to ensure continued alignment. Examples of effective feedback loops include daily standups, weekly iteration planning meetings, weekly check-ins with project sponsors, weekly or bi-weekly team retrospectives and continuous delivery of project functionality. After several months or a significant milestone I recommend another Inception. An aligned team is an effective team.
Inceptions at Cloud Foundry
I have been working on Cloud Foundry at Pivotal for over 2 years and I believe the way we work results in high productivity and well functioning teams that have fun. Every Cloud Foundry sub-project starts with an Inception including some of our most innovative features like Loggregator. Loggregator added aggregated streaming logs from all applications immediately to users and drains to remote syslog endpoints. The Inception meeting, specifically getting semi-accurate estimates from the team, ensured that we kept the scope confined to streaming logs and not expanded to log persistence and search. Rewriting the Cloud Foundry command line interface in golang was another project that benefited from an Inception. During the Inception we agreed as a team to have a significant departure from the user experience from the ruby version of the CLI which helped reduce the scope of the rewrite and resulted in a much better user experience.
Most of my previous experiences developing software have used a more traditional waterfall processes with big upfront design and documentation, large siloed teams and long projects that last a year or more. I never want to go back to that way of working. The approach we use at Pivotal now is based on concepts from Extreme Programming and Agile principles has been honed over 25 years since Pivotal Labs was founded using pragmatic real-world projects and continual refinements. The process ensures alignment and a shared understanding for the core team as well as with external sponsors and stakeholders. Try an Inception or something like it 1 the next time you kick-off a new project or initiative.
1 For more a more comprehensive discussion of this approach, my colleague Andrew Clay Shafer recommends Liftoff: Launching Agile Teams & Projects by Diana Larsen and Ainsley Nies.
About the Author
James Bayer is a Senior Director of Product Management at Pivotal and leads the product management team for the Cloud Foundry open source project. Prior to Cloud Foundry, he has worked extensively with Java EE technologies as a member of the WebLogic Server Product Management team at Oracle and other enterprise middleware positions at VMware, BEA Systems, Cordys and IBM. James holds a B.S. in mathematics and computer science from the University of Nebraska.
