147: Dan Roman and Richard Sheridan

Listen to full episode:

Joe Krebs speaks with Dan Roman and Richard Sheridan about using Agile Kata as a team process. Although not formalized, "run the experiment" is a common term at Menlo Innovations when they use Agile Kata-esque ways of working when they engage with their customers.

Joe has a book “Agile Kata” in the making, if you like to be the first to know when it launches, please visit www.agilekatabook.com.

Transcript:

Agile FM radio for the agile community.

[00:00:09] Joe Krebs: All right, thank you for tuning into another episode of Agile FM in the Agile Kata series. Today I have two guests with me, actually three guests with me. I have Dan Roman and Richard Sheridan from Menlo Innovations. We have Dexter with us in the background. He might or might not. Contribute to this recording as he's a dog, Dan is a frontline worker at Menlo.

He's a a lead, but he's also primarily a software developer. We're going to talk a little bit about Kata in development and obviously Richard Sheridan, author of the books, The Chief Joy Officer and Joy Inc. Is it fair to say you're the Chief Joy Officer of Menlo.

[00:00:54] Rich Sheridan: A chief storyteller is the more typical title they give me here.

[00:00:59] Joe Krebs: Awesome. All right. The chief storyteller, Richard and Dan, welcome to the podcast.

[00:01:04] Dan Roman: Thank you for having

[00:01:05] Rich Sheridan: us. Thanks Joe.

Good to see you.

[00:01:08] Joe Krebs: Yeah. Good to connect. And this episode we're going to focus a little bit on development. We want to talk about how do teams build agile teams? How do they build a product?

Here in particular software development products. Now, Dan you are, as far as I know from a website, your keynoting together with Richard there is, you have a focus on software for manufacturers of medical instruments and software for space researchers. So this is. This is I would say complicated, complex stuff you're working on and as far as I can tell and we talked about that during our visit in in Ann Arbor, where you guys are located, that there is no formal process like Scrum or Kanban or like to the book extreme programming deployed at Menlo Innovation.

Is that correct?

[00:02:01] Dan Roman: 100%. We have plenty of people who come and visit and we'll see what we're doing and find that what we're doing matches with one of their models. So we didn't set out to be agile, but agilists who come in say, Oh, Menlo is agile, or we have lean practitioners come in and they say, Oh, Menlo is lean.

But our processes, we never started from a place of. We want to be agile. Let's do it this way or we want to be lean. Let's do it that way.

[00:02:27] Joe Krebs: As you're obviously working with different kinds of companies and clients. And obviously also with different kinds of products you guys are creating. Now, I would be interesting because.

There is a term that's being used, I was told, on the floor at Menlo, this is run the experiment. That seems to be a frequent term. Can you just specify, either one of you, what that means, or maybe both, right? And how that comes into play, working in agile ways.

[00:02:55] Rich Sheridan: I would say, Joe, that phrase is born out of a background philosophy at Menlo that says, let probably pump fear out of the room.

We think that fear is a culture killer. Filler fear is a mind killer. I think there's a line in doom that says something like that. And so if someone has a new idea here, rather than. Hey, let's form a committee to write a policy on that. I do. Let's take a meeting. Our inclination is to take action with that simple phrase.

If somebody has an idea, somebody else might see. Great. Let's run the experiment. See what happens. And that can typically the things we try are on fairly small scale. We don't upend the whole place every week to try some new, crazy new way of working. But usually it is some small incremental change to an existing process or an enhancement to the way we do things here.

Because somebody believed that there was a problem to solve and this experiment may help us address that problem. Again, trying it and see how it works. And the experiments that succeed are the ones that last a long time and others might just thritter away because they didn't actually solve an actual problem.

Probably more often than not an experiment. Morphs over time. We had the original idea, we tried it, it didn't work the way we hoped. We try something a little different.

[00:04:23] Joe Krebs: So it could go into either direction. So when we talked about this a little bit about the experimental part and obviously I'm very public about my my work and my interest in Kata and scientific thinking through Michael Rother and Jeffrey Liker.

We, we met in Ann Arbor. And obviously when you hear the word experiment in connection with Kata , then it becomes, obviously the question is, how does this whole setup look like in Menlo? How do you guys operate? How does this all work? Do you guys have a product owner within Menlo? Do you guys have scrum masters?

