Being an effective Inception participant

Hey friends,

Recently I’ve been in two inceptions, one with a distributed team and another one with the whole team on-site. Before that, I’ve been to some meetings that people called inceptions, but I refuse to comply with people who call “looking at a spreadsheet to review previously written stories” as “inceptions”.

In all of them, a few team members were not sure about how to participate effectively and what was expected from them – so I’ll list here some thoughts that might help anyone going to an inception for the first time (and also experienced folks who are looking for ways to improve).

First of all, participating in an inception with a distributed team is a whole different experience. It’s way harder for the team to visualize the information gathered, which reduces active participation. Besides getting very boring, it’s just plain ineffective to try to run a distributed inception with the usual format, just looking for ways to make it look like it isn’t distributed at all. You need to go beyond that. I’ll write a post specifically on how to make distributed meetings more effective some other day, along with some alternatives on how to use different locations (and possibly different timezones) in your advantage.

Now, coming back to the inception topic, regardless of being on-site or remote. Prepare in advance. Read everything you can about what will be discussed and start thinking on how to solve possible problems. If you have an idea over what will be the project’s scope, talk to your coworkers about their experiences with similar projects. If possible, meet the inception participants before it starts: build relationships early on and get that team feeling as soon as you can. Start the discussions and present your ideas to everyone before the inception even starts, if you have the chance. Push the team to discuss the inception format before it starts.

There isn’t a checklist on what you need to do in order to help the team once the activities begin. However, if there was one, the first point would be:

Take notes of everything

Regardless of the activities your facilitator comes up with, there will be always information flowing and not being gathered. There is always that product owner who talks a lot and throws many ideas out in the open. There is always the architect or subject matter expert[1] who shows concerns on how that new feature will fit in the current system. There is always that stakeholder who doesn’t quite know how to explain what’s the organization longer term goal, but somehow expects you to understand. You need to take notes of all this information. It’s difficult to filter out what’s useful at the moment or not, so capture everything. Have post its, index cards and pens[2] and write it down. Don’t be afraid to ask if what you wrote down is correct, or to narrow down that information and make it specific.

The goal here is not to capture the absolute truth and document it. It’s to gather information. To be an effective inception participant, you need to understand the context and be able to discuss it. Use the breaks between sessions to go over your notes and remember what was said. Then, you should be more capable of coming back with questions. Ask everything! I believe it’s needless to say that you should question everything the whole time. Don’t accept just the -what-, but look for the -whys-. I’ve seen product owners unable to justify why they needed a tool, and instead just had in their minds how the tool should look. Surfacing the reasons for building something early on helps a lot to drive the discussions to what is really necessary.

Other very powerful use of “taking notes of everything” is to capture assumptions. In an inception, you’ll often hear “yeah we should do this assuming that <fill any crazy or unlikely possibility here>” or “this is easy because <insert thing that doesn’t exist here> is done!”. It might sound silly, but often features are designed and user stories are written based on assumptions that are not true, and won’t be any time soon. Don’t consider anything said as -true-, consider it as -assumptions-. Write in a post-it and put on the wall, and don’t be afraid of referring to it in later activities.

Now, I talked about gathering information to become a more capable team member, and also about capturing assumptions so that the team doesn’t fall in a hole of insane and unrealistic scope. There is another thing which deserves full attention:

Make the information visible

Share your notes with the team. Make them visible. Put them on the wall, white board, flip charts, or just lay them on the table in a way that everyone can see (this is the essential part where being distributed becomes a huge problem). When people see what you’re writing, they begin to understand what YOU are understanding, and the discussion goes a step further.

I can give a real example on how this helped the team in my previous inception: We had a Product Owner who talked a lot and assumed that everyone was following (which wasn’t the case, since some people didn’t have all the context behind his ideas and even not being a native English speaker was a barrier for some). People would, then, write down notes that just didn’t reflect what he was saying. He quickly understood that he needed to slow down. He then started rewriting the notes himself. This was awesome for two reasons: it helped the team to clarify their doubts without directly interrupting the conversation[3]; and it made the PO to engage and write stuff himself, making accurate notes that were referenced throughout the whole inception later. Also, when we started activities to write stories, it was already natural for him to write them down with his own words.

Also, you should be aware that much of what you write needs to be thrown away (either for being wrong and corrected in a different note, or just being redundant). I really like the exercise of going through all the notes on the wall by the end of each session, reviewing if what is there is valid and clarifying open questions[4]. If there is anything out there that is just not needed anymore, don’t be afraid of removing it[5]. Ideas evolve during an inception, and sometimes a note from the first day is not true anymore on the third. However, be aware of not losing assumptions on which the project depends, and to not lose the notes where the true intention or necessity of the stakeholders is described.

One point I didn’t mention about making things visible is the use of projectors or previously drawn diagrams. I strongly believe that, in an inception, the team should understand the problem and build the solution together – and bringing anything previously done goes against this. However, there might be existing architecture diagrams or even mockups of what the solution should look like in the future. I suggest keeping this to a minimum and, when it’s needed, just refer to it – and not make it a fundamental part of the discussion. What I’ve seen previously is key stakeholders coming to inceptions with all their ideas written in a spreadsheet and just reading them to the team. -This is not how inceptions work-. However, it’s important to not throw their ideas away. Instead, while they go over their ideas and everyone just watches, start writing stuff down and make it visual. Change the flow of the meeting. You don’t need to shut down the projector, but you can surely change the flow and engage the whole team.

Run the extra mile

Even though pieces of what I wrote here might sound like a facilitator’s job for some, I strongly believe that the whole team should actively participate and make the inception happen. I don’t like to see “roles” in inceptions[6]. Everyone should to their best to understand the “business needs”, to clarify that and to build a realistic plan that makes sense.

It’s exhausting to think about activities, make them happen, understand the needs, capture them, clarify questions, think about technology, discuss architecture, see where your project fits in the organization, who you might need to finish it, among many other things you will discuss in an inception – and most of the time, all of this points come at the same time. It’s not a one-man’s job. That’s why there’s a team. Support each other.

Of course things will change when the project starts – people will have new ideas, some dependencies won’t be fulfilled, the team might change… It happens. A successful inception is the one that minimizes the gap between “the plan” and reality.

What are your thoughts?

Regards,
-TC

PS.: Make sure all your inception artifacts are well taken care of after the inception ends. All flip charts, drawings, post its and pictures should be easily accessible for the team throughout the whole project. It’s not just something to remember the good old times: it is also a matter of saving all that useful information and being able to come back to it.


[1] Even though roles such as “architect” and “SME” are not agile-ish, from my experience is unlikely that you will participate in an inception for a whole new project, in a green field world. Most of the times there will already be an existing system, and thus, there will be people who own part of the knowledge. ^

[2] Help the facilitator. Bring material to the room and share with the whole team before the meeting starts. Don’t be the only one taking notes – instead, give everyone the option and tools necessary to take notes. As the time passes, it’s likely that people will join you and will stick post its on the wall with their notes. ^

[3] Specially when working with inexperienced people, you need to be aware that sometimes they don’t even know if they should understand something or not. They might get intimidated and leave the conversations with a lot of questions unanswered. Having the habit of writing everything down naturally helps these people. ^

[4] You might want to move the open questions to a Parking Lot and discuss them in a separate session, due to time constraints. However, if there is any outstanding question or issue, follow up with the team as soon as possible – it might become a blocker for the next sessions. ^

[5] Some people are sensitive and don’t like to see what they wrote down being torn apart and thrown in the trash. Be aware of that. ^

[6] In fact, I don’t like seeing roles at all in agile teams – but this is another discussion =) ^

Advertisements