Welcome to the home of The Bureau Briefing, our very own podcast. Each episode, we talk to a member of the Bureau of Digital community doing awesome, inspiring things. Check in each week for a new episode with your host Carl Smith. 

Be sure and find us on iTunes!

Episode 022

SHOW ME THE MVP!

with Natalie Warnert

Developer turned Agile Coach, Natalie Warnert joins us on the Bureau Briefing today. We talk about the need for flexibility in agile and moving from a prescriptive to an effective approach. We touch on how design fits into an agile process and how the language we use can make all the difference in keeping a project moving forward. We'll also address the question, why aren't more women involved in agile? For more information on women in agile, go towomeninagile.com or nataliewarnert.com. 

Are you a Digital PM? Join us in San Antonio for Digital PM Summit 2016!

Transcript

Announcer:    
Welcome to the Bureau Briefing, a podcast by the Bureau of Digital, an organization devoted to giving digital professionals the support system they never had. Each episode we're going to talk to a member of our community doing awesome, inspiring things. Now for your host, Carl Smith.

Carl Smith:    
Hey, everybody, and welcome back to the Bureau Briefing. It is Carl, and with me today I have got Natalie Warnert.
How's it going, Natalie?

Natalie Warnert:    
It's going good. Hi, Carl.

Carl Smith:    
I know that you're going to be at the Digital PM Summit in San Antonio this October, and I'm excited to see you get up on stage. When I was thinking about this conversation today, one of the things that really struck me was you were a developer, and now you've taken this turn to being an Agile coach. Share that story with everybody. How do you go from being a developer to being a coach?

Natalie Warnert:    
Yeah. It was an interesting story really. If you would have asked me six, seven, eight years ago what I would be doing right now, it definitely wouldn't have been this. I don't even think I knew this particular job existed then. Even going into college, into undergrad, I had never even thought about being a developer. I went in with the mantra, ""Ah, I want to be in business, and I want to work at one of those big towers that I've seen in Minneapolis or the other big cities. I want to work in the Skyline Building."" That was as far as I really got. I somehow meandered my way into information systems and came out with a business degree, majoring in information systems, which is a little bit different than computer science. Management information systems people are calling it now.

I landed my first job as HTML and CSS developer. I was working on website development, doing some Java script, doing some jQuery and then all the other styling and really didn't know how I got there. I did that for, oh, about a year, year and a half. The funny thing is looking back in retrospect now, we didn't call it Agile at the time. I know a lot of people say that. We weren't calling it scrum, but I can now see outlines of some of the ceremonies that we were doing. We were having a daily scrum. We were having meetings with our product donor. We were doing actually a little bit more of a pull system similar to Kanban. I was spending my days taking tickets and fulfilling those tickets, writing the code, doing actually a continuous deployment type thing and getting things out on the website and updated very quickly.

 The particular company that I was working at was Travelers Insurance, and I was in a program called the IT Leadership Development Program. Part of that program was to move around to different areas of the company, try different roles and really learn the entire business and learn all of IT. After that developer role, I went more into project management, and that was where I really got more exposed to Agile and realized, ""Hey, we were actually being fairly agile on this web development team. I really like this."" I also realized I'm not an amazing developer. I liked the solving problems, but it didn't really strike me as a thing that I wanted to do for the rest of my life.

I really was into more of the process and the human aspect. That made me transition more into that project manager role, which then transitioned more into scrum master, and then after scrum mastering for quite some time, really got more onto the coaching side and working with a number of scrum masters and really looking at the overall process across multiple teams instead of just the one particular team that I was being a project manager or scrum master on.

 The transition sounds probably fairly simple and quick, but it was anything but. There were definitely a lot of hurdles and a lot of things to learn. I'm still learning new things every single day. Yeah, that was where I started, and here's where I am now. I'm really not sure where it's going to lead me in the future, because I never would have imagined myself right here.

Carl Smith:    
Here you go. You started off as a developer. You learned what it was to be a developer. You understand the language. You understand the time it takes, which makes you a perfect candidate to then go on and help people who are doing that and then help the people who are helping the people; right? It sounds like that was the progression.

