 Welcome everyone to the session Achieving Aligned Autonomy in Product Development with Inceptions by Lakshmi Ramasation. We are glad she could join us today. Without further delay, over to you Lakshmi. Welcome everyone. Thank you. Thank you so much, Kunjan, for the introduction and I'm really delighted to be here. I'm Lakshmi Ramasation and I'm an Enterprise Coach at Pakiolan and I'm very passionate about the topic today. So before I get into the topic itself, I wanted to get in, talk a little bit about my living values as a coach and facilitator. These are the values that I live every day. I think about enabling inclusive collaboration, showing great care with my teams and yet challenging them for growth because that's how they get to the next level. And I have a strong sense of purpose and there's a poem that I read and learned as a child. It's a Robert Frost poem and this excerpt is from that poem. It reminds me that there's a long journey ahead and I still have so much to learn and contribute and help others with. So before we get started on the topic itself, I wanted to invite you to reflect on the last project or product kickoff that you attended. What was it like? And what was it missing? Describe your experience in one or two words and self reflect, or if you feel comfortable share that in the chat. Did you build a shared understanding when you were in the product kickoff? Did you feel like if you attended the product kickoff that you walked away with the same idea of the problem in your head like everyone else? Or did you struggle? And did you feel like you walked away with a different idea of the problem? You thought you understood but when you walked out you were still confused. And this is where I find most teams are when they come together in a large workshop or collaborative space. That is what an inception is all about. So an inception really is a process derived from lead inception that our organization, Paciolan uses to kick off new initiatives for teams. It's a disciplined and inclusive way so that you can help set teams up for success. And when we do this right, we really achieve an aligned autonomy. So what is aligned autonomy? It's really an outcome that a team reaches once they have a successful inception. They walk away with that excitement and freedom to be able to execute so they can creatively problem solve in order to get to those outcomes. That's a beautiful state and it's really magical when teams get there. So today's learning objectives were going to be diving into where inceptions started from where they originated, what the inception process is, and how we build fluency in inceptions. If you go back to 20 years ago when Agile came about, Agile projects emphasized the early and continuous delivery of valuable software, but that was quite an ask. The industry was quickly faced with three questions. How might we work out what should be in that minimum delightful product, MDP, and kick off work in an effective way for teams? How might we ensure the team is really creating the product with a shared understanding, the same understanding? And how might we ensure the product that we're building is incrementally being delivered and there is an effective plan to be able to get to the right outcomes? These questions were where inceptions were born. So we'll talk a little bit about the inception process and how that magic of collaboration comes together. Now, when you come into that collaborative space, you want to be intentional about creating that space where people can generate those conversations that are meaningful to them. So how do inceptions help with this? Let's take a look. The first problem that inceptions try to solve is the problem of communication. And I love this quote by George Bernard Shaw. The single biggest problem in communication is the illusion that it has taken place. And isn't that true? It's like the telephone game. We think that we've said something and people have understood, but sometimes we may not be conveying it in a way that another person understands. So maybe we have a story in our head that we're holding back. And this is what happens in large workshops as well. So it's really important to set the stage and make sure everybody has the same information so they can collaborate. It first starts with a good layout. So you come together in an inception and this is what we go through. This is a multi-day workshop depending on the complexity and the size of the initiative. It could be two days, it could be three days, or it could even be four days. But what you want to do is cover, start kicking off the inception with the why. The product manager and the stakeholders come together and really envision, you know, relay the product vision. And they talk about who we're building this product for, who is the persona, who are the people that are going to be using the product, what is the product, what is it not, what does it do, what doesn't it do. And the main features that we're building in this product. The team at the end of everything in the why bucket really has a strong understanding of why this problem is important to be solved for our customer. And then we start diving into those artifacts that the team is prepared. It could be technical architecture, it could be sequence diagrams, technical artifacts, US, UX artifacts, maybe some product artifacts that they have prepared so that everybody can really understand now finer details about the initiative. Customer journeys and flows can be shared. At the end of this, what really happens is the team is now able to have a good understanding of the problem, and now they can start working, breaking the work down. That's what happens in story mapping. And that's an activity we'll dive into in a little bit so you'll get a visual of what that looks like. And then finally at the end of the what we say, okay, we've created a story map, we now know what the work looks like, but how are we going to incrementally deliver, and that's what happens in slicing. Finally, at the end of the inception, you want to know what are the roles that people are going to play, what's that process where people are going to come together, and finally wrap it up and say, you know, send out a readout to everybody, walk through some of the main artifacts and make sure you leave the room with that shared understanding. This is what a good layout looks like, and helps everybody get on the same page. The second is you want to make sure the right people are in the room. This is really important. So before the inception the schedule, you want to make sure the right stakeholders, the team itself because they're going to be doing the work. There are some dependent teams that you're going to be integrating with. Maybe there's some third party partners that need to be involved. Maybe the reporting team, if there's a reporting and data analytics piece, basically everybody that cares about the success of this initiative needs to be present. The last but not least is you need to prepare well to come together in an inception to make sure it's meaningful. This is really really important, I can't stress this enough. It's important that the team is actually ready to insert. I've seen this a lot where the team is still working on finishing up the previous initiative, and we're rushing into this inception. The team doesn't even have the headspace to start preparing for this inception. So it's really important that the team is actually ready. The second is really aligning before coming into the inception. It takes time to prepare the artifacts to talk about how are we solving the problem so that you can really be in that same headspace before coming into the inception. So that's really important. And the last is we know that everybody is going to be doing the best job that they can and preparing the artifacts in the best way that they're able to. However, it's still important as a coach and facilitator to make sure that the final technical and product review has happened before coming into the inception. And remember, this is an expensive meeting. There's 20 to 25 people, maybe the core team, some stakeholders, maybe some partnering team members that are present. So it can be a large meeting and really a good investment of everybody's time. So we want to make sure that everyone's prepared and we're making good use of everyone's time. So the second problem we're trying to solve, the first problem is communication. The second problem we're trying to solve is how do we really align people to build the right product. And a lot of work happens before coming into the inception to make sure that we're building the right product. The first activity that's conducted is preparing a customer journey. A customer journey is really a tool where you get to visualize the experience of interacting with your product from the customer's point of view, but the customer's point of view. And we'll look at a sample customer journey here really quickly. I know you can't read all of the font. Don't worry about it. But the main thing you want to take away is there's three zones in a customer journey. The first is the lens. What are the goals that the person is trying to achieve? And who is this role? Who is this person? Who is this persona that is using your product? The second is the experience. How are they interacting with your product? How do they feel interacting with your product? What are their pain points and what are their moments of delight? That's all covered in the experience. And the last but not least, the most important is the insights. These are really your opportunities that you can probably use to enhance the product and build the next release of your product. So building a customer journey before coming into the inception is really critical. This is where UX designer and product manager partner and prepare this meaningful artifact. The next thing is a user flow. This could be a subset of the customer journey because a customer journey may have listed maybe 20 to 30 opportunities and you may not be addressing all of those. You may only address a subset of those. So for those opportunities, the team could prepare additional artifacts like user flows, walking through every single interaction so the team is able to understand how to work on this particular initiative. So this is really important as well and really helps provide more clarity to the team. So the first problem is communication. The second is about building the right product. The third is now that you know what you want to build, how do you incrementally deliver this along the way? So this is where Jeff Patton has a couple of activities which will really take this to the next level so that you can really figure out how do you figure out what's in that first release. Story mapping is the first activity that the team does. This is something that happens in the inception and everybody in the team needs to participate to make this meaningful. So it's a way of arranging user stories to create a more holistic view of what it is that you're delivering. So if you think about the customer journey and maybe a few of the opportunities that you've outlined that need to be addressed along with this initiative, you're now looking at that and saying, how do I create a story map of this? And we'll look at this in a second. The next activity after that is slicing. So if once you have the whole story map, you now need to figure out how do you incrementally slice this so that you can have some proof points along the way. The team can have some celebrations. Maybe they can quickly validate a problem that they've solved before they move to the next part of the initiative. This is what a slicing a story map looks like. So this is an example of a hotel management website that has some customer journey stages, some activities that the user is trying to achieve. And this is the first release of your product that has some stories that the team has mapped in the inception. Now, this is just an example of how you could slice, but the team could really come up with, you know, what is the best way to slice? Maybe the product manager will have some idea of these are the capabilities we want to provide to the customer sooner than later. Maybe the team will have some ideas of these are the technical challenges I want to solve sooner than later. So it becomes a negotiation and a communication in the inception where the team can come up with, this is the best way we're going to incrementally deliver the product. So with all of that we've talked about where inception came about why it was important to come up with something like this and the process itself, but we know that it's not important to just do the process for the sake of doing the process. The important thing is to be able to get fluent at it and for it to become muscle memory for the team. This is where building fluency comes in. Fluency is how a team develops software when it's under pressure, and we want this to become part of how they operate and collaborate. So this is where it takes discipline to be able to do this right. Before the inception, you want to align well with all of the right people, prepare the artifacts and validate the artifacts. In the inception, you want to tell the whole story. You want to be aware of those first time listeners that are hearing the story for the first time, and make sure that they're following along so that they can actually contribute and collaborate in a meaningful way. You want to have parking lot etiquette because you know when you get 25 people in a room there's going to be a lot of rabbit holes. So you want to make sure that you can really have those conversations that you want to have and save the ones that you can have later in the park to add it to the parking lot to get back to it later. And most importantly, you want to leave the room with a shared understanding. You want everyone in the room to understand the why, the what and the how so that they can really walk away with that understanding to build that initiative because that is why we're here. So ultimately achieving aligned autonomy is really simple. You take happy teams, align them to their purpose so they can come together and generate great ideas and collaborate magically. With that, if you like what we've talked about and if you think Inceptions can set your teams up for success in your organization, how can you embrace it? Who can you partner with to bring this to your organization? What support do you need to start experimenting with this process with one of your teams? And if not now, when? So with that, I'll open it up for any questions. I see one question. Okay. Is this a one time exercise by asked by Krishna Prasad? That's a great question. So it's one time for the initiative. However, depending on the complexity of the initiative, the team may decide to pivot as they start to deliver. Maybe they have to do a story mapping again if they decide that they've got to a couple of slices and now we are not able to meet the outcomes in an effective way. So that can happen. However, for most initiatives, this is a one time exercise to kick off the initiative. And then after that the team really has a starting list of stories for them to continue to iterate on. Because this is just the beginning of the journey, right? So what happens is when you come together, everybody has the shared understanding of the product that they're building, and they walk away with the starting list of stories from the inception. However, the team still needs to continue to do backlog refinement, they continue to discover, they do regular demos, they may get additional feedback from the stakeholders. So there's multiple points where they may be more work that the team needs to discover and add to their backlog. So although this is a one time activity, it's just the beginning of the journey and the team just has to continue to collaborate to make sure that they're able to get to the outcomes. Hopefully that answers your question. Great. I see one more question, and we have some time left. It's a question by Nancy, how do you get the company willing to invest the time in doing an inception? That's a great question. So there were actually, inceptions were already brought into the organization where I was in. We just kind of took it to the next level where we were able to really evangelize it, train the whole organization. When we first started in our organization, we started with one team, and we were able to really showcase that it was setting that team up for success. So it became a good success story for us to lean on, but yet there were a lot of skeptics in the room. So it wasn't easy, but after we were able to prove that it was really having a positive impact on the team, and it was really leading them to get to the right outcomes, it became easier as we started to do it with a few teams. Now in the last year, we've done 20 inceptions in 2020, I mean they were all remote, and this year all of our inceptions have been remote. So this can be done meaningfully in a remote setup as well. But you need to start and maybe have the conversation with your leadership to be able to experiment with one team so that you can showcase it. Great questions and insightful answers. Thank you, Lakshmi. Thank you so much.