How do you guys manage the challenge of multiple development streams going on at the same time? For example, the team is pushing out daily updates to PTU 1.3 (awesome job by the way) while i'm sure others are still heads down trying to get the "Baby PU" up and running soonâ"¢---We've been told that 1.3 is the merging of all the development streams into one. This makes me that 1.3 is actually kind of huge in the way of things running smoother. Could you spend a few minutes to describe the sort of impact "merging the streams" has on the development process, and how better (or worse) it makes your job?asked by Cavguy & Crazyprsn

I definitely want you to answer the question but there's a part in there I just wanted to chime in on. It's kind of huge in the way things run smoother? Absolutely having everything condensed into one place means globally as a company we're looking at the same information the same data and we're all working in the same place.We just merged the stream back that we working on the web side and it did make some people not that excited and it broke some things but it got us all looking at the same thing. So we got all those streams back a while ago that was definitely a step in the right direction so now we wait until the last minute right when we're about to release and we break that often we give that to you guys and then we merge all that back so just try and maintain one core sense of development so we can all work together and can all speak in the same languageDarian Vorlick: And we always try and keep the emphasis on stability and I don't know if you guys noticed but the stability of the systems have been much improved as of late since we've been doing. So as far as how we manage the challenge of multiple development streams at the same time well.. that's what we have the different teams for.We may have one person working on one stream another person is working on a much more public stream so and then some of those come under as QA. For example the QA team may report a bug in the 1.3 stream and we ask them to go back and test see if it's happening in our main development stream as well just to see it may be happening in the 1.3 stream it may not be happening in the main development stream. Because whatever's happening in the main development stream may have fixed it already.So it's kind of being cognitive about what the differences between streams are what's going on in each one. This is where being able to track product milestones and the fixed version in our test bed program Jira come in very useful so we do have a way of reporting in fact we have a daily dashboard that shows how many bugs we have open in this stream and this stream, are they blockers are they critical or are they trivial? We have daily conversation with the production staff globally about what bugs and what tasks need to be tackled before the day is overEKD: You mentioned how better or worse it makes your job it definitely makes it better and how we're maintaining it is even as people work in the 1.3 stream that you guys are seeing we're we have an automation process that we're immediately grabbing that date and trying to bring back into the mainstream at all times now before we didn't even have that operation running so that's been wonderful so that when we are going with 1.3 we're right back working together and we can lop off again for a new stream without going hold on we have to stop everything and merge it back now and becomes this big orchestrated process.We get those emails constantly "Hey we're blocked someone needs to help us get this done". But it's better to do it a little bit at a time it's like you're writing a book or painting a painting everyday you spend a little time on it because by the time you're done on it it looks prettier. And the other part of that question was how do you manage multiple streams at a time and I think you just answered that.