I'm here with Bill Wake, a 15 year plus veteran of Agile, and major contributor and thought leader in the space. Thanks for joining us Bill. >> Hi, thanks Alex. >> Let's talk about support escalations. The team is trying to do Agile, and part of the premise is hey, we're going to get good flow time here. And you're going to have two weeks where you know what you're working on, you know what success is, and then boom, all of a sudden all these unexpected, two or three escalation, escalation development come into play, how do you manage that? >> Well, I think it's just if you're a team like a Dev Ops type team, you're doing development in operations, you're going to have those >> Those things happen, so in some sense, you're trying to be prepared for those as they come and just deal with them. The fact is if we're spending half our time on support this sprint, we're probably not going to be spending 100% of the time on developing new features that we had hoped for. >> You know over time you can kind of figure out the level at which things tend to run and different teams handle this different ways. I've seen a team that they sort of designate one person per sprint to say you're the first line for the team and if something comes in you deal with it if you need more help we'll give it to you but our team's assumption is you're pretty much going to cover it for this time and sort of setting a one team member expectation and adjusting the planning otherwise. As the teams get more In the continuous deployment, it becomes less of an issue that they're just taking whatever it comes next anyway. They weren't going to be spending two weeks, they were going to be spending a couple of hours or half a day or something and if it turned out the next thing is a support thing Then, let's do that. Or if we have to drop what we're doing then we'll do that and get it moving through. >> Let's talk about the relationship between those two things content wise. Is it hard for teams to look at support issues and get into the habit of saying, alright,well is there something we can do differently about the way that we're building the product or deploying it to users? That can reduce our support escalations versus okay, well, we thought we wanted to develop this new stuff. Is that a hard balance to strike? There's this idea of new development, and Is different than sustaining engineering. How do you find teams, strike the right balance so that they reduce the amount of support escalations they get? >> Well one thing is over time, we're trying to build a better level of quality into things, because we recognize that if we say something's done, but it really isn't because we have this kind of quality gap. And at some point we have to pay that back. And we can either make it better now and leave out the gap. Or we can leave the gap and then we have to >> To go support it later and, you know, it's interrupting it's a pain it's all that. Then, you know, we can see justification for doing things now to find out that. And, you know, the teams I know that do well on things, they have retrospectives or more ongoing continuous kind of things. And they try and explore. We have in the lead startup there's this notion of like a five wise analysis to say what caused this problem, or how did this occur? And really dig in to say let's find something now, we'll fix the immediate thing. We'll invest in up the chain of the wise and fill in to say, make this one a little better, a little better, a little better and then the things that go wrong all the time tend to be less frequent. Another one, the XP people that's been around a good long while as he calls it the street light theory and says if you have a town and there's, it's all dark and you're going to put in street lights. Usually the two places are you'll put street lights on busy streets because you get a lot of benefit from it for the people who are there all the time. And you put them in the streets that are maybe a little crime ridden. And. >> [LAUGH] >> They need a little more safety there and. And that of corresponds to what we're doing here as the team goes through you know the primary correspond to the defects, and as we hit and support fixing those defects we add the extra supportive tests and looking at our process and so on and you know kind of get the street lights there to make the flow go a little better overall. That's some great advice on managing the practical realities of what happens in development cycle versus what we plan. Thanks, Bill.