Natalie Warnert:    
Yeah. It's been a really helpful skillset to have. Even just those couple years that I was a developer, I can relate to a lot of the things they're going through. I understand how stressful releases can be from the development side. I understand how hard it is to test and the frustrations that come with infrastructure being down or infrastructure that's not working the right way you want it to. That really helps me to be an effective coach, because I can speak that language. I can empathize, because I was really there.

Carl Smith:    
It's interesting what you're saying about doing the Agile stuff before it was ""Agile"" with a capital A, which everybody loves to say, "Agile with a capital A." A good friend of mine, Jack Skeels, he was doing Agile back in the late '80's, and he was saying that that wasn't ... I don't know that that was the terminology, they had some of it, but then it starts to form, it starts to become a thing. Now you have all of these weird offshoots with Fragile and WaterFAIL and all this kind of stuff. I really think a lot of it's based on the context of what you're trying to accomplish. Are there times when you're there and you're meeting with people and you realize you have to go off-course from what Agile would say?

Natalie Warnert:    
Definitely. We have a few different camps. We of course have the camps that are divided by method or, I guess ... I don't know. I don't know the word I want to use. You'll probably have to cut this out. We have the different camps that are divided by, ""We do scrum, and we're into Kanban, and we're into lean methods and we're doing XP. We're doing this."" There's those, but a thing that a lot of people forget about is we're really trying to base it on a set of principles here and how are we developing better, not necessarily what practices we're using.

It's what things are we doing to support the principles. Those practices can be anything.

The other thing I like to say is that it doesn't mean that we should be knocking the other ones, whether that be Waterfall or someone who's doing scrum or someone that's doing a lean-ish thing. Everything had a place at one point, and, yes, we found ways of working better better, but the thing that I realize, especially in running Agile transformation, is that we can't possibly expect people to just flip the switch and do everything one way. One way's not going to fit for everybody.

I think the way that we're moving is going to more of a pick-and-choose style, where ... Someone called it an Agile buffet, which I really liked. Maybe you pick your lettuce and you pick some chocolate pudding, and those don't go well together, and you figure that out, but maybe there's a couple other combinations that maybe they don't look like they go well together but they actually do. It's really how are we going to try these different things all relating back to our Agile values. That's the way that we're really going to get things done.

It goes back to just being able to communicate well and to inspect what we're doing and see, is it doing what we need it to be doing. Those needs are going to change too. It's gone from a very prescriptive type implementation to I think it's gotten a lot more pragmatic. Then there are of course people that are on all spectrums of that.

Carl Smith:    
Right. I'll say that, looking at your experience, SPC, CSP, CSM, you've done Lean, you have Six Sigma, Kanban. You are the perfect person, I would say, and I'm sure there must be other people out there who have similar experience, but I haven't met them, in figuring out what are these different tools, these different approaches, where we can keep the principles the same. I'm just curious. Have you done something? I know in your talk, Show Me the MVP!, you're going to talk about Lean UX and how that works in product development. Are the things when you look at your background that have helped you just not pick and choose but find some of the best from everything and put it together?

Natalie Warnert:    
Yeah. I've done a lot of different implementations with a lot of different teams, and one thing that I've really learned is the inspect and adapt. I have by no means been perfect with doing that. I look back a few years ago when I was first getting into some of the scrum stuff, and I was extremely prescriptive, and, ""No, you can't do that like this.""

On the other end of the spectrum, I tried a lot of things with Lean UX on a team that was not agile at that point, and we figured out what the middle ground was. Then I had people on the other side saying, ""Well, that's not Agile."" It went to the point where I was like, ""You know what? These things are actually working for us, and if you're going to tell me that I'm not agile because I have a few hand-offs in here, then maybe we're not agile, but we're something, and it's working.""

Carl Smith:    
You're effective.

Natalie Warnert:    
Yeah.

Carl Smith:    
Exactly.

Natalie Warnert:    
We're making it work for us, and we're working within the constraints that our organization has put out there. With Show Me the MVP!, I did a similar talk to this one in Ukraine last year at Lviv IT Arena. It was really interesting just talking about, because I think people have a really different idea about what an MVP actually is. The term has gotten so corrupted, and so the big thing that I try to put across in the Show Me the MVP! talk is an MVP needs to be a functionality to learn something. We're not talking about a minimum marketable product. Maybe we're not going to sell this, but maybe we are. What are we trying to learn?