Do you guys have project managers, agile coaches? What do people listening to us right now have to imagine when they just picture Menlo and cannot visit you guys in person?

[00:05:10] Rich Sheridan: It's probably valuable to know, just for your listeners, a little bit of background on what Menlo does for a living, where we make our money.

We are doing custom software development on behalf of our clients. So Dan has done a lot of projects for us over the years that he's been here. He will work in with manufacturing companies who are trying to enhance their ERP systems. He'll work with furniture retailers who are trying to improve how things happen on the sales floor.

So all these companies are coming to us because as Joe, everybody in the world needs software to run their businesses these days. And so we are bringing in clients from every industry imaginable to come in and work with us. We have a fairly simple structure to our team. The teams that Dan is a part of that are working on those various projects will consist of a project manager who is typically paired with we'll call it a product owner on the customer side of the equation.

And for us, the customers are the people who are paying us to do this work. They aren't necessarily be going to be the end users, almost never the end users. Software building. We have a set of people on our team that have a very fun and unusual title and a great role called high tech anthropologists, and their job is to understand the humans that will one day use the software, the end users in software.

Then we have our software development team, which comprises the biggest part of our company. And then Formal quality assurance role that works alongside the software development team. So every project at Menlo has some component of each of those four pieces. And and we work on a weekly iterative basis here.

essentially right sizing every project for exactly the workload, right sizing it with the types of people it needs. We're more in the discovery phase. There'll be more high tech anthropology. If we're more in the software development phase, there will be more people like Dan on the project. The project manager and the QA teams are shared amongst variety projects, and they are they are constant throughout the course of each of the projects.

In any given moment in time, we're a team of about 50 people. We have, probably right now, I'm going to guess about 15 different projects. at various stages. Some of the projects are large. They'll have 8 to 10 people on them. Some of the projects are small. They only have a couple. And it's probably worth noting that we pair.

That pairing is a big construct here. That was an early experiment that took hold in the 23 years ago when we founded Menlo. And it has never let up since.

[00:07:44] Joe Krebs: So running the experiment seems to be something like a, for testing and verifying the process in place, like programming, right? Is this an interesting, is this you have read about it, you, the teams might try it and find Found it useful, like many teams found their programming useful, right?

So it's an interesting thing. So you're using that kind of experimentation approach for the process you're using, but you're also using experimentation for building the products for your clients. And that's where I want to go a little closer here. So you have your how do you protect your end user, your users?

Your clients or your customers that are the product owner or acting out that role. If you want to say it this way. But then how do these requests come in? There's a ton of teams that are there that are using user stories product backlogs, ordering activities, refinement activities planning, sprint planning activities, and so on.

How does this all look like at Menlo? How do you guys incorporate that if you work in different ways? I would be curious to hear.

[00:08:42] Rich Sheridan: Yeah, the biggest starting point and starting is always hard for every project is starts with our high tech anthropology team and really attempt to answer three questions and use a lot of experiments to get to the answers to these questions.

What problem are we actually trying to solve different than perhaps the one even the customer presented to us? Who exactly are we trying to solve this problem for? What types of people? And we'll use personas and persona maps for that exercise. But a lot of that discovery work is done out in the field.

And so a lot of the early experiments are to be able to find these typical end users of the products we're working on out in the world. And that is often where some of the key experiments start early on. I'll give you a fun example, way back in our earliest days, long before anybody had iPhones or any kind of GPS devices, we were working with a company that wanted to create lanyard type devices that people who were on cruise ships would use to navigate the cities they would arrive in as the cruise ships pulled into port.

And so imagine they had around their necks, they had these GPS driven devices with moving map displays and that sort of thing. So we had to figure out simple questions like do people know how to read maps? Because, if you ask a group of people, do you know how to read maps? Everybody would say, absolutely, I know how to read a map.

If you ask people to read maps, you find that hardly 50 percent of people know how to read maps. And so it would be very expensive to try and do this on a cruise ship. We did get one cruise ship ride throughout the course of this project. But before that, we went to a local theme park here, locally here, just to watch people try and use maps.

So we would run into that. with them. We would walk up to them with a map in our hand and say, Hey, can you show me where the Edison exhibit is? And we obviously have the map in our hand and we would see if that people would grab the map and what they would do with it and how they would orient it. And 50 percent of the people said, Oh, I can never read these things.

