 We've talked about agile planning and the collaboration that it both enables and requires. Now let's drill down into exactly what that means for you, our GitLab users. In our next talk, two of GitLab's product managers, Kristin Debenko and Gabe Weaver, will talk about changes they've seen in the agile planning space, some of the unique approaches that GitLab has taken to build planning into our DevOps platform, how we're using GitLab internally, and then my favorite part are vision and roadmap. Today, they will share some really exciting changes on the roadmap that will make GitLab even more powerful and more flexible and better able to deliver the very best planning experience in the industry bar none. So let's listen. Welcome to agile management with GitLab, present and future. I'm Kristin Debenko, Senior PM in plan. I focus on portfolio planning features. And I'm Gabe Weaver, Senior PM in plan, and I focus on our team level planning and collaboration features. Before we start, a note about forward-looking statements. Anything we say in the presentation could change as our roadmaps are ambitious and we embrace change without notice. Information presented in this session should not be used for the purpose of any material purchase decisions nor is it a promise of any sort. Okay, with that out of the way, our talk today will include the following. Gabe will walk us through some common challenges with agile. I will talk about how we eliminate communication silos in GitLab with features that support collaboration and we'll wrap by sharing our exciting roadmap and vision for the future. Over to you, Gabe. Thanks, Kristin. Let's talk about some common challenges that organizations are facing today. The pandemic happened. While some forward-thinking companies were already far along and their transformation journeys, most were nowhere near ready to transition to a fully distributed work environment. Few were equipped with the right tools and technology to enable efficient and effective remote-only collaboration. Building and maintaining software at scale requires a lot of roles and cross-functional collaboration. Most organizations use point solutions integrated into a complex do-it-yourself tool chain. As organizations have progressed in their transformation journeys, this approach has resulted in a lot of challenges. Tools get out of sync, lack of visibility for various roles at different levels, inefficient and difficult collaboration. One customer recently told me they had unintentionally reverted back to using PowerPoints and email to communicate software requirements because they were using three different tools for planning and tracking work. DIY tool chains make maintaining alignment exceedingly difficult, which more often than not results in the needs of customers not being appropriately met. The classic tree-swing problem is a great analogy here. To fix this, some smart people designed super complex scaled agile frameworks in the hopes of getting everyone moving in the same direction. While promising on the surface, these frameworks and large-scale agile transformations as a whole cost a lot of time and money to implement. They also quickly surface the fact that organizational change is really hard. According to the most recent state of the agile report, 43% of respondents say the most significant barrier to adopting agile practices is the organizational culture being at odds with agile values. When organizations try to adopt agile practices without realizing that they must also fundamentally change their organizational culture, they generally end up using a scaled agile framework to facilitate a waterfall process. It's all too easy to unintentionally prioritize process over collaboration and fall back to encouraging large upfront requirements over iteration and learning. As a practical example, two thirds of organizations are still using spreadsheets to track work and many spend two full days at the beginning of every quarter, making hard commitments on the details of everything they must deliver over the next 90 days. Most customers that I've worked with who are leveraging a scaled agile framework say they are still adopting it years after initially making the decision. Very few say that it is enabling them to deliver customer value as efficiently as they had hoped. Another common challenge I hear from our customers is how to measure success and define value. When I ask customers how they define value, most talk about the progress they are making on delivering their quarterly commitments. In fact, 45% of organizations measure the success of their agile delivery by their team's velocity or put another way, the number of tickets they close. Unfortunately, closing tickets does not mean delivering customer and business results. Mapping the output of teams to business and customer outcomes is by far the biggest and most complex challenge organizations are struggling with. These challenges are a major catalyst behind how the DevOps landscape is evolving. We're seeing a huge shift in how organizations are defining success with the transition from projects to products and focusing on customers first. We're also seeing a dramatic increase in companies that are migrating from DIY tool chains to single platform solutions in order to reduce silos, improve collaboration, and create better alignment at scale. We want to eliminate silos at GitLab. This means we must consider the modern product team. We want to be more than planning for engineers alone. For us, collaboration between engineers, design, and product are essential to a great outcome. In this next section, I will take you through an overview of the specific features we've recently shipped for collaboration between all personas that use GitLab plan. There will be a specific focus on the designer persona and then we'll move more broadly to the whole team. For designers, one of the most important shifts we've seen in the research is the continual evolution of the composition of product teams. You can see in this snapshot from 2017, many of these companies listed have dramatically shifted their ratio in favor of more designers to engineers. This informs us that designers are important GitLab users and design collaboration is essential to planning features. You can also see how we've shifted our own hiring ratio at GitLab. Over time, we realized how important this ratio is but specifically between front-end engineers and designers. So we're focused on building a one-to-three ratio on our teams at GitLab so we can more easily prioritize on usability and feature improvements. So looking at a designer's typical workflow with DevOps, we asked ourselves, how can we make this better? Shown is a standard do-it-yourself tool chain from a designer's workflow perspective. You can see that the authoring happens in the design tool like Sketch or Figma or Photoshop. A prototype is posted to an app like InVision and then it is posted into an issue tracker where the product team often gets involved including engineers. Engineers further takeover in the repository and the code base and stage code is created but the communication happens via Slack or email to loop the designer back in. It's not efficient and it's not optimal. We see a different way in GitLab plan which is more streamlined and collaborative for designers than the whole team. We've built plugins for both Sketch and Figma that allow designers to upload right into GitLab issues. GitLab then becomes the single source of truth for design conversations. You can also easily link to any Figma file as well. This process goes even further than GitLab issues. The designer can participate in the merge request which brings the code into alignment with the design vision. Threaded comments and posted screenshots can help facilitate this. Using the review app feature creates an awesome staged environment for everyone to view the code. Here you can use our visual review feature to give point and click feedback on the implementation and loop in non-technical stakeholders. QA and the whole team collaboration becomes easier when the reference to the original design and the designer are participating. Here's a demo of our Figma plugin in action. With a few clicks, the Figma frame can post as a design into a GitLab issue. There it can be versioned and discussed in the comments. Next, we get into another important collaboration feature that brings in the rest of the product team. Threaded discussions and GitLab issues allow async communication on the most important topics. Any member of the team can start threads and encourage dialogue with GitLab flavored markdown. You can also link to other GitLab objects such as MRs and designs, and you can add mention your teammates to loop them in. Another collaboration view we have are our issue boards. While this fully supports teams using Agile and Kanban, we've made it even better this year for EMS, PMs or directors who want to see progress on specific epics or features. You can see that by turning on the group by epic selector, it adds a swim lane for each epic, which gives a precise high level view into how features are progressing in this workflow. Not only that, we just released epic boards in 14.0. This enables workflow status across epics. For example, I'm tracking the progress of these epics using scope labels on the board. This is another awesome view for tracking portfolio level initiatives or features. Two more collaboration objects we have are iterations and milestones, which both track against a timeframe. Once issues are assigned to either of these, directors and other high level team members can get a view into burn downs and the progress of the team. This enables you to sequence work across planning periods, to measure progress, track scope creep, and use metrics like velocity to collaborate on trade-off decisions with stakeholders. The final collaboration view today is roadmaps. Similar to epic boards, this gives a portfolio level view into progress and timing of epics. Even if you don't use a framework like SAFE, you can still use epics to communicate progress of your features and capabilities. Our roadmap view is great for the whole team, but executives and other high level personas will find this useful for ensuring alignment of initiatives across the company. Now let's talk about where we're headed. As a teaser, it's not achieving feature parity with our competitors. We believe there's a better way. We have an exciting new shared plan initiative. We're merging issues, epics and requirements into what we are internally calling a work item. This is one of the most exciting things I've ever worked on because of the amazing things we'll be able to do with it. For the next six months, Gabe and I have joined our two product groups, product planning and project management, to focus primarily on this merged architecture for work items. You might ask why? Up to this point, we built planning capabilities around distinct objects with different behaviors on each. As we've learned from working closely with our customers, this has resulted in some real usability challenges. Epics are only in groups, issues are only in projects, we have assignees on issues, some customers need assignees on epics. These are just a few of the many examples. In most cases, we've ended up duplicating the effort to achieve parity for the shared capabilities across the core objects used for planning. So we took a step back and realized that we could better solve our customers' needs by simplifying the planning system within GitLab. Instead of maintaining distinct objects with special properties, we're working towards consolidating the objects into a single core work item. Work items will have a type and support parenting like our current epics. They'll be available for both group and project, and they'll be compatible with all the great functionality we've invested in like design management, iterations and parent-child relationships. We'll also be making status of first-class experience to better support progress reporting and automation and enhancements we'd like to tackle in the future. We'll launch with some default types like requirement, issue, feature, enhancement, test case and bug, but they will all be powered by the same underlying model. We're also revamping the detail view to improve usability and enable real-time updates with the exception of collaborative markdown editing which we'll tackle later. Eventually, customers will be able to create their own types so they can map a work item hierarchy in GitLab to their agile framework or business domain. Simplifying the planning system this way also enables us to more easily address another core problem. Teams regularly work across many groups and projects, but there's no way to visualize that in any single place. We're going to focus on providing greater flexibility in how work items roll up across groups and projects. This will enable more efficient collaboration, better reporting and less time spent with context switching within GitLab. Ultimately, these core changes will lead to increased visibility, traceability and collaboration across your entire software development lifecycle. And it will make it easier for GitLab stages to integrate into plan in a kiss instant way and vice versa. There is so much we can do with work items looking into the future. This next section is a sneak peek of how this data and new architecture can come together practically in our roadmaps. At GitLab, we dog food our issue tracker and have implemented a considerable amount of automation outside of the core product. We will work towards making automation a first class experience and reducing the manual setup required to enable it. This will allow teams to shift the time consuming tedious effort of issue maintenance to GitLab so they can focus on higher value activities. It will also power more efficient collaboration across different functional roles. For example, approval on an MR could trigger an update to an issue status which could trigger a pipeline to kick off. If the pipeline fails, we could assign the issue to someone. Another exciting feature that work items will have are custom fields and calculated fields. You'll be able to add these like columns to your work item. For example, you could add a custom field for the work item, which tracks a customer name that you enter from your CRM. You could also add calculation fields where you could imagine rolling up things like CAPEX calculations for cost, summing of weights or story points at an epic level, prioritization models such as rice, or you could aggregate key result data from within GitLab itself. We want to enable customers to track actual outcomes as time series data within GitLab. This will enable work items to be mapped to the outcomes they are focused on achieving. We can start to record and track real measurements in GitLab through the manual recording of inputs into a custom field, ingesting from a third party app via the API, such as your CRM, or using collectors and product analytics. For example, track user events and link them to the work items to track the outcomes. This will also complement and tie into our value stream analytics and help correlate improving your DevOps adoption with business metrics. Objectives and key results will also follow tracking outcome metrics. For example, if tracking monthly active users, you might want to set a KR to increase it by 25% in a given period. You could imagine using the date selector to choose the time span of the KR and to track it to an actual data point within GitLab. Then connect that KR to the objective and the work items that will actually move the needle once they ship. This could give even more insight into key results such as growth by understanding which code level changes made the most impact to the numbers. Another exciting thing we have planned for work items are saved queries and views. We think these are key to flexibility and easy navigation through the plan stage. It will create a robust framework where anyone can create the views that match their business value and save and share them. I'm going to give you a very rough wireframe with four views that shows how this might work. Please note that all of this could change as UX has not given it love. This is a safe query I've called plan team current milestone. It is scoped to the milestone 13.8 and the name has been saved. I've modified the view to be a list view with group by health status turned on. I can now share this view with my colleagues as it is saved. I can also change to other views using the view picker in the top right. Right now I'd like to see it as a board. Now I see the same issues and they are organized bug workflow labels so I can see my team's progress. I'm still on the same original saved query. Next I'll switch to view it as a burn down chart. Now I can see how we are tracking to the given end date and if any scope creep is creeping in. One more switch to grid edit view for the same query. Now this is a forward looking view but we envision an easy way to sort, edit and enter issues just like within a spreadsheet. As a PM I could switch to this view to quickly modify titles, weights and status and I could also drag and drop the sort order to refine my priorities. One other note, you may be thinking how do I see the detail view of these work items in GitLab currently you would have to navigate to the individual URLs of each issue and you would lose context. We plan to have a modal or a docked sidebar or both that lets you view detail without losing context. The design of this is still to be determined but we want to ensure that there's an easy way to stay in place for example on your spreadsheet and not have to always navigate away to the unique URL. So that is the final view we have as a teaser for saved queries. Of course we could add more, we could switch to road maps, gants or any views that our customers need. We think this will be a game changer for ease of use and maximizing your data within GitLab. One of our core product principles is that GitLab should work by default and that's our long-term goal within plan. When we combine everything we've talked about thus far we have the core building blocks that will enable robust support for most of the popular agile frameworks out there today. We want to create ready to use templates so teams can effortlessly onboard into GitLab and leverage the framework of their choice. The building blocks we were working on and plan also leads back to the way we think about the future of planning within GitLab. It takes a lot of practice to learn how to build with true agility. We want to provide the wider community with the right set of tools in each step in their journey and help them continuously improve and evolve their processes. At the same time, while frameworks and processes can be helpful in certain situations, we believe they should always be secondary to results. That's why we're focused on connecting output to outcomes and enabling more efficient collaboration across all of the different roles that play a critical part in the product development lifecycle. While we realize that some may need complex enforced workflows, it's our goal to create a platform that empowers organizations to sustainably deliver customer value and business outcomes with the shortest possible cycle times. Thank you for all your time today. If you want to learn more about our vision, check out our direction page. Also, a special thanks to the whole plan stage who make all of this possible. We love our team.