 Welcome everyone to the session by Konstantin Korn-Schmid-Pauly. So the session is titled as Customer Obsession. So just to have a quick introduction, so Konstantin has over 30 years of combined experience as a program leader and agile transformation coach. He has helped transition various US federal agencies, non-profit organizations and the Fortune 100 enterprises from the existing work practices to the Agile understanding. So that connects all the layers of the organization to the new lean and agile self-sustaining ways of working. So without further delay, I'll give it to you Konstantin. Thank you so much for the introduction. I really appreciate it. So good evening everyone. Good morning or anything in between wherever you might be located. So I'm excited to be able to present on a topic that's very near and dear to me because at the end of the day when we talk about agility, really it has to involve everyone in the organization. And I think when we look at one enterprise that clearly has embraced obsessively focusing on the customer, we know that this is arguably Amazon. They have in many ways become the blueprint of how we actually engage feverishly with our customer, making sure that we are doing everything for the customer and everything that we're not doing is waste. So really kind of they have set the blueprint, a lot of organizations try to model them. And really it requires a discipline and what I want to kind of walk through today is some of the things that we as an organization can do to connect. But why is there a disconnect with customers? So these are some of the things that I in my practice have found. And really I'm not going to read all the bullets on the slide, but it's really sums up in kind of a couple of sentences that a lot of organizations still, if you look at the customer being on the left, a lot of organizations are still traveling out to the right. So they're having large projects. They're happy about quality of the projects, but the outcomes come very late and they're not necessarily lined up with what was initially requested. We build long requirements documents, but that's not necessarily written to this what the customer actually wanted. And also very important is that a lot of organizations don't leverage the discipline of user experience, which is really an investment that is very, very valuable to have, because really that connects you with the customer and their experts in that field that can help with that. So let's take a look kind of at the lifecycle, if you will, of customer obsession and the touchpoints and the disciplines that we have associated with that. So clearly on the top, you know what's mentioned that user experience, being able to connect, understand, sense what the customer needs and then tying back to a lean delivery model. So what's valuable today may not be valuable six months down the road. So we have to connect and really resonate with the customer very quickly. But then once we have a solution introduced to the customer and really the road starts because then you have the digital experience. You need to make sure that you have your customers be able to work with you in the way that they want to. So a digital experience that's useful, fast, easy, simple, that they are actionable and that they really have can get, because oftentimes you may have a product that still has some issues, but if you have great customer service, then that will make up for it and vice versa. And then to the top circle there as we loop back, the customer experience, that's kind of the goodwill, the citizen engagement, the brand that you're building. So this is all kind of one circular loop. But we are going to focus on really tying user experience to a lean operating model. I want to spend a little bit of time on the discipline of human-centered design. So this is really where it starts. Again, the customer is on the left and we purposefully do research. We try to empathize. What are some of the problem areas that we're trying to address? We then help coming out of that step define by compiling the research, what we've observed and really pinning down kind of those air problem areas, which we then go into kind of design thinking. We ideate on some solutions and we bring that into kind of a prototype form and we loop it back to the customer through some form of rapid iterative testing and evaluation and then we launch, which would be hopefully a short-cycle minimal marketable feature in which we gather feedback. And we use some of the methodologies that you see on the screen as well. Key thing is design thinking, experience design, because you really want to connect with your customer in that respect. So really what we're looking at at a high level is that we need to travel from the problem to the solution space. And we need to have that interactive feedback loop with the customer. All the while, sometimes customers have pie-in-the-sky ideas and say, you know what, we really love this. You build it for us. Well, it may not necessarily be aligned with the architectural runway. There may be solution architecture that is not in pace with that. So you want to make sure that you are in lockstep with your solution architects, the technical advisors that can kind of validate that along the way. So that's very important. Pulling the onion back a little more because I kind of wanted to make sure that we have two artifacts or two processes to share with you here. User journeys. If we don't do user journeys, if we don't interact with our customers, how do we know? So we need to put ourselves in that space and say, let's walk through the scenarios. What are your goals? What are the challenges, the touch points? And then figure out the persona. How do we make that persona get what they need? And ultimately here you have the other thing is where you have empathy maps and the empathy maps are basically let you think, feel and hear and see how you interact with a customer and what your customer really needs. So that's kind of the user experience side to the left. Now let's focus on for a moment here on how we visualize what we've learned from user experience to actually define it, how we build out the product roadmap. So this is basically Karen Martin and Martin Osterling have been authorities in kind of lean design thinking. They wrote a book back in 2013. And I like what they say is if you can't describe what you're doing as a value stream, you don't know what you're doing. And so that resonates I think with a lot of organizations. What value streams maps really are is that you are basically defining every step that it takes to deliver value to the customer. And it looks at the people that support these steps and it looks like the systems that are supported by it. So wouldn't that be wonderful if you at some point could say, oh, I can eliminate two steps in this process and make it more efficient for my customer to get my products. That will help you illuminate where are their areas. And then if you exercise value stream mapping on the road, you are actually able to build a situation where you can hone in on problem areas where there's waste, where you look at cycle time, you can look at lead time. So again, that combined with what you learn from the customer and now you're visualizing your product roadmap, very, very powerful. So who are the benefactors, right? So the customer again in the middle, as an agile team, if I can see the chevrons that I'm trying to improve in the process flow by reducing lead time or cycle time, I can clearly hone in on and say here are the things that we are going to focus on in terms of our development efforts. Quality operations, your regression testing or your root cause analysis will be easier to see because you're looking at problem areas at a particular process step. You don't have to go all the way back necessarily where it's not relevant so you have that visibility. And clearly user experience, you can better align on areas to optimize and then the product management has the visualization of the overall product roadmap, lifecycle value stream, so they can make some strategic decisions to make it more efficient down the road. So I know I'm jumping very quickly here around a lot of concepts but there's a discipline that needs to happen to bring this all together. So let me kind of bring it all together in an initial and don't worry if you don't have to read this on a very small screen I'm going to be showing you some highlights on steps across the way. So first let's just take a look at this map here, right? So you have everything starts with the customer at the left, all great ideas are welcome. We then take it all the way through this whole process of analysis, UX and ultimately feedback loops through MVPs. And now let's take a look at this in a little more detail. The first one is you need to kind of create a space for your customer to say we welcome all great ideas depending if you're B2C or BTB you might have different artifacts. In this example you have a lean business canvas that someone representing the customer could fill out the customer could do it himself or herself or you simply have a feedback insights form where you gather great ideas that come in and then you as a product management team are really looking at this is the voice of the customer that's coming in, right? This isn't kind of just the surrogate which we at the enterprise think we are assuming. So then the second step you go through analyzing and the analyzing really is taking the initial input and bringing it into a format where you can gather a little more information but the idea is that you remove yourself from creating large tomes of business requirements documents. You have a single lean feature canvas where you identify the problem statement. You look at the things that you have on the screen here you fill those out and by the way that also sets the stage for some formulas and prioritization which we're going to go to in a little while so that this could be something that's sliced up small enough for the team to understand and build in a very short life cycle versus aligned with a big project plan that again will take things down a path that we don't want to be we want to be more feature oriented not project oriented. And also we're validating is what we're being proposed we're proposed here is it aligned with a value screen that we've established and if it's not still a good idea but it might not be one that you want may be prioritized as a high priority or you would align it with another part of the organization. So the third step is again we looked at it in on a previous slide is there's a whole area of lean UX where we take this process of human-centered design but we do it in a more compressed format we don't eliminate the steps but we cycle through it quicker so that we can get through this diverged converge approach and ultimately come up with something that will then culminate where you then can say okay now I have some initial analysis now let me take a look we can't do everything at once right it's impossible so we need to basically prioritize these are a couple of prioritization models that you can look at organizations will use different ones there's probably some additional ones also but these are some of the main ones that organizations will use okay so all these features we're going to basically use this formula we're going to prioritize them based on that way now we get into kind of the implementing part of the story so one thing that we experienced that actually helps is before you do any kind of big room planning or alignment when you have multiple teams dependent on each other is for the product owner, the product management and it's the representation from UX to say okay we're going to now do a story mapping exercise we take the feature that we prioritize we are presented to you and now you can basically take it through the process of sequencing and prioritizing and then you can ring fence what might be viable to release within a release of you know a couple of sprints for example and then you go into big room planning so ultimately the big room planning part is where you bring all the teams together to then create your MVP backlog and then what we like to also often see is that you want to make sure that we're 100% aligned with your customer in terms of any visual design so making sure that you are interpreting this correctly so you can do this in terms of conducting a sprint zero where you essentially are going through the cycle of doing more tendencies and you have the front running of UI designers that would create artifacts might have developers that set up their environments but ultimately then you align on what's needed within that kind of start-up sprint get to a kind of a definition of ready so you work very closely so that when you start development you're not scrambling to say what did the customer interpret for us so then once we've done that we actually execute the MVP so we're getting now to the point where you are executing the MVP and there are some critical decisions you need to make after working through designing the right thing have we done it right and so you need to validate whether or not you've met the business hypothesis or if you basically need to revisit that and take it back through development cycle or you basically need to pivot or you persevere because yes we're online or in worst case scenario you stop while you're not investing too much so that's kind of the decision points that are quite critical and then ultimately you are going to look at adopting because what you do in terms of when you actually map up whether or not the deliverable meets what the requirements were the acceptance criteria at that point you don't know yet how well you interact with how well the customer is proceeding that product so you need to have some adoption metrics and you need to also say how fast do we deliver right with what quality so if you see here for example we have the product value stream we also have the process value stream but we can say how long is it taking us to go through the cycle how long is it really do we need to accelerate certain things so what you see here on this screen is kind of more of a kind of sequential view some of you may have seen this model here before where this is basically an iteratively start-up model to kind of visualize that everything that we talked about is iterative it's not sequential it goes through a cycle essentially showing what I shared with you on some of those process steps but it takes it through the abstract figuring out what do we need to evaluate analyze and making it concrete in terms of getting the solution from problem to actually something valid that the customer can accept and it resonates with so last but not least wanted to kind of share in summary what kind of what are some of the behavior changes that we need to do in terms of being more in tune with our customer as you've kind of seen from the process that we walked through clearly obviously you need to be customer centric at every level of the organization and we don't want to be kind of project to project transactional oriented we want to become more product focused and we want to basically be able to deliver and measure what adds real value just not outputs right sense these multi sensory think like the customer feel like the customer and again I mentioned earlier adapt a lean UX discipline it'll pay dividends and then ultimately what we talked about you visualize your product lifecycle and if you do all these things you can actually successfully build a lean product operating model that will tie the whole organization to what the customer is asking for so that I want to thank you all very much we're just about at time here but welcome any questions that you might have and I thank you very much for listening here thank you Constantine and I believe anybody if you have any questions if you want to put in now we have a few more minutes where Constantine can take some questions so I believe there's one question which has come from Ditanjali which says can you say Jira is the tool that combines lean and agile part well for implementation Oh absolutely great great question all know Jira has its positives and some negatives but yes taking your Jira's construct and not just aligning it with your development but bringing a Jira board at the program level you can create a program Kanban and you can tie those together and you have the traceability because keep in mind you want to trace your feature implementation all the way through development so you want to have that trace back so Jira if you're thinking about that absolutely a great tool that you want to use okay there's one more question from Ankit Agarwal which says what is the top thing customer appreciate with the approach you have mentioned the top things that they appreciate is that they basically are seeing that the company's resonates with what their needs are right so if you are able to identify the need and then very quickly come back with them to them with maybe not even a complete solution but a partial solution that does what intended well then the customer will have the confidence that you are working with them and yet you are not having them wait for long project cycles to deliver something of value so really if there's one thing you kind of want to highlight is this reducing the time to market and reducing the cost of delay because if you delay something that's delivered to the customer they may be lapped by the competition they need to have something quick and so if you can do build unambiguous and fast you are going to be very much in the trust situation with the customer absolutely absolutely thank you I hope Ankit that answers your question we have one more question from Preeti Monod which says to do customer centric development do we need to follow BDD practice agile development that's a great question that was a whole I wanted to actually see to build some slides into it but we would have been 30 minutes 40 minutes into the presentation BDD absolutely taking behavioral driven development aligning it with that is the logical extension having a well established pipeline having the kind of three amiibo concept where you are lockstep with the PO taking what exactly the customer is envisioning and cycling it through and shift that whole process the test first it is perfect in terms of alignment with this because in BDD practice you are ultimately then getting out of the estimation game because you are bringing things down to a very small unit of work which resides in a feature file and you are executing so your throughput is consistent and you are bringing it back so BDD practice harmonizes really well in this customer centric model great thank you I believe that answers your question Preeti please feel free to put in any comments if you have in the comments section there is one I think we will take one more question and we can for rest of the questions we can feel free to have them in the hangout section so there is one question from Srinivasan Sundaram he asked what are the challenges you faced while transforming from project mindset to product centric mindset really good question it is not easy because you think about it the role of a project is guided by a project manager and they are more attuned to command and control or more prescriptive to say I know this is how we need to do things versus being adaptive and taking more of the backseat allowing self and power teams to flourish it becomes really it is an organizational change element as well so when we have this engagement we are looking at the new job families and how these job families are different coaching the existing project managers for example on being a more adaptive and aligning that with the team so there is a lot of if you will there is some one oh ones and then there is more kind of meet the teams where they are each team each engagement is different but it is absolutely depending on the level of maturity and agile maturity will like to do a baseline assessment we will let the teams self-assess and then we as coaches do validate show me some of the artifacts that support your assessment and then we will do our assessment and then take them on the journey and at some point reassess how far they have come and it does not only transcends into other areas product owner roles may not be visible maybe just a business owner so we need to basically go and build this from the ground up from the health directions, from the handshake from what we bring in from the customer and then ultimately how it gets delivered cool great thank you I think Kashra Nivas and I hope that answers your question we have three more questions but there is one question from Ganesh Ganesh which has come on the chat so I will read that for you but maybe if there is a if there is a long answer to it maybe we can take it in the hangout session but regardless I will read that question out to you so he has asked are there any real-time case studies that we can have to understand this that is a great question so certainly at EPAM we do have case studies but we have to be mindful about how we share those but we have materials we clearly have sometimes anonymized ones that we have done but we cross our engagements we always end in engagement with case studies we like to put in place but there is a policy around being able to share those unfortunately I believe there are two more questions and both are from Gitanjali I will take the top one Gitanjali I think the next question please feel free to interact with Konstantin on the hangout so I will take the last question and then we can move so another one which Gitanjali asks according to you which agile job roles should primarily involve with stakeholder with respect to requirement understanding documenting before team onwards from spring zero okay so basically you want to make sure that you are aligned all the way at the left with a product management culture so product management will basically establish the roadmap of alignment with the customer will establish the value stream and then ultimately that's the strategy the longer term strategy then at periodic levels where you are focusing in on areas of the value stream that you want to focus on to create efficiency that then drops to the PO level product owner which is more of a tactical alignment with the teams so the product management will say we have to prioritize these sets of things Chevron on the value stream for example so the product owner will then take those requirements which again are typically more in a lean future canvas so they may be four or five or six of those that have been prioritized and then ultimately they take those to the team in a big room planning or even before the big room planning they do some decomposition of stories through story mapping and then finally bringing it to a kind of an efficient starting point for big room planning to say okay now we've already broken down the stories to the level that we can do some estimation now let's align on our dependencies so the whole aspect is the product owner is not bringing a business requirements document with 500 pages to the team it's all been kind of validated on a very lean definition in terms of what the user needs that can be implemented within a reasonable space to get that feedback cool I think we've had a good number of questions and we are almost eight minutes ahead of our schedule time but I'm glad there are so many questions that are coming in and I would like to thank Constantine for this for sharing your great experience and guidelines with us today