See that circle I over there, the information booth, you should go ask them. So we found out right away that about 50 percent of people self report they don't know how to read maps. But this was really early experimental data that we could collect very inexpensively around what kind of challenges would people get to if they don't know how to read maps and we're creating a device that's supposed to allow them to navigate a city.

And we get very creative. We try and do things inexpensively. And then ultimately we experiment with the potential designs, often with paper based prototypes to see what will actually work for people. Once we get into the actual software development, once we've secured that we understand what design and work for them, then there's a lot of other experiments that Dan and his fellow developers here at Memo will use.

Sometimes those experiments are technical ones, technological ones. Sometimes it's most of the time, I would say they're often human ones because we were often working with developers. And our client sites, we have to figure out how to work with them, given the way we work.

[00:11:55] Joe Krebs: Dan I'm curious, like just to take it to the software development side and take advantage of you being here on on this podcast as well, right?

So it's a great insight to see business and the leadership of the organization, but also to see the actual implementation of these products, right? So let's say we're doing these visioning techniques and obviously as a. As Richard pointed out, there's a lot of cost savings finding out early on that people can read a map, right?

Could you imagine you were building something assuming they can read a map? That would be a very costly detour later on. But I want to go a little bit deeper because there's so many teams, agile teams out there that are preparing for sprint planning activities or iteration planning. And they're using user stories or and then they're basically have planned everything and laid it out and implemented.

You guys have through that experimental process, a different thing in place. I think it's much more lightweight, if I'm not mistaken. Can you walk the listeners maybe through once these requests come in and you're actually in the software development part of how you're still using experiments

for that?

[00:13:00] Dan Roman: Sure. So to as Rich was telling us about those experiments, it reminded me a little bit that every development iteration at Menlo, I would argue, is itself an experiment. So the beginning of the iteration happens after a show and tell, where the software development team will actually have the client or customer demo back to the development team the work that was accomplished for the previous iteration.

And then based on that demo we'll authorize the next week's worth of work which comes out to some 40 planned hours worth of work. And when I think about Kata, I think about declaring a desired future state. And that's ultimately what we're doing. When we set out a plan for the iteration, we're saying the plan is we will end up in a state where these cards have been completed and there'll be completed in this effort.

And then the rest of the iteration is the steps that we as a development team take to try and realize that. Future state. And then by the time we get to the end we'll basically start the cycle over again, which will again reminds me a little bit of Kata where we'll compare. All right, we started with a plan to get to this future state.

We've run the iteration for a week. Let's compare where we are compared to where we want to be. And ultimately, all of that happens through obviously the software developers doing the work, but that all happens through . The story cards, which are our fundamental unit of work and these are three by five index cards on which are written the work items that the developers will go and implement and our quality advocates will go and test.

And typically our high tech anthropologists are part of writing in the first place.

.

[00:14:28] Joe Krebs: Is there still like, are you pulling from an organized formal product backlog as so many scrum teams? are doing, or is this process a little bit more ad hoc and fluid based on the work you did in previous iterations where you're getting instant feedback from your customers and how does that all look like?

The show and tell, that's where this comes together, I would assume.

[00:14:50] Dan Roman: Yep.

That's a very good question. So it's a little bit of all of the above. So what Rich was alluding to at the beginning of our engagements, the high tech anthropologists will do a lot of the Upfront work of describing here's based on our research and our observational data, what we believe the application needs to do.

And that sets as a starting off point for the engagement itself. But over the course of every engagement, we are also discovering new work. So over the course of a given iteration, as the developers are doing work, they might write. They may write other story cards or the quality advocates may write some story cards or even at show and tell the client might may say, Oh, we didn't think about the fact that the user might need to do this certain thing.

One of the fundamental rules that Menlo is that everyone can write a story card. Now just because you've written a story card doesn't mean that it'll get authorized or that'll get put on a weekly iteration. But we are certainly collecting the scope that's being executed nonstop over the course of the engagement.

[00:15:49] Joe Krebs: How does maybe I love this story cards, right? Obviously, there is a story to be told and collaborated on as a team. How detailed are you? As teams now within Menlo, how detailed are you with the planning activities? Are you planning very ad hoc? Is this like in subgroups or pairs or how let's say, this, these requests are coming in.

