 See, Talk Today is about thinking more product moving from Scrum to a dual track agile approach. So firstly a little bit about me. I'm a consultant digital program director working in London. I love mountains and travel. If you follow me on Instagram I spam all my followers with loads of travel pictures. And also I love speaking at conferences like this and really sharing with the community and engaging conversations. Felly os bwyrwch â'u gweld â'r twitter mae'n gwybod â'u gweld â'u gweld â'u gweld â'u gweld â'u gweld â'u gweld â'u gweld â'u gweld â'u gweldالwch. Felly mae'r gwerthol ar wych unrhyw gweld â'u gweld gan cymdeithas o gyr ddafodi hefyd yn 14 oedd, ac mae'n gweithio'r gyda'r wych i-dwy'r brand yw Ysisiadol – fel rhywbeth fel arfer y thyn. Ond fyddai'n symud ar y dyfod. Roedd ddau y 2005, mae twf i'r cyflawn afrwynt gymaint, How did software projects run? So how we looked at it was the classic project management golden triangle, we call it. So scope, cost and time. How we measure project success is if we come in on time, if we come in on budget, if we hit the deliverables that we defined right up front. What else is it about projects that we sort of measure? So the PMI, the project management institute says that a project is temporary in that it has a defined beginning and end in time and therefore defined scope and resources. And the key word here is temporary. A project starts and it finishes. So here's your project, there's the start, your project goes along and here's that magic point where everything ends, it's all finished, it's all good. It said no one ever, this doesn't actually happen. We're building products and services that continue past the end of a project. So they just continue on, a project stops. So today I want you to forget about projects. I want you to think more product. And also what about agile, at an agile conference? How did agile sort of exist in 2005 again when I started out? So obviously the agile manifesto came out in 2001. But in 2005 when I started, it was still quite a waterfall sort of process. It was quite gated. We went from discover, through define, design, development, QA and then launch at the end. But slowly and surely agile started coming into our world and everyone started being agile, doing agile, sort of using varying processes to varying degrees of success without sometimes really knowing what agile actually means. I think this is a really good example of it. So this is an agile map, landscape done by Deloitte and it shows you all the frameworks, terminologies, methodologies and look how confusing it is. To me it's a bit like Bangalore traffic. Very confusing and busy. So everyone's quite confused about what to use, what sort of framework to use, what methodology to apply to their projects, their products. So today I want you to also forget agile. Now I know that sounds a little bit controversial to say at an agile conference. But what I want to focus on is that there are some really good basic principles of delivering a product. So firstly, customer first. This is the kind of crucial thing that should underpin any product or service. So it's about prioritising the customer and the outcomes that they want and need. So it's about focusing on the customer and the outcomes, not the actual outputs, not the features. Like what changes do you want to make? What changes do you want in the customer? What changes do you want in behaviour? It's about valuing, getting, working designs, prototypes and software over defining requirements up front. So don't just define what you want, what features and deliverables you want and then sort of design build, et cetera, release it and then sort of see how it is. It's getting something working to the customer quickly so that you can feedback and iterate. It's all about this feedback loop and getting the customer feedback into the loop and so you can iterate your product. So frequent delivery is the second principle. It's about delivering a working product quickly to the customer. Again it's about the customer but frequently delivering means you're putting something in front of the customer so that you're getting that feedback and you're getting that into your product. And it's about the team and your customers working together to make adjustments. So it's not just your team deciding what you want to change, what you want to adapt and iterate on. It's asking your customers what they think. Do they like what you're doing? Does it suit their needs? Does it solve their problems? And they're making adjustments. So iterative development, releasing things frequently and getting that feedback, releasing in small increments. And third principle, team collaboration. A successful, you can't really have a successful product without having team collaboration. So it's the key to making your project work if you are running projects and also it's the key to building a better product. So it's about not relying on documentation to define requirements and share knowledge. It's also, it's really about face-to-face communication whether that's through video conferencing or you're actually in person. It's really about getting your whole team and everyone involved in sharing decisions and making decisions together rather than again defining things up front in isolation. And remember your clients or stakeholders they're part of the team too. Don't isolate them. You need them working with you to build a successful product. So back to Agile now. This is the Agile manifesto site. I think it was built in 2001 and probably hasn't been changed since it's just this terrible image sort of repeated down the page. But the four kind of core values behind Agile individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan they all tie into these three core principles. So customer first, frequent delivery and team collaboration. And what about Lean? So Lean is like kind of a cousin to Agile. Agile was born out of software delivery, Lean out of product manufacturing. But again the Lean principles focus on customers, optimise the whole, eliminate waste, learn first, deliver fast, keep getting better and energise workers. Again they all relate to these three principles. So customer first, frequent delivery, team collaboration. So the case study that I'm talking about today, spec savers. They are in opticians. They sell glasses and contact lenses online and in high street stores. They are based in the UK but they are also international. They have stores in Australia, Spain, the Nordic countries, Netherlands. So last year and sort of for about a year and a half I was working with the creative and design agency. So we were responsible for all the creative design, strategy and research for spec savers. And spec savers were split into these four product streams. So book an appointment, so booking your eye check online. Contact lens e-commerce is selling contacts online, virtual technology which was kind of when you can try on glasses through your webcam and things like that. And then also glasses e-commerce is selling glasses online. So we were working in Scrum. So how it was set up. The client, they had a product owner and they had a product owner and a Scrum team for each product stream. So four of them. We worked with a third party development agency who ran the development in QA and we did the overall strategy research and then we had a UX and design pairing who sat in each product stream. So these four Scrum teams. So there were lots of problems which I'll talk about in a minute. But we had to go through kind of this problem solving process with this process that we were following with Scrum. So we had to understand the problem. We had to devise a plan. We had to carry out the plan and we had to look back so inspect and adapt. So this is the kind of structure I'll go through today and talk through what we did with spec savers. So firstly we had to understand the problem. And you might think from the title of my talk I will talk about the problems with Scrum but it's not about that. Basically it's not about blaming a particular framework a particular methodology. It's not about the process that's at fault. It's how your process that you're applying affects your clients, your organisation, your products, your team. It's looking at the particular case. It's not the framework's fault if it isn't working. It's about to spec savers. So what do we know? This is pretty much everyone. So the client, our team, the development agency, everyone was frustrated. Everyone was angry, everyone was annoyed. The product wasn't getting built successfully. Designs weren't getting through to build. Everyone was just annoyed. So what do we do first? We understood there were some problems in the process but we didn't know exactly what they were. So we held a retrospective. So we took the team together and that included the client and development agency and we ran it in the kind of stop-start-continue format. So what do you want to stop? What would you like to start? What do you want to continue? And there weren't that many continues but that was the whole point of doing this. And we found that a lot of them fit into these three core principles, these three sort of underpinning themes. So we had requirements being defined by the product owner which might sound all very well but actually it wasn't the customer defining the requirements for the product. The PO was just saying, let's put this in the backlog. It was also being defined by the technology. So the development agency were building on top of quite a legacy code base. There were a lot of issues with it. We had to build, we were basically designing based on the technical limitations of the code base. It was also a bit of a feature factory. I don't know if you've heard that term before. But we were just looking at features and deliverables and trying to get them out as fast as possible. And also, importantly, there was no customer testing prior to release. So we designed build, release and then we tested a post launch. Sprint releases weren't happening. So we were basically trying to fit way too many stories into each sprint. They weren't getting done. We didn't release. We were moving things to the next sprint. The work that we were doing as a creative and design agency wasn't getting built. So where we were looking at bigger things and not just the small fixes, it just wasn't getting through. We weren't working as a team. That wasn't just our team, which was split into these four kind of UX and design pairings. It was the team that involved the development agency and the client. We weren't working as a team. We had these siloed product scrum teams. So we weren't looking at it as a holistic product. We weren't looking at it in four separate split streams. Not everyone was involved in decisions. There were a lot of decisions made in isolation. We were also, as the design agency, getting told what to design. We got some very prescriptive stories in where the PA would be very definitive about what they wanted. Designness. So what did that lead us to? It led us to understand that we needed to focus on the core principles. We needed to look at a more customer first approach. We needed to work towards building a better product for customers. It was really about a better product and it was about the customers. So we needed to devise a plan. So we basically decided to implement product discovery and dual track agile. So product discovery first. Product discovery is about discovering what your building is what your customer needs. Not what your product owner wants. Not what the tech limitations are deciding. But it's what your customer needs. There's quite an important distinction here. It's about delivering what your customer needs rather than what you and your team or even the customers think that they want. Even if your customer thinks that this feature will actually solve their problem. It might not. It might not be actually what they need to solve their problem. So I've got a good example of this. I don't know if you know Lord of the Rings quite a popular film. All these guys think that they want something. They really, really want something. But actually it isn't what they need. The ring doesn't solve them any problems. It actually causes death, destruction, wars. It's really not what they want. So how do we map this process out, the product discovery process? We looked at data research and basically looked at getting insights. So there are a few sort of cool things we looked at with this. And firstly we have the luxury of having an existing sort of product. We had websites and apps to look at. And we basically could get all the data, look at where customers with pain points were, what they were doing on the sites, where they were exiting, what they were spending time on. So we could look at that and gain insights from that. But compared to research, it's really a good one to look at, even if your competitors aren't doing it right, it's really good to understand the landscape there. And also existing research. If you're looking at things like, I mean one of the things we were looking at was the checkout process. It's quite a sort of common thing in e-commerce. So actually there's a lot of existing research out there already that you can get hold of and save yourself a lot of time and money. So we I think bought a case study on the checkout for $100 or something. But it had loads and loads of valuable research of just about ideal states of checkout which had gone through loads of rigorous customer testing. And we also ran some focus groups. So customers who wear contact lenses, wear glasses and put them in a room and started asking them questions, trying to delve into more behavioural insights. So we gathered all these kind of insights to look into the pain points. What are the customer pain points? So then we looked at the problem statement. So the problem statement is about focusing on the problem that you're trying to solve and defining a measurable outcome. So you're not just jumping straight to the solution. And this is really important. This was a big reframing for our entire process. We weren't just immediately going into defining features and deliverables. We were actually looking at what problem are we trying to solve with what we do and what's the outcome of this. So problem statements value outcomes over outputs. It's about an outcome, what sort of change you want to see in the world. It's not about what feature you want to see out there. So Albert Einstein said, if I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions. And actually, myself included, I think a lot of our companies and organisations tend to spend 55 minutes thinking about the solution and only 5 minutes thinking about the problem with very solution focused. So a problem statement can be phrased as a question. And it kind of boils down to this. You can see, if you google it, there's lots of frameworks you can use out there for problem statements, but this is quite a simple one. Which is how might we do this action so that we get this benefit. So on spec savers we looked specifically at the contact lens e-commerce journey as our first product discovery task. So, on the contact lens journey you go to the contact lens package page you click on your buy button and you get this lovely pop-up which actually includes so much information. So you get where you have to put in your prescription for your right eye, for your left eye and prescriptions can be quite a confusing thing. So there's a couple of options there for Sphere, there's sort of adding type because these are multifocal and you've got quantity for each eye but not only does it do that every time you change your prescription it has a look up to see if they've got the product in stock. Which then sort of has a little spinning sort of wheel and then comes back with the information and then you get your total price. Not only do you get your total price you get your delivery time and your delivery cost as well. So think about how much information is just in this one pop-up and what did Spects Avers find? Basically there's a 55% drop-off at this point in the journey which is quite understandable when you look at how much information is being surfaced in one place here, one pop-up as well. So then once you add it to the basket the next sort of step is checkout and there was a 23 step checkout process 23 steps, can you imagine? Like clicking through, filling in fields 23 times to get to your end purchase after having to do that awful pop-up. So it was a terrible journey. So our problem statement was how might we make prescription entry more simple so that customers can complete contact lenses, purchases more easily to quite a simple framing of a problem. But actually what we could do with a problem statement is actually refer back to that when we start looking at features when we start looking at sort of design and build we can actually say are we trying to actually solve this problem? Next, we need to develop some assumptions. So an assumption is a declaration that is assumed to be true. So now we've got a problem let's make some assumptions, let's start making these guesses about the user, about the customer who they are, what they're doing. Let's look at things like features now, let's suggest features, let's see how we can think about how to solve these problems. So some questions that you can ask when you're making assumptions. Look out, our customers have a need to these needs can be solved with what problems does our product solve when and how is our product used what features are important so now you can start sort of making assumptions about features. How should our product look and behave? And we will solve this through doing X. So these are just some of these kind of assumption questions you can use. So we made a couple of assumptions around this contact lens journey. So we need to separate out the prescription and the delivery in the journey to cause less confusion and ease this one pain point. So that's quite a simple one, we remove the kind of one pop up which contains all this information and then separate it out. But it's an assumption, we don't know if it's going to work. Another feature we came up with we should provide customers with the ability to express re-order based on their last purchase to save them refilling in their prescription. Again seems like quite an obvious one but the site wasn't doing this at the moment it didn't store your prescription. So next, we've got problem, we've got assumptions that we've made around it. So now we want to look at how we test these assumptions. So this is a big thing about the product discovery process it's testing and learning. So we want to look at some hypotheses. So this is a hypothesis framework it's quite standard but it's we believe that doing, building or creating this for this user or persona will achieve this outcome. We'll know we're right when we see this signal or metric. So you're basically making your assumption but you're looking at the outcome and also some measurement around it which is really important. So our hypothesis was we believe that separating the prescription delivery for contact lens purchases will achieve a decrease in drop-off at this point in the journey. We'll know we're right when we see more customers completing this prescription step. So you can put some proper measurements against that last one. You can try and get percentages out of it if you want to look at percentage drop-off but we kept it quite broad. Just more customers completing the prescription step. So now we go into the UX design process and just to say that those last few steps so problem statement, assumptions, hypotheses it doesn't need to take long. It might sound like a lengthy process me talking it through but we did things like this in a half-day workshop where we got the client and the development team in two and we just ran through what problems we had everyone started making assumptions and then we defined some hypotheses to test so it can be a really quick process it doesn't need to take a lot of time. So again, there was some quick UX and design against this. Again, not spending weeks like pixel perfect designs. It isn't needed. Because then we move on to a prototype and this is what's really caught being able to test with your customers. And we looked at three types of prototyping. So first was low fidelity. So these are more static prototypes so they're to gauge reactions to concepts and propositions. And it's about testing short journeys and simple goals and we use just clickable design in envisions. So it will be very kind of quick upload design get them click through and then you can put this in front of a customer and get some feedback. It didn't take too long. We've then got medium fidelity designs and these are prototypes and these are more interactive so it's about getting input on an experience or getting input on mechanics of a journey. So you can test new products and features look and feel and motion principles so something like this carousel you can see here. And we use principle for this for the animation. And then we've got high fidelity so that's a live prototype. So this is to gauge reactions to true functionality of full scenarios. So it's testing look and feel but also complex interactions. And you can see here this is where we started testing the prescription fill-in with the drop-downs having to select your prescription for each eye. And we did this in an HTML prototype. So again that can sound a bit like a lot of effort clients or stakeholders aren't going to pay for this but we had a hybrid designer and developer who actually built this in two to three days and it was the full contact lens journey he built as a prototype. So then it's about testing real sort of crux of it. So it's about talking to customers. So we do this in a variety of ways depending on what we wanted to test. Firstly face-to-face interviews so this is really good for the kind of high fidelity prototypes. So we used the recruitment agency to get some participants in and we had our UX designers sitting down with the customers and actually kind of going through our prototype with them which provides a really valuable really valuable feedback. There's also online testing. So there's sites like validately.com user testing.com where you can upload questions to with questions and then you'll get customers or users participating in it and filling out questionnaires but also talking through their journey and talking through their thoughts as they go through the journey. And there's gorilla testing which actually is one of my favourites because it's really cheap and quick. So we had our UX designer go out onto the streets and go to a coffee shop to find and tell me answer a few questions on that which obviously cost a few pounds in England but it's very quick it's very cheap and we've got immediate feedback. So that's more probably for the low fidelity prototype so when you've got some clickable designs you can just show them. And then also surveys. If you wanted to look at more quantitative data you could send out a survey to existing customers and ask them to mark things on a scale of 0 to 10 so that's quantitative data there. So there's a few other things we used. So you've got your insights now it's time to iterate. So it's about testing and iterating. If you have got a hypothesis that you test and it doesn't work you can bin it you don't have to keep it you don't have to go ahead and build it you can just put it back aside and focus on something else. That's the really important part of this process I think. But if you do find something that needs tweaking you can put it back into the process and iterate on it. So what's good about this product discovery process it's all about validated learning so you're actually validating what you're designing, what you're suggesting you're validating your assumptions and feeding that into the development you're building things that customers actually need. So you're defining and testing that the customer is actually going to use this they're actually going to appreciate the value of this. It also creates business value and this is really important so the business will get value out of something if the customers are going to use it. If you build something launch it and customers don't use it you've got waste. And also it creates a better backlog so in your delivery and development backlog you're actually feeding smart things into it. So back to agile agile doesn't have a brain so you need to feed smart things into your backlog. It's not going to do the work for you and decide what's useful. You need to actually refine that and decide useful things to go into the development backlog else you do get waste. So how does that fit with a development team working in Scrum? A big question. So we looked at dual track agile so this is a kind of rough diagram of how that runs it's not quite right in terms of the loops but it kind of works but there's a delivery track and a discovery track and they run in parallel. And basically what it's not about which people do kind of tend to think with dual track it's not about having one team and separating it off and having them working separately from each other it's about merging the team so you've got your product owner sitting across the discovery and the delivery track then you've got your designers design team in Discovery so working into the delivery team you need the designers as part of the development process too you also need development as part of discovery it's really important to get your developers and your technical teams involved in these conversations about what you're building if you're having those conversations up front that's so important and also what they're testing it's great to involve your development team in talking to customers they don't tend to get the chance to do that it's important to understand the customer at the end of this product and then QA kind of works more in delivery so this is how we kind of ran the process so we had two backlogs a discovery backlog and a delivery backlog so in our discovery backlog we came up with epics and stories we worked them through in a Kanban style process so instead of having us pair of UX and designer in each different scrum team we actually took them out of the scrum teams and pulled them into one team working on one product and we still involved them in certain or involved where needed in certain ceremonies of scrum that the development team was still running but we didn't necessarily involve them in everything that was going on, there was a lot of waste there so we worked them more in Council of Kanban style we got validated ideas and we took them into the delivery backlog and then the development team were running different cycles of scrum so what I think is really nice about this and what I think is really important is that there's a mixture of frameworks and methodologies and processes involved in all of this again it's not about having one strict framework, there's a lot of snobbery out there about having to run to just scrum and that's it and you have to follow it doggedly but something like this I think where you can blend frameworks is really useful because you can kind of inspect and adapt what's working and changing so we used aspects of design thinking Kanban Lean UX and also scrum so we kind of blended these processes together so how do we carry out the plan now I'd like to think that everything went really perfectly this was me just enjoying the brilliant plan that we devised but actually actually this was more like the reality especially me at times there we go crying so there were some core problems that we had so one of the first things was and this is quite a big one is changing mindset so we were shifting to problems and not solutions and outcomes and outputs it's really hard to get a lot of stakeholders on board with this especially more senior stakeholders who are used to seeing a list of features a list of deliverables especially when you're working with clients and you've got a contract with them and what's in places like you will build these features as part of this contract so trying to shift mindsets we had to really take the client the development team as well on this journey so we'd run a lot of sessions with them when we wanted to implement this process to really get their buy in and why we were doing this why it was important to focus on the customer it was also about working collaboratively so this team collaboration obviously so I think that's one big criticism or one big sort of worry around the dual track process is that it's not waterfall you're not doing your big design up front and then feeding that off into the development team and you're working in isolation it is about running this as two tracks together so you have to work collaboratively despite the fact we took our UX and designers out of some of the at least some of the scrum ceremonies we didn't want to remove them completely and just work in isolation from the development team and also despite different processes it's ensuring that the ways of working are clear to all so we had a mix of different methodologies and frameworks and processes so you've got to make it clear to whatever people are working with how they're meant to work and discuss that with them and make sure it's understood we implemented Kanban with our team they were used to working in sprint cycles so it was quite a big learning curve we set up a Kanban board and the team didn't really respond to it at first so we had to adapt it continuously for probably a few months at least to try and get it to suit our kind of work in flow progress and then what's a really really important thing and the diagram I showed you before doesn't actually properly clearly show is that you've got your discovery backlog and you're feeding into a delivery backlog but actually it's a cycle, it's a loopback so once you've launched things you're testing on the live product you're getting customer feedback on that you've got to feed back again feed back these ideas into the discovery backlog so your backlogs are continuously being updated in this kind of cycle so something that I've used before and on this which is quite useful I don't know if you've seen one before is an outcomes roadmap but we split it down into three core areas so when you're doing process changes it can be really helpful to look at these three areas which are people, process and product and this is a sun diagram actually instead of setting firm timelines for something we're just looking at the nearest like the smaller circle is kind of the near future the bigger one is you're going a bit further out and then further out again so it's kind of now next later almost and then we mapped outcomes that we wanted against this roadmap so some of those kind of ones that we wanted to put in place very quickly where the team being able to fill more autonomous in their decisions not just being told what to do by the PO not defining requirements we wanted to implement testing with customers quite quickly and we wanted to start working with problems and outcomes rather than solutions and outputs then further down the line we wanted less team churn we had a lot of team members leave when we were working the old ways because they just hated being in these little silos of the product we also wanted to use a mixture of prototyping we wanted customer feedback going into the backlog and then further down the line we wanted to improve the key metrics and get the development agency more engaged with the customers and not so sort of working in isolation on the tech these were just some of the outcomes we looked at mapping so tips for implementing process changes five core bits of advice first one is to engage your team so it's so important to work with your team in any changes to process if you've got a great idea it's brilliant but take it to your team talk about it with them and ask them what they think ask them if they've got a better idea than what you've got as well that's always a good way to expose if there is any kind of contention in the room but engage everyone in your team make it a safe environment for failure basically process changes will fail you will put in place certain things that don't go right you have to scrap them you have to adapt and do something else but make it safe for people to do that otherwise you just won't try anything you won't go out there and implement a new process change inspecting and adapting obviously a massively important part of agile but also when you're putting in place process changes it's so important to do your retrospectives look back, inspect, adapt continuously and understanding and selling the value I talked about business value before but it's really important to understand what is the impact behind any process change because if you understand the impact then you're actually going to be able to sell it into the wider stakeholders who you might need to sort of convince that this is the right way to go so for us it was looking at the customer first approach and understanding the impact that that would have and talking about it to the client in terms of the metrics they were looking to improve like conversion for example so we really sold in the value that our changes should make and it is about involving everyone so it's not just your team it's any third parties clients, stakeholders getting everyone involved so what we did is I think I mentioned it before but we held these workshops up front we worked through our process changes with the client with the development team involved everyone so looking back, inspecting so what was still wrong with us when we had implemented this process and it had been going for a while inspect savers still work in product silos they still split off their product into those four streams we couldn't affect that unfortunately it was too little too late for some people we still had members of our team leave or want to leave either the company or just the team and work on something different they were just burnt out from the old process so sometimes changes won't you know help everyone and there's still a lot of tech debt in the code base so despite wanting to obviously push for a customer first approach and not focus on the tech limitations there was still a lot of tech limitations so we had an ideal state we wanted to build and sometimes we could not build that straight away so we had to start looking at other solutions to this and that's where we started exploring different options where we could actually build a front end separately what went well though what was good we had a focus on the customer finally there was less development weights we weren't building things that just completely failed we did achieve better key metrics and we achieved better conversion which translated to actually quite a lot of extra profit for the company for the spec savers and we had a happier team which was really important despite a few people still leaving in general we managed to make these changes and actually have a great team atmosphere one of these kind of individual pairs like working in silos so by thinking about the core principles around good product delivery you can make customers and your team happier which basically equals this hopefully so thank you a few minutes left over if there are any questions couple of questions one is you you specifically called out how for the design process you looked at Kanban and for the actual development scrum so question were there any specific reasons why scrum or Kanban could not work for both yes so what the problem was with scrum for our sort of UX and design pairings especially working in the same sprint sort of cycles that the development team were working was that the focus was very much on tech and what we could build and it was a very rushed process in terms of we have to have something delivered for this sprint release by kind of freeing us up from that and moving to the Kanban approach we had a bit more freedom to explore things properly to put the right amount of time and focus in the product discovery process so it wasn't it was more not having time boxes really and I think why we couldn't all work Kanban was a lot because it was a third party development agency they were very, very set up for scrum it was how their sort of operations model it was all sort of how they focused and worked so it was very hard it would have been very hard to change what they were doing so we had to kind of think about us firstly but also the overall kind of benefit would Kanban actually work with this and we felt that we can still work in the Kanban style and just be dropping things into the delivery backlog we didn't have to do it every two weeks we didn't have to work on a time box within a time box basically second question was around you said you did away with the whole concept of a specific product owner you were working directly with the customer so what was your experience there in nobody being there as the voice of the team as such because generally the product owner plays that dual communication channel and he makes sure that his availability ensures that the team does not get stuck on certain stuff so while your customer available 100% of the time with the team can you share something? Yes so the product owner was 100% available they were sort of working across both tracks but they were working in these product silos still so we'd have one product owner on contact lens e-commerce but they weren't looking at the glasses e-commerce so that's where I think the issues were as well the product owner was fully available for the team that was actually not a problem but they were fully available for a certain part of the product so what we had to do as part of this is actually try and pull the product owners together they barely talked to each other that sounds really crazy on you you were looking at one product so we had to try and get them together and work with them in these kind of I think we ran at first quarterly workshops because they weren't based in London but we got them together and we actually got them to start looking at the kind of problem statements assumptions hypotheses together so that they were thinking about the product as a whole rather than in these kind of silos I think that was the main issue that we had with them rather than them being available someone at the back Hi, thanks Suzanne that was really interesting Thank you I guess my question is more around obviously the idea for a dual track development process across UX and developers is fantastic it also energizes the team but the big challenge that I see implementing this at least in my setup and I know for a lot of people in Bangalore is we are captive product units where the sort of main team might be based outside India so in that situation do you have any sort of tips or suggestions or techniques for how we build that customer empathy and especially from a product owner perspective we are doubling up across both the tracks how do we make sure that we are most making us as most relevant as opposed to just outsourcing it to the UX team that you used in your study No, with remote teams in different time zones it can be quite difficult to implement and that's another level on to it I mean we were working so spec savers are based in Ireland called Guernsey which is near France actually so south of England they were on there the development team was a few hours away so we weren't in different time zones but in different places so we had to think about firstly that team collaboration to work so we needed to use video conferencing we really needed to face to face discussions the client was invested in that so they made sure that at least quarterly we were all meeting up as a team I know that might not be as feasible as well going across country so I guess on different time zones what we would do or could do is look at what core sort of things are needed to be done together I don't think we didn't involve our UX and impairings in every single scrum ceremony with the scrum teams that's what they were doing before and we found that actually quite wasteful they were sitting on these long calls about bug fixing and they just didn't need to be on that their time could have been better spent so we isolated and started tracking which ceremonies would be most useful for everyone to attend and who those people would be so it didn't need to be every UX or every designer or every kind of sprint planning meeting for example but it was good to have a presentation there so I guess with kind of different time zones as well which I think is your question it's kind of isolating those course of points where you do need to get together and making sure that you arrange those times so that everyone can attend and there's lots of good tools you can use to have more interactive sessions I can't remember what it's called now but it's like an online whiteboard tool which we've used before to be a bit more sketchy about stuff so you're not just all on a phone talking against each other I don't know when there's a bit of a time delay etc so yes that would be my advice Thank you I guess just one last question Thank you for the session and I could relate to the dual track agile mode because you're following that in our projects wherein we have a team which is working on building and discovering the backlog for future PIs and there is a delivery team working on a particular PA so what my understanding was that this has to be at PI boundaries where the discovery has to be one or two PIs or releases ahead of the delivery cycle Yeah, yeah Sorry, was that your question? That was then, the other thing is we normally have a lot of metrics to track progress during the delivery cycle but do we have some metrics to track the discovery phase of it we have burned down charts to track the delivery cycle but what about metrics to track the discovery phase of the agile So I guess firstly we were I guess even though it's dual track you're not completely sitting like that in a sentence because you are feeding stuff into a backlog so there is a bit of staggering but we were trying to not make it a waterfall approach where we'd be designing and then handing off it wasn't that sort of process what we were trying to do is still get that interaction between developers and designers throughout the discovery process and throughout the development process so it wouldn't be necessarily that a developer would sit on every single meeting or whatever but we needed their involvement in that sort of assumptions, hypotheses you know, we're looking at features we're looking at solutions, we're sketching things you know, how will that work we needed the development input so although we're staggering off putting stories into the backlog we were still working together so a bit more sort of yeah, dual track will have been a separate track Sorry, what was your second question again? The second one was about metrics we have a lot of metrics for delivery Cool, so I mean we implemented Kanban and there's definitely a certain metrics we started looking at within that so our work in progress flow so how quickly things were moving through and we had limits on that so we'd look at where the bottlenecks were so we looked at some core kind of metrics in that process but I think the whole discovery process is about those customer outcomes and that's what we always what we always tracked against so we'll be delivering something in the end which did improve, did hit that customer outcome and with the outcomes based approach you're looking at these metrics as well, these measurable outcomes so you can actually track back and measure against it so it's about maybe conversion rate it's maybe about easing a pain point or just drop off like we had in that journey Thank you very much I'll let you go and enjoy your lunch now