 Yeah, okay. Hey, welcome Today, I'm Aaron Sanders today. I'm gonna be talking about how to learn faster and how scrum has this compatibility with Hello with things like lean UX lean startup design thinking and other discovery elements are Really what this is known as as well as dual-track scrum A term that Marty Kagan Jeff Patton and others use quite a bit It was started way back when With Desiree C. She worked at a company that was acquired by Autodesk and at that time Autodesk was very waterfall the company that she worked with was using scrum So she wrote a paper to describe how they were Using both design and delivery inside the same sprints. So there's this Track of development alongside this track of interaction design So designers are really working kind of at a sprint in minus one level feeding that design into sprint in That would implement those designs and those that kind of feeds forward into what gets tested in the next cycle So in one cycle where both coding what happened in the sprint before and doing some design testing for what's about to happen next So here is the scrum framework. I want to quickly walk through but show of hands. How many people know scrum Excellent I keep your hands up if you're using scrum Keep your hands up if you are developers on a scrum team Okay, and our shipping code potentially ship a shipable code at the end of every sprint All right, and talk to users every sprint All right, a couple of hands one up in that last one So maybe a couple of opportunities for those using scrum first and a lot of our talks have focused on this I've noticed different speakers of really Shipping code always be shipping so that's probably the first opportunity for us and then the second one that I would like to Invite you to consider is how to get in touch with and talk to your users every single sprint so I won't spend much time here with with the the Scrum framework right we have a product owner owns this product backlog Triangle-shaped because things down at the bottom here can be big and vague They don't need to be so detailed out and then we work with the team here to refine the backlog Ahead of the sprint which of course makes that planning meeting so much much better And that's really why we've extracted away this backlog refinement is as a pre-planning event Make sure the top of that backlog is really airtight Then we have a sprint each sprint is the same length different organizations use different lengths It seems these days the typical length is two weeks But somewhere between one and four it was very radical when scrum started to ship product every single month And that's what they tried to do now Of course, it's radical to ship product every 10 or 11 seconds Which is where places like Amazon comm and Etsy and others in the continuous delivery model are getting into So at the end of course, we want to create these right this potentially shipable product or WTFs Working tested features of course is what WTF stands for Review retrospect and then we go back people don't know what they want until they see it So as we check out check out these working tested features It feeds back into the shape of our product backlog and how we're prioritizing that feeds forward into what we're building So that is all what I would consider the delivery cycle of scrum with dual track Then if I zoom out just a little bit, we're going to add over here to our product owner Some people from the team now have to do some double-duty We have a developer and a UXer that are part of this cross-functional team Also working with our product owner to think through what do we need to learn? What do we need to discover make sure that not only are we building the product right, but we're also building the right product So there are some things then that we can add on embellish our scrum framework with these discovery items and We have things instead of a static Roadmap more of this opportunity backlog so trying to add dynamism right up to the front with with how we approach these ideas these Identifying pains of our users and applying remedies keeping that very dynamic doing some user research building up story maps ideating through design studios Sketching personas doing user validation on right fidelity prototype. So Bill Buxton. He's a UX author He says there's no such thing as right and I'm sorry There's no such thing as high and low fidelity only right and wrong fidelity depending on what you're trying to learn We try to measure if we're building the right product with these key performance indicators KPI's Also known as okr's objectives and key results So people once again don't know what they want until they see it So as people are working with these different prototypes and as we're learning from them What's important that feeds back into this opportunity backlog now with different companies that I've worked with Go back to them and and ask how many of these Opportunities actually move forward and to a sprint or onto a product backlog any guesses What percentage of work actually moves from opportunity to product backlog all of them? Not much So from many to a few. Yeah, usually less than 50% so a really high amount would be around 40% So that's really why we want to think about instead of having this static Year-long roadmap that usually drains out over the year and then the end of the year We fill it back up for the next year is trying to keep this really dynamic And as we learn something doesn't have user value How to shift how to pivot away from those items into those that we think do have much more value So when we create this this this cohort this collaborative balance team up here It's really we're looking at answering three different questions with discovery So we want to find the middle of this intersection of what is valuable. What do people want? What is usable do they really love this experience and then what is feasible? Can we really reasonably build the solution given the people and the time that we have? So valuable for me is really this thing of what do people want to buy or use? And so we don't go out and ask them directly Hey on a scale of zero to ten, how likely would you be to use this feature if they're in a grouchy mood? We'll say one I don't want to use it and if they're in a really happy mood and they want to please you They'll say I don't know like an eight or a nine. There's usually not really a lot in the middle, right? We're asking them to speculate so we don't ask these questions directly We usually find some oblique ways to find these answers people want it because they use it So it's valuable if people are engaging with the solution now sometimes the experience gets in the way of that I was at a place that has a Movie festival and you can buy these tickets But when I went there the movie festival was sold out yet independent movies were still available So they had an application that you could download and find which movies were still still had tickets available Sadly it was listed in alphabetical order and then if the movie was sold out Strike through through the text so I'd have to scroll until I found a movie title That did not have strike through and then it would say playing Tuesday. Well, this is Wednesday. That does me no good Scroll find another one. Oh, that's playing fries Friday. It doesn't mean no good So I abandoned that app. It was something. I really wanted I had I needed that information I thought that was valuable for me, but the experience itself got in the way so I abandoned the application Creating this cross-functional team of product discovery or product ownership We really need to think about then how to collaborate. I find this is one of the weak points in strumb, right? We have this what sometimes called the single wringable neck of the product owner to eliminate competing priorities And it starts to maybe strike of being anti-collaborative of not being so cross functional we get one person from the business and their opinion matters most So we're trying to assemble a team now that can really think through these problems And they have to know when to stand forward and when to stand back, right? Our product owner really knows the park it what people would find valuable user experience here and dove over here so one way to make this work comes out of the fifth discipline guidebook and It really talks about the time and the skill that we have available For work so if if we're low skilled in Leadership and don't have a lot of time we tend to tell people what they do or sometimes we yell at people what to do Little higher up we sell people on what to do or we test or we we consult and collaborate at the very top We co-create now seeing singe says the only way to get into consulting collaborating and co-creating is through mutual Purpose so really understanding together. What makes something valuable usable and feasible and that Dance then really collaboration and that next door is the dark arts on collaboration is really sharing an experience It's messy. It takes a lot of time. We need to see some divergence We need to hear about the conflict and the diversity of opinions Why to share an experience let go of our personal agenda and really start to share and understanding and Gain that mutual purpose together So if we don't for instance if we just get together meet talk through and sign off on requirements We might unfortunately have a different picture in mind So if we find some way to visualize that which I also find is a large part of collaboration We can see those differences in opinion We can talk about it manipulate that visual model and since we all bring different ideas and perspectives And we wind up with a much more sophisticated picture Then we leave with that same picture in mind and so that collaboration shares that experience So we can have that shared understanding that mutual purpose When we start with this opportunity backlog we can start to model out our opportunities This is a derivative of the lean model canvas, which is of course a derivative of the business model canvas It's somewhat of a paint by numbers approach In the middle here at zero position leap of faith assumptions What would cause unrecoverable failure if true now really it's hard to start there So we tend to start here in the solution idea in the problem space now They're both in the number one position because even when asking people to say hey, can you can you help me see? What is the user problem help describe that detail it out? They tell me about the solution So we have to tease apart then that solution from the problem So we tend to go back and forth really quick They're very tangled up try to tease apart that solution. What problem is it really solving once? We get through that then we talk about users and choosers who's affected by that solution who really has the problem Now sometimes we have both an end user, but we have to get past the chooser first So I give you an example motor-roller mobility that I worked with One of their choosers one of their customers would be something like Verizon one of the carriers Once they sign the contract with the carrier then they get access to the end users those consumers So difference between the chooser and the user need to think through both when we're coming up with these opportunities Now they usually have some way that they work today Somehow they get to this goal Usually these solutions aren't so new and novel and innovative. We've never seen them in the world before So how do they do that today which should lead right back into these leap of faith? assumptions So working with a hotel chain the CEO spun up a scrum team and said look our Members are getting older. We're not gaining new members. We need to attract millennials They seem to really like their mobile phone and the apps on it tell you what let's build an app for these people a check-in Check-out app and we were thinking through different leap of faith assumptions We knew the user value would be well They wouldn't have to stand in line anymore for check-in right they could just immediately go to their room if they have this Application to check in so a user metric would be less people in front of the desk less time taken So we did a lightweight amount of user research We basically went to the front desk of a of a hotel watch people check in and they had that v8 moment They're like, there's that there's that assumption apps not worth building Any any guess here? I had you guess on the opportunity any guess what the assumption was Why do you go to the front desk of a of a hotel That's it. So what how could we have a? Application replace the necessity to gain a key from the front desk So that made this whole thing invalid. Of course the CEO said yeah, that's cool. Keep going He went to the board and got some more money and they you know You have these keys that you can now touch to the lock that opens the door So they figured out how to put that into the application and to go through a bunch of different properties To rekey the whole thing so he had to add a couple of zeros to this opportunity to make it valid now All right, so once we really have that opportunity down and we share an understanding We're literally on the same page of the idea of what to build and what problem it solves Who's it for and how do we measure it? We can start to do some user research So I gave you an example of that of going and watching people at the front desk Here's another one from a company called the weather channel So they're going out and you might notice they just have paper in front of them They don't even have a prototype. They have nothing except for questions They're trying to find out from from this subject What's important to him about knowing if the weather is right, right? This was a big question I'm a don't know if you notice from my laptop. I'm a skier. I live in Colorado. You asked me what's great weather I'm gonna say to feed a snow and just blizzard everywhere. Love it. Let's go, right? That might not be the kind of weather you think is good. So they're interviewing people to find out Where is their critical mass? What do people consider great weather for being outdoors? After we do some user Research or alongside of it we can start to build a story map This is from Jeff Patton if you haven't read his user story map book yet. I totally recommend it it's really a Model that we lean on from user-centered design and user experience So if you know journey mapping or experience mapping, it's that same sort of thing now We're applying it to user stories so we can understand what's important to the user and start to journey map that out Start to map that out and instead of having this one dimensional product backlog We add an extra dimension to it So going across the map across this way is the workflow of how to work through it going this way our Alternatives or different levels of necessity in each column now. This is a story map from a medical Company and they build a robot and this robot is in a cage with this this person Alex the packaging tech And so Alex is managing this robot to put large bottles of Medicine and the small boxes putting them up on shelves to ship off into the pharmacy So the company built this this story map and it keeps going a long way And they asked me what do you think about this? I said well first off tell me what what are all what are the different colors and what are these marks? Well yellow or the tasks Red our problems blue our questions and this is actually green our ideas and I'd said okay, well with that what I see is It's a long workflow Alex has to do a lot to manage this robot And it seems like starting it up is a bit of a headache Yeah, that's pretty much it so they collaborated and built this visual model and shared an understanding about maybe where to focus in On building prototypes or improving their product The story maps we can map out our current product So if you're doing something like a sales force Integration is how do all of your systems work now? We can dump that out spray that up on a wall and see that and then think about how are we going to change that later? What is sales force going to do for us? So we can use color to talk about things we might need to add with sales force or some sort of color or shape To show what we're going to take away from these different systems for an integration like that With story mappings, then we of course sketch personas we're really trying to be in touch with our user here and We can do a design studio So this is once again back to the weather channel and all of this stuff Even though we're trying to create a product owner team is meant to be highly collaborative This is a whole team approach So we have people leading on and helping us figure out what we need to do to find these answers And as a team we we find these answers together So in this design studio, they're thinking through a new Hurricane tracker right some sort of place where we can go and see when the weather is really bad And so here's a front-end developer next to the UXer next to a QA person next to a developer and off Off the picture. There's also the product manager and even the scrub master is sketching on this It fast sketch for about 15 minutes share those results with each other Then use that information for another round of sketching. They would do this about three or four times So remember collaboration would we diverge to converge? So in the first round of the design studio highly divergent Right another great thing about collaboration is start independently So we made sure we had enough information that each person could sketch But not so much information that we're biasing each other So each person could lay down their thoughts and ideas and then after everybody did that We would collectively share out and then we saw a couple of rounds of divergence Then we started to see that convergence and when they really came close together then we thought okay Here's an idea to prototype and not all the time through design studios do these ideas Combined so nicely and that's okay. Remember one of the lean principles is Deliver fast decide late. So if these ideas are not completely Compatible, how do we take both out and figure out how to test these ideas for our users and have them help us? Decide what's most important one of the best wins that we had at the weather channel was going from the stakeholder saying I think to them saying users say and using empirical evidence of what they were gaining from the market To help figure out how to make solutions and really leaning on the team to find the answers from those users Of what the problems were and the right solutions to apply So this is the team figuring out what's important in this hurricane tracker not it being handed down from some stakeholder from above These Design studios run a lot better if we can figure out some way to stretch past what is Probable and into what is possible So a prompt that I'll use for this is what would you make if you didn't have to make it work and I gratuitously stole it from This this post right here and uni. I can't remember her last name, but uni came up with this So I asked people to include Technology that doesn't exist in this world today can exist in a different world or in the future or parallel universe But something we can't actually make today to try to get past this this probable into even the impossible and then snap Back into a preferable kind of solution not just the mediocre status quo solution a Lot of people talk about minimum viable products Here's a pro tip for you if you want to make that viable product Smaller more minimum figure out ways to minimize your market first So it really means a lot of interactions with the users to figure out who do we super serve Probably going back to weather again not me as a skier for great weather Maybe more the golfer that for for the good weather So we really want to think about the user that's most affected by the solution and the problem they have So try to figure out ways to minimize that market for that first release and every release for that matter after that So with all of that we can do some user validation with right fidelity prototypes Well, we with weather channel is pretty easy because we could go out into coffee shops and do coffee shop testing Right consumers are all over the place Are affected by the weather but really we need to go to wherever the product is used So if it's an internal IT app go to those people that use it if it's a sales force integration Let's talk to sales about that about what they need right so but instead of bringing them to you You go to them watch them in action. See how they use your product see what they're doing They'll just do things regularly and routinely and you're keeping in the back of your mind Wow, that's a really crazy work around they're doing we should should really focus on how to solve that problem for them Over here are all prototypes that got tested with the market So even here this whiteboard is a prototype So this was the right fidelity for them to test in the beginning. Why they sold a Multi-million-dollar contract across network and web and apps to show the weather on your route to the airport is called a business traveler app and Immediately in testing this in just the whiteboard so they found out people don't really care about the weather to the airport There's other apps that take care of that They know to add more time with the weather is bad to get to the airport what mattered more is People that commute more than 10 miles I guess that's like 16 kilometers to work and if the weather is changing on them on their way to be able to find an Alternate route to work. So this was the right level of prototype to find that out Once they got there they could move in to more of a balsamic look and dial it in dial it into a clickable prototype with animation and then finally even this is a prototype that Takes barely any work to push into the app store Also somewhere in here, too is you can really start to certify with Apple the application Pre-release and even make it easier for you to get that certification for that app release Key performance indicators there's all sorts of them tell you one of them that they had when I walked in there Was unique views unique views was very important. However, what are you doing? That's a vanity metric What are you doing weather channel to affect UVs? Well really nothing because when the weather is bad UVs go up so we had we try to think about the kinds of Indicators that we actually have control over and here's another pro tip Think about the kinds of indicators that will maximize outcome and impact So if we start with the world as it is now and we think about people with different You know, they're sad have some pains or maybe they're confused or downright angry We come up with some sort of idea. We call it a product a feature Specification or this is kind of a dirty word with agile requirement, right? Required means just be quiet Get out of here read the manual. Why are you talking to me? But remember we want to collaborate We want to try to get to a shared understanding of what to do Once we have that shared understanding of the right idea We start to build it and deliver it into the world later. Now many people will measure this delivery as Success, but once again if people aren't using it. How is that successful? So we really want to think about this anybody happy now have we changed an emotional state? Have we changed user behavior? Are they are they saying this makes my job so much easier? I love this. I totally know when to golf now, whatever else I'll be warned There might be some people that are still ambivalent or angry But you might notice they're outside of that that design target for that specific release The trick is not to build software The trick is to figure out how to maximize the outcome how to change your user behavior as quickly as possible What it actually means minimizing the output So the biggest return on the smallest investment Very infinitesimal amount of investment to lay down some squiggly marks on a whiteboard and put that in front of people and say Hey, does this help you get to the airport better and they say why do I care about that right without building any code at All is figuring out. What's the important outcome for people? It's figuring out if the weather is bad on my way to work when I have a long commute Although this stuff all this scrum stuff comes from this thing called the new new product development game now New is doubled up because it's really a new game for new product development Now the old game is called a relay race, right? We do all a phase one take a break do all a phase two Some places overlap their phases a little bit Jeff Sutherland one of the co-creators of scrum called scrum type C process all phases at once That's why it's called scrum. It's a rugby approach not a relay race handing off But a multidisciplinary hand-picked team that works together from start to finish I say that because not all only are we talking about phases at once like design Develop and test but also these phases of discovery and delivery How can we do both in a continuous fashion on our scrum team? So discovery really is a design thinking process We're gaining empathy with our users by talking to them. We usually have some sort of framing for a problem Like commuter weather app But as we talk to people that problem widens out So we need to narrow in and redefine the problem somehow with some sort of thing like a design studio Then we start to flare out again as we ideate and come up with solutions that we prototype test and figure out Which one or two of those prototypes are really bring forward into the world? From there, let's look at this idea of discovery and delivery then like I was saying they should really be continuous as we discover We deliver and as we deliver we discover now really that's building and learning side by side So that sounds a lot like this lean startup idea of building code Measuring data and learning ideas to build now Eric Reese called that lean part of lean startup for cycle time He would talk about going through this cycle in the order of 50 times a day Right so really trying to decouple the learning from the delivery learning very fast going out and getting in touch with your market Frequently several times a day if not several times a week So now if I zoom out it gives you kind of this whole picture then of the dual track discovery and delivery Another tip here is in this sprint planning meeting is start to talk about what do we need to build? What do we need to learn? Do we need to talk to users? Do we need to update our story map? Should we do a design studio? Do we need to create a prototype so we start to add those things in during sprint planning and get them on the sprint backlog? So once again weather channel I talked about them because they let me We would then say of Friday every Friday. We would talk to users So one hour times seven people a task talk to users seven hours And just put that on the sprint backlog so that we would make sure to commit to both the discovery and the delivery side Then at the daily stand-up we basically go around the the circle twice first time What are we building? What's getting in our way of getting things done and built then? What are we learning and what's getting in the way of what we need to learn? And in between sometimes some people would say you know what I'm not going to really be on the discovery side So today, so I'm going to go back to work. You continue with that stand-up Then at the end of the of the sprint at review not only are we looking at these WTS the working tested features But we can start to look at the artifacts of what we've been learning. We can look at these prototypes idea says If a picture is worth a thousand words Prototype is worth a thousand meetings kind of goes back to what Dave was talking about this morning Instead of writing all of these things down on cards and user stories and pumping them into your tool is Figure out ways to talk to your users have them narrate that product story and figure out ways to illustrate that story via prototype and Different visual methods. They're a lot richer than just something as a user. I want to so that written on a card Well, I guess that's about it. I want to thank you for your time This link here actually goes to a drop box where there's all sorts of materials Resources method papers on how to do things like run a design studio or do story mapping And then as you start to really kick butt with this stuff I'd love to know so sit drop me an email or give me a text message Let me know how things are going with all of this stuff and with that. I'd like to open it up to questions Yes in the front. We have a microphone for you. So you have to pause for a second Just a question because you started about those KPIs you're often using the weather channel examples so other than user views what KPIs that you come out with which will actually check on happy users Yeah, a great question, and I can't really disclose that but UVs are like, oh, we can't do anything to increase them We need to come up with a different KPI. I will say that instead of five KPIs They came up with one and that one was measured across all of digital. So product development QA everybody have the same one measure As a pity you can't disclose it. Pardon. I can't disclose it though. I'm sorry Back over here Hi, I have one question just now you mentioned about the user research using the papers I believe it's some type of paper role-play and prototyping Like is usually work well for the commercial product. No Consumer product. That means if you want to know how it's the customer's response but I just recall some of the you know the subsystem use in the you know the Enterprise solutions like logistics or something or even ERP. There are a lot of Workflows and the tons of alternatives How do you deal with this type of a complicated system because I think even in the industry people have thoughts about how a gel can Apply well for the you know the enterprise solutions or complicated systems. Yeah So part of user research is doing both qualitative and quantitative research So the qualitative is usually low in numbers of people we talk to but high in that subjective quality Where we figure out why people are doing what they're doing the quantitative very high in numbers and high in numbers of people Right, so the instrumentation that we have inside the product in any analytics So we can figure things out like that and even with this consumer app One thing that they saw is when they talk to people everybody says I love the map I love seeing how the weather moves over the map, but then Quantitatively when we looked at the analytics nobody's clicking on the map area So it told us what right? It told us that that that People were not clicking there, but it didn't tell us why and as we tried to figure out why they told us I love the map through some twists and turns we learned that People more associated map with something like Google and they associated radar with weather So just a switch of the term from map to radar Increased the usage in that area by 20% But even with and I would see with these big solutions ERP solutions internal Users are much more friendly, right? It's easier usually to find a qualified user and they're more willing to talk to you because they know you as a colleague So being able to get in touch and talking with them usually is actually easier with these are no internal applications And usually easier to have that quantified Instrumentation that we can analytics we can look at as well. So both of those are user research Looking for other hands any other questions Yes, you have to yell out or wait There it is Okay So I'm Currently we're currently trying to do something which is more or less similar or at least I can recognize certain things Do you have any maybe any ideas of Good team sizing especially on the UX part Yeah, that's that's a great question, you know overall We have this seven plus minus magic number really for communication channels, right with seven people We have we're tracking kind of 21 open channels. So if we have You know 21 people we have 210 open channels. So that's probably too big. That's why we use this this magic number So for instance at Motorola mobility, we had one product owner, but we actually had two UXers So there was a visual designer alongside an information Architect and then a user researcher was more consultative She would come into different teams over time But we actually had two people from UX on on each scrum team And then there was anywhere from five to eight between developers and QA No scrum masters For whatever that's worth. Yeah a question back over here It's a pass the mic Keeping our volunteer busy here. It's getting good exercise. Thank you I'm not sure I heard it that but you say you put to people to UX people for each scrum team for each scrum team How many UX people you have millions no there was Yeah, there was I think overall at Motorola there was 9 or 10 scrum teams so we're talking about out of customer experience which a Motorola mobility was hundreds We had I think a dozen from UX that were embedded full-time on these scrum teams Okay in my reality Which is doesn't have many UX Experts yet, so we usually have zero to one US Expert, how would you recommend how we do this? Well, so Kagan says You can have one UXer on two teams or half half the UXer on the team But in that case I'm going to want this half You know part of it is context switching right if I have to be on two different teams doing two very dissimilar things I've seen research that shows like they've done done MRI analysis your brain literally atrophies And you have the cognitive ability of an eight-year-old so Switching around we turn everybody into primary students right so that's one reason to focus of course We don't always have that luxury With with the user researcher right there was one of her for these 10 or 11 teams I forget exactly how many now so she didn't apply her time to any one of them She had office hours for these different teams and they would leverage her as necessary to then upskill That user research ability on these teams, so maybe if we don't have enough UXers It's about upskilling and helping the rest of the team gain some amount of ability to take care of of the experience of the product Thank you Looks like We are out of time, so thank you very much for attending. I appreciate it Yeah