You have these stories and you're experimenting, I would assume also on those. How detailed are those or all the questions?

[00:16:22] Rich Sheridan: Yeah. The important element of our planning that I think probably differs from many development teams is how collaborative it is with our customers. Number one, we're putting together at a high level a story mapped version that might map out a year or two worth of key milestones for this client broken down into achievable goals that might run.

Okay. A month, two, three, four months. And then we start laying out the story cards for that very first goal. And the customer is standing alongside of us choosing these story cards that should go into that plan. Obviously we're giving them some advice from a technical standpoint as to if there's a more appropriate sequence of things that makes more sense, but we really want the business feeling like they're driving this we often find it When we hear of other teams challenges in planning and estimating and that sort of thing, you often find that it's an adversarial relationship with the business sponsors, where somebody is I can't believe it's going to take that long, or you need to get this done in a shorter amount of time.

Our approach isn't to try and argue against the importance of a date or features within that date, but to simply argue with the data of here's what fits, given your budget, given your burn rate, given the team size we have. And then it's a question of, can we make responsible trade off decisions with our client to get to that particular goal?

And then, as Dan said, on a weekly iterative basis, we're going to review the progress against our original plan. Because, no plan actually holds up once it hits reality. So we're going to get, sometimes we get more done than we expected, sometimes we get less done. But that weekly visit into what exactly do we get done in the weekly opportunity to now look ahead in that longer plan and say, okay, what we've learned now, should we make adjustments to the plan?

Have we discovered new things that need to be done? Should we write story cards and estimate those story cards? Should we take some things off that we originally thought should be part of the plan in favor of newer, more important things? Collaborative planning happens on a week by week basis on all of our projects.

I think the most fun thing I see happen is that often we use paper based planning techniques, which is again, unusual for software teams to use paper. Typically in the earliest part of our planning, all of our story cards are on white paper. But as time goes on, and as customers start to get nervous that we don't seem to be making as much progress, we often switch to, say, hot pink paper for things that were newly discovered or that somebody raised their hand in a meeting and said, hey we didn't think of this when we talked to you about it originally.

And so we'll write that story card up, we'll estimate it, but when we put it in the paper based planning process, we make it hot pink. And over time, what you can see is The actual physical real estate of our planning sheets being taken up by more and more hot pink work Which essentially says hey, there was a lot of stuff for some reason we didn't discover early on Yes wrong with that, but let's at least acknowledge With this, these colorful pieces of paper that we are now three months into this project and 25 percent of the things we're working on are things neither one of us thought of at the beginning of the project.

That can be really helpful to maintaining executive sponsorship of a project because. Now we can have explicit discussions about new things that came in. It isn't some theoretical wave your hands in the air. There were a few new things that came along. No, it is clear what the new things are that came along because it's on this different color.

[00:20:18] Joe Krebs: Yeah. Creating truly a partnership, right? With with the business the clients in this case do to showcase this, right? And obviously as a client, I would assume they're all very happy with us to see that. They are late changes are being incorporated some way or the other, and

[00:20:34] Rich Sheridan: happiness is an interesting word in this.

So it would be fun to believe that the people on the other side of the planning table at Menlo have all of the power and all of the authority to make these changes. But typically they're reporting up to an executive somewhere that has some other budgetary constraints. . We're not so much trying to make happy customers out of this process.

We're trying to make informed customers so they can have intelligent conversations when they go back to their offices to say, Hey, I thought you were going to have all of this. What happened? And what you really want to do is give them the physical artifacts they need to be able to create a story. scale all the way up, perhaps to the CEO of the company to figure out why is this project where it's at right now.

[00:21:27] Joe Krebs: .

That's a good point. And thanks for clarifying. I think makes makes perfect sense. Dan Richard's mentioned the word a few times. I want to go a little bit deeper. That's the word estimates. Are you guys estimating there's a lot of different kind of estimation techniques out there.

Agile teams are using, I'm just curious with this approach where you're going into more experimental activities, if estimation is actually still a thing here, or if it's an, if so, how lightweight it is.

[00:21:58] Dan Roman: Sure.

So to start right off the bat, yes, we do estimate it's part of that weekly iteration cycle.

So every development team is sitting down and looking at the cards in play, as well as cards likely to be played in the future and estimating those story cards. That takes about an hour of time for regardless of the size of the dev team and we estimate in hours and in powers of two. So a given story card at Menlo would sit between two hours and 32 hours again on that power of two spectrum which can feel pretty radical for some organizations where things like velocity.