Sometimes that's the absolute minimum functionality that we can put in to get some feedback. Sometimes it's a little more, because we need some more to learn. We need to maybe meet a certain set of table stakes in order to be able to learn something. A lot of the examples that I've used in training classes have just been extremely simplified ones with sending emails or checking out with a shopping cart. Those examples are good to get context and to be able to understand. However, you get the people in there that are saying, ""We could never market that. We couldn't market sending an email if you don't have a subject line in it.""

That's true. It goes to, all right, what do we mean MVP in this instance, and what are we actually trying to learn and validate so that we can do something. That's really what I talk about. I give a couple examples of some digital places that I've worked where we've implemented some, quote, ""MVPs."" Sometimes they're not the best solution. Sometimes they're super hacked together, but we just wanted to see if it would work, to see if it was worth investing in. By meeting these set of table stakes and adding this small piece onto it, what is that going to do? It's really all about learning.

I think going back where MVP comes from, the lean startup, it's all about, yeah, testing hypotheses. Regardless of what you're really defining ""MVP"" as, are you learning something from it? If so, then keep doing it and try to learn more. I don't really care if you put a ton of effort into it or not to make it marketable. It's just what are you trying to get out of it, because maybe it does need to be a little more marketable to get something out of it. I don't know. It depends on your situation, which goes back to what I was saying before. It's all contextual, and so you have to be able to be thoughtful enough to understand what context am I working in, and it's going to be different every time.

Carl Smith:    
I think the issues that a lot of people face when they're working in Agile for the first time or even as they get going is that design component; right?

Natalie Warnert:    
Mm-hmm (affirmative).

Carl Smith:    
You call it just in time design, and for me that feels right. I know that I've seen Agile for design. There are all these types of things. What do you find works best when you're trying to get to that MVP and the design component? What do you do to help with that or to give people a little bit of comfort, because I know designers, they wig out a little.

Natalie Warnert:    
Oh, most definitely. It's definitely difficult with designers to call things done, because ...

Natalie Warnert:    
As with developers; right? We can always make something better, and so it's hard to put that stamp on it and say it's done, so I try and change the language, and I say, ""Done for now,"" or I say, ""Just enough for now,"" those types of things. We can never go back and look at this again, but we need to get this to a point where we can stamp it and try it. Then you know what? We're going to learn and we're going to add to it. I think that designers are getting a lot better at working that way as are developers.

I think that on the development side, it needs to be, especially when you get past your, quote, ""MVP phase,"" it needs to be worked on a little bit, because all too often I see solutions going in that were hatched together for more of a let's learn, let's do MVP. Then they don't get built in more of a scalable way, and then we run into problems down the line. I think that needs to change a little bit.

Back to the design piece, there's another thing I've been working in that ... You mentioned my SPC. Scaled Agile talks about point-based design versus set-based design. Really, what that means is we want to instead of making a decision at a very early point in time on the way our design wants to go, especially with MVP type stuff, what we want to do is we want to preserve our options by keeping a set of designs, so a few different designs to try. As we get closer to our whatever it is, our release date or our test, think about the cone of uncertainty.

As we move along that and we get more information, then we can whittle down into more of a single design, but if we make that decision on the design right at the initial piece and say, ""Yep, this is what we're going to try. This is going to be our MVP,"" we're most likely going to find out that that's wrong, and we're going to have to do a bunch of adjustment at the end, versus if we look at it the other way and we come in with maybe five different designs, and then we learn something, and then we cut it down to three, and then we learn something, and cut it down to one, we've had to make adjustments, but those adjustments haven't been as drastic as they would have been had we said, ""Okay, we're going to start with this one,"" and then we end up at a completely different option. That's a really helpful tool. I talk about that in Show Me the MVP! as well.

Carl Smith:    
I think language matters so much. Communication is always the biggest struggle for any team, regardless of how you're trying to work. Just to be able to say, ""For now,"" I think adding those two words is brilliant, because it lets everybody relax.

