 Hi everyone, my name is Victor Wu. I'm a product manager here at GitLab and today I wanted to share with you within GitLab plan. What is our goals and what is a strategy to attain those goals? especially as we enter into the second quarter of 2019 and these are really bold goals and these in the strategy is Gonna last several years. So this is gonna be quite interesting So I'm gonna close this window so we can see more on my screen and the agenda is pretty much on the left And I'll keep that open during the course of this video And so I wanted to start off with talking about what are our goals within GitLab planning again? GitLab plan is one of the stages in the GitLab DevOps lifecycle as we see it And so the overarching goal of plan is to have GitLab be the primary planning tool for successful medium and large Enterprises of the future And I'll get to what I mean by of the future in a second and that's that's very important in Very much informs our strategy But I wanted to mention how this aligns with the vision of GitLab as a whole which is to allow everyone to collaborate on all digital content And of course right now GitLab is very focused on software delivery focused on the DevOps industry as a whole and so In the realm of delivering software Planning collaboration and figuring out what to build getting feedback and incorporating that into your features And your software cycles is very important So that's why it applies to our Gillette plan applies to the Gillette vision very well Setting the stage is I wanted to step back and look at our industry and something that folks have been saying for a long time Is that software is eating the world and when Mark and Jason penned this it was all the way back in? 2011 and he was predicting something that has pretty much come true Very much and maybe even more so than he anticipated and pretty much in a nutshell what it is is that? Companies in particular medium to large enterprises are increasingly becoming software Enabled if not software driven in fact what what I argue and what you know It's not something I invented is what the industry is seeing is that in three to five and even ten years more and more businesses will become Software enabled in other words as a business your your key offering your key business will be powered by Software so you might not necessarily be in the software business per se or you might not be inventing You know technology, but you will be leveraging technology and in particular software so that you will be differentiate against your competitors and Because of the nature of software and the cost and the benefits there in the the competitors who do not embrace this digital transformation will just not survive and they just won't be around and so That's that relates to what I just said previously The the successful businesses of the future by necessity will undergo a digital transformation Those who do not undergo this transformation will inevitably fail And so that's why as as gilab ourselves We're focused on the customers of tomorrow because they'll be around and we'll be able to serve them and expand our business as a consequence and This particular goal is great because we're it's an expanding market in this in the nutshell Right because there's you know, there's X number of businesses today that need to ship software and in particular a lot of these You know Silicon Valley tech giants have taught us that In order to ship Software there's there's a certain number of practices you need to do you know folks I've called it agile devops in particular or at least the latest iteration of it and businesses small and medium to large businesses are You know following suit and taking the lessons learned there and incorporating These best practices from these tech giants into their business and enabling them to survive In the future as I mentioned earlier So that's why this particular goal makes sense for us as gilab Because the market for companies that need software transformation is only going to grow in the next few years so that's why we're focusing on the future because as These companies come online as these companies figure out that they need this transformation We want to be already there. We want to be already having the tools and capabilities and functionality So that when customers Realize this they can say oh gilab is the default choice We'll go with gilab and along the way We're gonna bring some of those customers along for the ride as we invent this future and but but that that leads into our strategy So I get into that in a second So how are we gonna focus on the future in this particular strategy? We're gonna do three things we're gonna make big bets in the future We're gonna mitigate risks by taking our existing customers on a journey And we're gonna leverage our single application strategy something that I think is very unique to gilab So one of the big bets on the future is something what I like to call the plan break plant and replant cycle essentially that's saying If you have plans you essentially need to constantly break them So if you look at a typical Gantt chart such as the one you see on the screen You might have a plan to say, you know, I'm gonna shift You know these set of features later on in the year I have all these initiatives going on but the moment you ship a feature the moment you you you wrap up initiative If you've designed your application, what if you've designed your business? Well, you should be able to get feedback from the customers right away Maybe even some you know indirect feedback from customers from the market as a whole and you want that feedback as quickly As you can to inform your planning right away. So for example, that might mean, you know Totally scrapping one of these initiatives. It could mean reordering something. It could mean deep prioritizing something It could mean reducing scope of one of these initiatives. Whatever it is We need a cycle of plan Breaking that plan once you get the feedback Replanning and then making that cycle over and over again So that's the name of the game in agile devops And in particular what you know the again as I said that the tech giants have already taught us and that we're applying These lessons learned to the small and medium Medium and large enterprises. I'm sorry And so with medium and large enterprises in particular what's interesting is that they just have a lot of scope to deliver Right and your typical product development, you know to pizza style team You can only ship so much in your you know, two-week sprint and so what we've been seeing from customers is that Typical enterprise will have multiple of these teams shipping software in parallel And these features and initiatives are coming together to serve a greater business strategy So for example if you're looking at this particular picture here at one company could you know One team could be shipping this line another team could be shipping this line But together they come together for some greater strategy So so we need the tools to manage all that right so traditionally you have your agile planning tools You have your scrum tools. You have your command style, you know boards and so on and so forth And that's all great and we have the inside gilab, but really looking forward We really need something beyond that and we're calling that agile portfolio management As as almost as a super set of project management so with agile portfolio management, it's really being able to to scope out that work at a portfolio level and not just at the individual team level and project level and then When you have it at the portfolio level that doesn't mean you have to slow down It doesn't mean that just because it's at a higher abstraction You have to go slower like as I just mentioned earlier the plan break plan replant cycle applies at all Abstraction levels it applies at the individual team level. So you're making decisions about what to ship in your team but you're also making that those decisions at the portfolio level and at the you know at the program level whatever you want to call it in your Particular business. So so that's why we we put the word agile in that sense and because that's that's what the industry is Having us use in that particular case So so one of those things is against this this gantt chart this roadmap view is something that is very helpful We already have in good lab what we're inventing in the future is being able to view That's that the breakdown structure that work breakdown structure easily within good lab So you can see this hierarchical Substructure that we've shipped, you know back in January just over a month ago And we're going to continue to iterate on that with some really awesome visualizations Bringing that roadmap view into the epic itself. So that that's part of our big bet about doing agile portfolio management having that work breakdown structure having that Portfolio visibility in order to ship amazing features In your medium to large enterprises in order to support this cycle of plan break plan and replan What's interesting is that this cycle only makes sense when you're going fast, right? If as I mentioned earlier This you still want this cycle at every abstraction level and you still want this cycle to be very fast at very at Every abstraction level and it's sort of even you know self-explanatory and obvious why this is the case Because if you're able to to ship business value to your customers at a high rate You're able to get that feedback faster and you're able to Get to that that optimum what the user actually wants So so maybe you made a mistake and you shipped a feature that the customer really didn't like But that's okay if you did it really quickly because you get that feedback right away And then you ship something else and it's it's better by 10% and the next time it's better by 15% Eventually you get an optimum versus in a traditional, you know, maybe even a waterfall style Framework you spend, you know a quarter three months Shipping a feature that you you know, maybe have done a lot of planning and user research in advance But it wasn't good enough and you realized at the end that you shipped the wrong thing and essentially Three months are down the drain with agile portfolio management with this cycle You need to go fast and you need to go a lot faster in three months You know, I use three months as a reference, but some industries maybe three months is actually a pretty fast But I'm guessing in most industries you really want to go faster than three three months for a typical sprint and a delivery Cycle and so how are we going to do that in Gillab? So what another big bet we're making is value stream management and you might have heard of this and it seems like you know Very buzzwordy and like what does it do? Is it just another process and to me? It's just a mean certain end It's just one amazing Framework I would say that helps you achieve that high velocity as I mentioned earlier And how it does that is that value stream management helps you as a process as a framework Quantify that cycle time and when I say cycle time, I mean the time it takes for you to ship software from when you decided to Do to ship a feature? How long did it take you to plan it to design it to to write the code to do QA to have your business folks review it To ship it out to customers. Maybe you had to do some beta testing along the way What is that end-to-end cycle time? How long did it take you and the reason why value stream management? puts a premium on Quantifying that number is because that's the best number to quantify. It's not to quantify You know, you know how much you know value you you accrue to your customer based on a particular industry standard Or based on some arbitrary, you know analysis that you did Those are great and it's something that we might focus on within Gillab in the future But right now we want to be laser focused on this time aspect Because what agile DevOps have told us is that if you can go fast Essentially, you'll be forgiven because the product development Cycle will tell you. Oh, you made a small mistake. You missed a mark from a product perspective from a features perspective It's okay because you went fast. You got that immediate feedback You can quickly change course or tweak and iterate to where you want to go So that's why we put a premium on this end-to-end cycle time And so that's exactly what we're designing into Gillab. You can see it from this particular view You can see from a value man value stream management Process or framework they often say that you need to to document these things or have these things So so how we've interpreted a Gillab at least right now of a design of value stream management is putting this cycle time front and center in many of our our UIs to help Decision-makers stakeholders people who can affect change in your process and key sponsors, you know Whether that's you know a business leader even their executive folks see how you're performing Because ultimately this number 15.4 days in this particular Example is a direct a reflection of business value as I said earlier It's as close as you can get right this number is super super close to how you can Reflect your business value that you're delivering to customers and in fact This number is is important because it's objective and you can actually improve it and within Gillab Our vision is we want to have you be able to call and quantify whether this number You know it has reduced by 5% and that's great You say over the course of a month and then furthermore what value stream management also, you know explains to us It tells us you must almost you you must also map the individual stages in your DevOps life cycle To to quantify how it's contributing to this 15 for point four days That's the mapping part of value stream mapping So in this particular case you might have a development stage in your life cycle You might have a code review stage. You might have a user acceptance acceptance stage and if your development Cycle is really high. You might want to know why that is the case If your review time is high or if your business Acceptance testing is high. You want to find out? What's the case? Why that's the case? So value stream mapping is a framework to help you identify which pieces of your DevOps life cycle is the worst offender say in Contributing to this end-to-end cycle time and it helps you say it helps you identify that and quickly pinpoint the problem and so you can address it whether that means you need to improve your process you need to Improve your culture and you need to hire more folks. You need to invest more in technology so on and so forth So we believe at Gillab That that's exactly what is going to improve your business by providing this end-to-end cycle time Identifying the waste as you can see here Identifying the waste and and allowing you to optimize for that so you can see in this particular case There's more stages and you can see how long you spent in that time And for example, the lead time can quantify, you know a waste time or you know How much time a particular initiative was stuck in a stage without active work? So that's one way to interpret lead time in this particular case essentially the inefficiency of A value of your value stream map Again, this is another view how you could see that to really zoom in to the number So so that that's our big bet on Let me shrink this again on a big bet Rounds out our big bet in our future focus strategy in secular plan really it's about agile portfolio management being able to to Have a framework to capture all the work that you need being able to quickly Re-plan work as you need it and being able to do that as quickly as possible Quantify what quick means and even improve that over time So that that's part of our future focus strategy another part is mitigating risk so Because we're so focused on the future We don't know if what we're inventing is the right thing We don't know if these are the right features that we're building and it's especially hard Along the way because we might not have a lot of customers for these future Looking futures as I mentioned earlier a lot of these Organizations that will need these features have not been invented yet or have not gone through this agile DevOps transformation yet So they might not be interested in using these features right now So there's a lot of risk there because we might be building something that people don't want in the future Or we might not have a lot of adoption right now as it were and so what can we do to mitigate that risk? and so What we've done is we've reached out to very strategic customers and you can see on our customers page on gilab About that gilab comm and you know, we have a lot of them who we've worked closely with and identified and said, you know You understand this DevOps future you understand How the future of software is going to drive your businesses whether you are a you know Our technology company or not and you for example, you can see some of the logos here They're not fundamentally technology companies, but they understand the future of DevOps So we're working closely with customers and if you're a customer watching this video We will feel free to reach out to myself Or anybody at gilab and let's have a chat and have you impact our features and that's exactly how we're mitigating the risk We're partnering with customers Working closely with them and asking them. Is this the right thing? Is this what you would use? You know, maybe a month from now two months from now. Is this what you need now? Do you really need this now or would you rather? You know us partner together and work on a feature that you will just get be ready to use three months down the road So we're being really strategic in working with the right customers to mitigate that risk of us building the wrong thing and having our customers shape our roadmap because Even though we're confident in this strategy and this vision we might not get all the details, right? And so we're mitigating that risk With with inviting customers to join us along the way and then finally and another strategy point is We are leveraging our single application strategy So I get lab or not we'll get get lab itself as a product is a single application For the entire DevOps life cycle and so we're doing everything from planning to monitoring So what that means is that some of our features or some of our areas will actually be a little bit more mature And so that's great And so in particular a lot of our customers are coming to us for source code management or coming for us for continuous integration and continuous delivery So we're able to leverage that we're able to bring in customers Who need get lab for source code management because it's it's it's you know best in class Has all the features and functionalities that people need right now. It's fully integrated With the rest of Gillab it has amazing design and it's just a great tool So we're able to to get those customers using Gillab right away And because Gillab is a single application the moment customers are using Gillab for source code management and CI They already have these planning features that I've been talking about in the interface itself It's not a separate plug-in. It's not a separate feature suite It's not something to to turn on in the settings Everything is already there in the user interface and you can use it right away And so that's something very powerful that even though we're focused on the future in particular for Gillab plan We can still leverage the fact that we're getting a lot of adoption of Gillab in this other These other areas of Gillab in particular source code management and CI and have them taste a Gillab plan at least the future version or the future features that we see that are important inside good lab plan So that really rounds out What I mean by the single application piece and you can see from this screen An example of a merge request and you can see some very awesome features there So that that wraps it up for the Gillab goal and strategy video here You can see the link in the YouTube description below to our direction page for the plan area And I encourage you to visit it to learn more about this And then there is indeed a write-up of pretty much everything that I've talked about here And so you can read that in more detail. Thank you for watching