I know that's a very popular way to, Fibonacci numbers as a means of calculating velocity or t shirt sizes, another sort of abstraction. I think that there are a couple of things that necessitate, or at least why we as Menlonians prefer that method. One is because estimating in hours is a universal language that when we get to that planning game after the show and tell with our stakeholders.

There's no need to do any translation between 13 Fibonacci points or a medium t shirt size. We can say we've got 40 hours of effort for a given pair to plan for. And this card is 16, and that's 16 hours worth of work. And that's something that is instantly understandable by our stakeholders.

I think part of the reason that we as a team are able to do that and Not in all cases, but in some cases, why other teams choose those kinds of abstractions at Menlo. We have a very healthy relationship between the technical folks who are doing the work and the project managers and stakeholders who are authorizing and planning the work.

And that's manifest in this sort of contract. That's very explicit and part of, as I understand it, our project management training. There's a dual responsibility for maintaining our estimates. So any software developer pair that's doing work on a card. As soon as they know they're going to miss the estimate.

So if Rich and I were pairing on a story card and we were on an eight hour card and we started to realize, Oh, wait, this is bigger. This is going to be at least double that. This is a 16 hour card. Now we have a obligation to go out to our project manager, for example, Lisa, she's one of our PMs and telling her, Hey, Lisa, we are working on this card.

It was originally estimated as an 8, but because of these reasons, we see it as a 16. That's our half of the sort of contract. The other half of that is the one that lives on Lisa's side, or the PM's side, which is to say, Thank you for your estimate, and smile. And that sounds like a really simple little strategy, but it's That kind of strategy that sucks the fear out of the room that would otherwise inhibit Rich and I from volunteering that information or giving an honest, updated estimate on the card.

And that's why a lot of other teams can run into those abstractions is because it's scary or painful when you let some set of stakeholders know, oh, this thing we originally estimated will take a day is now going to take more than that. Yeah,

[00:24:59] Joe Krebs: well, there's definitely a lot of controversy out there about.

Estimation and the techniques and in communicated and sometimes they're so like inflated to o just to be safe, depending on what organization and teams you work for. So that's, does not seem to be the approach at Menlo and obviously you guys. I've taken an expert estimate on the work at that time and see what, what comes out of it.

Once you start working on it very interesting thing. Now you just mentioned that I want to follow up on that word too, because I think the listeners out there who are. Used to agile coaches scrum masters, et cetera, et cetera. They are probably not saying did he just say the word project manager?

Did he just use that term? And because that sometimes that is a term that has been removed and replaced and you guys are using it actively, as far as I understand what's the role of a project manager at? Menlo, if you're working so in so agile ways and in experiments and et cetera what would be the role of a project manager other than nodding and saying, thanks for your estimate and smiling.

[00:26:09] Rich Sheridan: So the primary role of a project manager at Menlo is to be the voice of the customer, people who pay us to do the work when the customer isn't in the room. And so their job is to answer questions from the development team about the general direction of the project, where it's going, how we're going to get there, what what the overall overarching goals for the project are if the cause, if the project manager doesn't know they will reach out to the client who isn't imminently available every time we want to reach out to them.

That's why we need somebody who's advocating on their behalf when the client isn't around or not available by phone and that sort of thing. The the other role important role project manager does is to help the team remove obstacles. Dan and his pair partner will be rolling along and a card gets stuck.

Have a question, need to reach out to somebody, you can just let Lisa know and say, Hey, Lisa, I just want to let you know we're stuck here. We wrote to the client. We're waiting for an answer. We're going to red dot that card, which means they're going to stop it. We're going to move on to the next card in the lane.

And if there's anything you can do to help remove that obstacle, that would be awesome. Project managers also keeping close track. Our customers are spending a lot of money with us, so keeping close track on the budget relative to the total budget relative to the burndown for that budget, all those kinds of things.

I guess there's a tremendous amount of, financial oversight that comes with every one of our projects, we're often working on projects that run into the millions of dollars. And so project managers are helping manage that part of the process with us. And you're also making a lot of decisions alongside people like Dan is to what should the composition of the team be this week.

