Skip to 0 minutes and 1 secondIn the last video, we looked at the facets of our nature that make it hard to do Agile in practice. And in this video, we're going to look at how those things manifest into team environments, and how we can move from a bad place to a good place using Agile. If we revisit the blue button moment that Dana had here, and the not Agile version, she had too many tasks, too much emphasis on output. And she just decided, whatever, I'll cross this blue button off the list, and I'll move on because I want to go home.
Skip to 0 minutes and 32 secondsAnd in the second one, she said, I don't think this is going to give us the outcome we want, so I'm going to work with my collaborators on an alternative. Now, let's like sort of think through the things that influence Dana to have the one perspective versus the other.
Skip to 0 minutes and 52 secondsAnd we'll look at the first area is understanding a valuable outcome. So, in a non-Agile team, you're given solutions, make it look like this, make it work like that, so your understanding is low. What actually constitute a valuable outcome. And in Agile, those things are very specific. Now, that doesn't mean you're getting specific requirements or specs about make it blue, or make it red, or make it brown, or whatever, but you're getting very specific views of who this user is, and what their life is like, and what's valuable to them.
Skip to 1 minute and 29 secondsThe inputs you get are, instead of requirements, which are kind of diminishing as companies place more value on innovation, and less importance on big, long, supposedly reliable plans, our inputs have to do with narrative collaboration. Now, you've heard this phrase a lot. And in the next module, we're going to work on those things in a lot of detail, and you're going to practice them. But one of the centerpieces is the Agile user story. And their understanding of the user for a lot of the team in a non-Agile environment is low and distant.
Skip to 2 minutes and 4 secondsAnd you can test this with your teams if you think you're not sure where you are on this, talk about who the software is for with somebody, see what happens. You may be surprised at what they think is important. And it might be a really good exercise for you and the counter party to try that out, and see how it is. But in an Agile environment, our understanding of the user is high, we are close to them, if we're not observing them directly, we're seeing outputs that the rest of our team provides us to humanize them, and bring us closer to them. Here's kind of another example sort of how this look, it's like Dana the SQL.
Skip to 3 minutes and 18 secondsAnd Dana probably did a perfectly okay job of implementing the requirements she got, but they weren't very good at really fixing the problem or articulating what a fix actually means. And so, they end up with something bad, and our product manager or project manager is going to have to wait to fix this problem now because Dana is busy with something else. In the second version of this, our product manager or our project manager comes in, gives Dana more of a description of what problem is happening, and what do we need to solve. And Dana has been trained with our material here.
Skip to 3 minutes and 56 secondsSo she asks him for a narrative, and examples, and specifics, so she can see what experiences this user is having that are negatives so that we can work through, and they can fix them. She does not oblige herself nor does the product manager oblige her to make sure that nothing will ever break again. Now we would all love that, but the reality is, it's probably a much better idea for them to get a few fixes that they know are probably going to be good into the system sooner and in front of real users. Rather than just trying to completely perfectly fix everything, and take longer, and increase that envelope of uncertainty.
Skip to 4 minutes and 34 secondsAnd Dana has also instrumented some observation into that first batch she put in because she has a nice clear view of what constitutes success and failure. She's able to gather observations about that, and she's ahead of the curve now. And Pascal is getting what he wants which is orders are working. How do we actually do this in practice? Well, one technique that you learn as a designer is to diverge and then converge. So that means coming up with a bunch of ideas, and then narrowing down to a solution that makes sense. And the reason why this is important is that we're first focused on making sure we understand the right problem.
Skip to 5 minutes and 14 secondsAnd it could be any number of things, or there could be any number of dispositions, or descriptions of it that might kind of resonate. We want to expand those, compare notes with our collaborators, and then condense them down into what we think is focal. Then not only will that help us get a better answer, but it's a great way to exercise everyone's understanding. Then, once we really know what the problem is, then we do the same thing on finding the right solution. This is a technique you'll learn how to use over the rest of this course. The user story is a great place to encapsulate this.
Skip to 5 minutes and 48 secondsWe are say, focused on a reward, we know who our persona is, and we learn how to use that as a day to day centerpiece anchored in, some of these other items like personas. So, let's look at a few other areas about what might influence Dana. Well, one is that, she's probably has in the non-Agile environment, localized metrics. How many lines of code did you write, did you complete the feature that we described, and get it out the door? And in an Agile environment, we're hopefully looking at more teamwide metrics. Metrics that are tied to successful outcomes. For lack of a better term, I'll call this blame-iness.
Skip to 6 minutes and 23 secondsSo, if things go wrong in a non-Agile environment, there's a lot of blaming. In an Agile environment, there's a lot of examination of why did this happen, and let's just figure out why, and then let's figure out what to do next. Collaboration in a non-Agile environment is infrequent and rigid, and frequent and easy in an Agile environment. And we have a plan culture, there is a plan, we will follow the plan, our job is to follow the plan in a non-Agile environment. And we have a culture of experimentation in an Agile environment. We do things in small batches. We observe if what we're doing is valuable, and then we make a decision about what to do next.
Skip to 7 minutes and 3 secondsTesting and validation is integral to that cycle. So, doing things in small batches is good. It helps you keep from going too far off track, and you're constantly seeing what's delivered. And it kind of forces everyone to encapsulate and complete their work as they go along which is good. But to really get great outcomes, you need to instrument observation into the end of each of those iterations. So that you're asking, how would we really know whether this software is valuable or not. And just asking some random user, do you like this, do you not like this, is not good enough.
The Blue Button Moment
As you watch this video and listen to Alex explain blue button moments, think about some of these moments that you’ve either experienced or witnessed as you worked on a project. Once you’ve completed the video, then visit the “Share Your Blue Button Moment” discussion question and share one of your experiences with other learners.
© Copyright Rector and Visitors of the University of Virginia