Natalie Warnert:    
Yeah. One of the biggest fears is, I don't want this to go out before it's perfect. People don't want to put out sub-par work. That's in our nature for the most part. Yeah, by telling someone, ""Yeah, we're going to put this out,"" they're like, ""Oh, it's not done yet. It's not done yet."" You have to get over that hump and say, ""This is good enough for now, done for now, and we will definitely be able to go and revisit it,"" because of course we're going to want to make changes.

Carl Smith:    
Right. You recently got your master's of arts in organizational leadership, so congratulations.

Natalie Warnert:    
Thank you. Yes, I'm a little over a year.

Carl Smith:    
I don't know where you found the time.

Natalie Warnert:    
It was tough.

Carl Smith:    
There you go. I know that your thesis was on increasing women's involvement in the Agile and technology community, and you're working on Women in Agile, so talk about that. What have you found? What's going on? How can everybody help?

Natalie Warnert:    
Yeah. Great questions. Women in Agile, this is something that came up, at least came to my attention, probably four years ago at a conference. We realized, ""You know what? Where are all the women?"" I'm going to give credit to the entire Agile community here, because in the four years since that conversation I've seen a great improvement in the amount of women that are showing up at conferences and speaking.

We've definitely seen gains, but what I really wanted to understand was why? Why is it like this? Everyone knows that there are fewer women in technology. A lot of the studies go back to, ""Okay, well, why aren't we getting girls involved earlier? Why are they dropping out in college?"" My question was a little bit different. I said, ""All right. Those things are somewhat treating some of the symptoms, but we have all these efforts going to get girls more involved in STEM. However, if we do not have women in leadership positions to support those girls that are in STEM now that are going to grow up and hopefully continue in the field, but what's going to happen then? We're just perpetuating the issue.""

"Where are the women that are in IT? Yes, we know that proportionally there are fewer, but even looking at percentages and proportions at conferences, it's not equal, or it's not proportional to the amount. What are the reasons that the women that are already here, what are the reasons they're not being more involved? That was really what my thesis dug into. What are those reasons? Then on the other side of the question, okay, now that we know some of these reasons, what can we do to help combat those reasons and pull those women up to be more involved? That was what all that work was on.

I've done a few different events. I've written a number of articles in addition to my thesis and actually have a workshop coming up, actually this Sunday, right before Agile 2016. I know this podcast will be out later than that, but look for information from that, because we're hoping to do some videotaping and post some information from it. Really, we're looking to get both women and men together and say, ""Hey, we know this is a problem. We're not putting any blame on anybody, but how do we show the benefits of involvement, and how do we help make it easier to get involved?"" After all, we're going to benefit as an entire community when there's more people involved.

Carl Smith:    
It's so true. All the research shows that when you have more diverse teams, you've got better teams. It's all about diversity and inclusion, making sure that everybody gets a chance to not only be heard but to be accepted; right?

Natalie Warnert:    
Yes. That was a key piece that I was touching on with someone the other day is some people think diversity is just, ""All right. Our team looks different, but let's get them all to think this way, think the way that I want them to think."" That's not diversity; right?

Carl Smith:    
No.

Natalie Warnert:    
We're valuing the different opinions, and we want people to be heard and be accepted, and we want to come to some sort of a consensus but not a consensus that was coerced.

Carl Smith:    
Yeah, absolutely. Natalie, thank you so much for being here. Where can people find out more about the work that you've done on Women in Agile?

Natalie Warnert:    
Yeah. Great question. There's a website out there. It's WomenInAgile.com, and there's a lot of resources out there, as well as if you go to my personal website, just NatalieWarnert.com, there's a ton of other things that I've done, links to other podcasts and my thesis. All of those things are out there. Then the other thing is, anyone is welcome to use the hashtag, #WomenInAgile on Twitter, and so people post some great articles on there, and that's a great way for everyone to collaborate. One last thing. There is also a Linked In group that is completely open, and people post discussions on there too, so ...

Carl Smith:    
Great. I'll make sure and link all of that up in the show notes. Natalie, thank you so much for being with us today. I'm excited to see your talk, Show Me the MVP! at Digital PM Summit this October 12th through 15th in San Antonio. This is the fourth Digital PM Summit, which blows my mind.

Natalie Warnert:    
Yeah, that's awesome. I'm super excited to be there and to be able to talk.

Carl Smith:    
Thanks again. Everybody who's listening, thank you so much, and we'll talk to you next week.