So it's a very collaborative role for the people doing the work I mentioned before we pair, we switch the pairs every five business days and. over time, systematically rotate people in and out of the projects to avoid burnout, to avoid towers of knowledge issues, all that kind of stuff. And the project managers will work very closely with the team to figure out what would be the best composition of people who should pair with whom who who would be good candidates for these story cards, that sort of thing.

[00:28:27] Dan Roman: I think there's one element that's important too for Menlo, but I would also argue this is true of other organizations. But the roles and the titles that we have for the work that each of us as Menlonians do does describe a primary role. But that is not to say that the team is not responsible for also doing some of the other responsibilities of the other roles.

For example, I am primarily a software developer at Menlo. But on a day to day basis, I am contributing to the conversations Rich is talking about where it's planning the resources for the project, making sure that the customer is appraised of any changes to the plan or keeping in mind the decisions that we're making today and what impact that has on the end user, the way that our high tech anthropologists might be considering.

So I think it's one of those things where it's like we, we have those titles and those roles to an easy heuristic to generally describe what we do within Menlo, but at the end of the day, there's actually a lot of blending or blurring of the lines that exist between our individual roles.

[00:29:30] Joe Krebs: Yeah. I think that's also it speaks to the self managing aspect of agility in general. Now I'm so thrilled to have you both on this podcast episode, because we had in this Kata series so far, we had different topics. We talked about transformational cultural things. I, this is a and I think that's a really great, wonderful episode.

I believe it's a wonderful episode that really focused on Developing in agile ways, but in a non prescriptive or existing frameworks. That are out there and you can almost say like, when I listen to your conversation. It's almost it's almost sounds like cherry picking, right? Of how we're using this concept, or we are estimating, but a little bit different, or we have paper, but some of them are pink.

And and so what I and working in pairs and we're shifting pairs and the way of how you operate with clients rather than the product owner being in house, the product owner is the actual client. So there's a lot of things. So there are some terminologies or project manager, just to name another one versus a scrum master.

And what's really fascinating, I think, is for one of the goals of this episode is to show existing Agile teams if something's not working with an existing framework or with the process they have chosen, as you guys said, run the experiment, right? Try something new. Adjust your process. That's one element.

And maybe you find ways of changing the way of how you currently work with breaking something. Obviously, that is recommended, but you're saying it's not working for us. That's not us. And that would be whatever you shared about. Menlo and the culture, but there's also the way of using this way of working to build the product itself, right?

So there's two aspects to it, shape the process, how you want to work, but also the way of how you build a product for your clients. So I want to thank you guys for that. That is really nice. Thank you.

[00:31:22] Rich Sheridan: You bet. Yeah. I think our general philosophy is all of these tools, methodologies, ways of thinking have value to offer and why would we constrain ourselves to simply one of them?

Why don't we borrow pieces and parts? And put, I think for us, we do refer to our general system of work here as the Menlo way of working. . And but if you probed, you would see we borrowed all these pieces from this so we don't find ourselves resisting any of them. We find ourselves embracing them, looking at them deciding, oh, that might work here.

And every project has its own unique, qualities to it as well. I

[00:32:02] Dan Roman: think one of the pieces that reminds me of is the notion that when we're designing our process, we're setting out to solve a problem and our problem isn't that we're not doing agile. It's not that we're not doing scrum and we need to start doing scrum.

We're trying to provide value to a customer on a frequent and consistent basis such that they can respond to feedback and make planning decisions. There are times when that desire or attempt to solve that problem will line up pretty closely with what Agile might seem like or Lean. But at the end of the day, it all starts from let's solve a problem and the absence of some predetermined process is not itself a problem.

.

[00:32:42] Joe Krebs: Yeah. This is, that's wonderful. And then maybe a good word to end the the podcast episode here together. And obviously there is. An opportunity to take a tour with Menlo and see that all in action. So I invite the listeners to go and reach out to you. There's a, there's tons of tours you guys are doing on a yearly basis.

Ann Arbor is the place to visit in Michigan. And and then they can see all what we just talked about in

action.

[00:33:08] Rich Sheridan: And one of our experiments during the pandemic were virtual tours that we continue to this day, even though. The in person tours have resumed. ,

[00:33:17] Joe Krebs: even cooler. So this could be done just from your couch.

Thank you so much.

[00:33:22] Dan Roman: Thank you.