 Hi, my name is Ty Davis and I'm a technical marketing engineer at GitLab. Today I'm going to be talking to you about Agile portfolio management using GitLab and how your organization can build out structure using the GitLab tool to apply enterprise Agile to your company. When we take a look here at healthcare provider incorporated this is a mock organization that I've set up for this demo what they've done is they've gone in at the parent level they've applied the healthcare provider incorporated so they have their organization at that very highest parent level or maybe it's an application they have at that parent level and then they have subgroups underneath that which you can see here is broken down into six different subgroups or six different value streams or specialty areas that they are going to break down their Agile teams as a part of. There is one spot done this parent group that is a project and that's labeled PMO management this is where they're going to have board views and be able to do non-functional portfolio issues that come up for that parent group level. The way GitLab is broken down is you have groups and you can have subgroups underneath that and then you can have broad projects residing on any of those groups or subgroup levels. When we take a look here at the drop-down menu for a hospital subgroup you can see that it's broken down into several different other subgroups that are going to be making up the Agile teams that all will funnel up to making that hospital specialty move along with whatever functionality whatever features whatever building that that is specific to a hospital value stream as part of healthcare provider incorporated. At every group level or subgroup level you have the ability to add in epics and we could see here that I could filter via a label in this particular case we have some some strategic themes that the company is looking at patient satisfaction being one of those and I could see that I have a couple specific strategic themes that as a company we're going to have better pharmacy turnaround time maybe we're looking to integrate the tool surter over another tool that we have internally there's some ACA compliance that we're looking to align ourselves more with and so we have the ability to create these epics at different levels in this particular case the parent group level where we created it. Something else that has a great part of gatelab is that you have a roadmap view those epics will be applied to this roadmap view and you have the choice of giving it a start and end fixed date if you'd like or you could see here on one of these this epic here that it has a start and finish date that's probably being applied via the timeframe giving in a milestone and we'll go into milestones a little bit later and what a milestone is and just a quick what a milestone is is it's just a time increment we can give it a start and a finish date we can apply or create like sprints spread one two three four five that is a milestone in this particular case that's what this is doing for this epic. Going back to the parent group level we're going to dive into one of the subgroups hospital and then we're working on billing here the billing team is really trying to build out this feature that's part of the hospital and patient billing is one of the projects and one of the smaller scrum or con bond teams that are doing that we have four teams here are four different areas of billing that are that are being worked on patient billing is where we're going to take a look at and see what this team is doing over here we can go look at the issue list it gives us a a running list of issues once it kicks on over to that area there we go and we can see that we have a running list of issues that have been created this is interchangeable with what some know as user stories the way we do it in GitLab is we have issues that's how we and we classify things that are being worked on maybe an enhancement a feature request or sorry not a feature request but an enhancement request a fix all done here in the issues you can also filter through these with the different filter capabilities where we're going to go over spend our time is on the board view and inside the board view I can set up several different board views what we're doing is first we're going to do our our sprint planning so I have a backlog full of issues and I'm going to start applying taking off my product backlog and putting those issues on specific sprints so we can see here that we've already done some technical technical risk assessment and that is how we've ranked on some of our stories you can see here that we've given weight to a few of them probably a couple other ones that we needed to determine the weight and give that to those issues but what we could do start taking these off our backlog we can assign them to a sprint we're going to assign these to this specific sprint something to note is that you can drag and drop and rank these on the the open lane here which we are classifying as our product backlog so we can know you know what is priority when doing our sprint planning and take from the top of that list now that I've I've done my sprint planning it's time that our team gets working on what's been applied to Sprint 1 and so I can see here I've gone over the dev board I still have a running backlog of our whole product backlog so what I'm going to go ahead and do is specify that I just want to see the issues that a part of Sprint 1 and it populates that for me it shows the four issues that I applied to my Sprint 1 as part of that Sprint planning and now the team can either for a self-organizing team or for having product owners or product or scrum masters helping us in assigning which issue we're going to work on we could have that done here because we are self-organizing team I'm going to go ahead and click on an issue and me myself I'm going to assign that to myself so now I've assigned it to myself I want to start working on that I'm a movement in progress let's say a couple other people on the team have done that as well you know Dan did it he moves over to progress we could see that DT has ability as well to move that over and start working on progress so right now both Dan and I have started working on our issues if I were to click on mine again you could so there's no no weight on it originally I'll say hey this is a weight of let's give it 15 this is a pretty pretty heavy changes or additions that need to be made you do have the ability to add different lanes based on how your organization moves issues or user stories through the process this is very simple in progress and review and then there is a closed over here and so once we're going if I just move over a view it's going to automatically update that tag from in progress to review maybe have it in testing or different different lanes that are different naming conventions that we want to be a part of the lanes that the process the workflow that that issue goes through you can do so now if you want to go take a look at the team board and see who's working on what we can do so over the team board view and we could see that the issues that I assigned to myself and Dan was assigned as well are showing here so if I'm a scroll master and I'm you know taking a look at the team see what they're working out wanting to check on their progress I can see what issues they're they're working on in this board and you've already seen a couple of these issues have technical risk around them that's because we built a technical risk board with some labels of high medium and low and you can move those over left to right give them a technical risk if that's what your organization is doing and it applies it to that issue I'm going to go back to the dev board we're going to come back here in a second one thing I do want to know is I want to show you milestones and this is how get lab defines its start and and for specific time increments what we've done we've built out you know six different sprints here so that we can give it a two week sprint time and then we can as you just saw assign those issues to specific sprints so we can monitor that and then you have the ability to go inside that sprint and have visibility into a a burn down chart that's going to be based on issue or issue weight not a lot it's been done yet inside the sprint so it's not going to be a trending trending down quite yet you do have labels where you can create these labels here you've seen that's how we've been doing our organization so you could create those labels here and that's how we built out our board views if I now I had talked about I assigned this issue to myself and I need to start working on it I'm going to go into the issue and this is where I'll have information more specific to the issue where they could be collaboration done we can have comments from different people saying hey this is needed this is needed some banter back and forth to get to the finished product that we want but this is now where I'm tying that SCM and that CICD to that project management piece so I'm going to go in and I'm going to create a merge request and what this is going to do is it's going to check out a branch off of our master branch and then I the developer can begin working and making changes to that code that needs to be changed or fixed or additional code added and I can do that on this checked out branch I can either just copy and paste this our get commands here and go inside my terminal or IDE I could do it there or inside of GitLab we have a web IDE that you can use from here and what this is going to do it's going to pull other source code files and then you'll be able to go into that specific code that you want to change and do that let's say I was coming in here and just this is very very simple demo so I'm just changing making a change to my code I'm going to go ahead and commit that stage that give it a commit message and then I'm going to commit to that that branch that I just checked out and once I do that what it's going to do is it's going to kick off a pipeline we'll see it's pending right here so you have a couple of pipelines already running if I were to go into that pipeline let's give it a second here you can see that the pipelines kicking off the build we have several different stages and jobs that are being are they're going to run through that we've set up we've done this using a YAML file that we've set up our our build test review dynamic security performance stages in and I added some jobs to those like code quality container scanning dependency scanning static analysis some unit testing it's going to kick off a review app here once we are once it runs through these tests and then we could take a look at those changes that have been made to that code and we can you know make sure that's really what we want it I'm going here and let's take a look at take a look at a pipeline that has run already this one is is ran through all its different jobs it's done the review the review app and so if we if we go to that just go to my merge request we can see that it's done a couple things for us it's gone through it's done a cold code quality chain excuse me a code quality check it's done some security scanning if I wanted to see if there's vulnerabilities and there were it give me a running list I could do a full view of full report it give me some patches to apply if it found that there was a fix for some of those vulnerabilities it's done license management detection down here I can see that there's been several changes that have been made it's going to do the diffs on that and show that to me commits how many commits there's only been one it's going to show the pipelines that have read if they pass if they failed and then as I talked about it's going to give me that that review app which we'll to check the changes on that and make sure it's good to go and once I believe it's good to go all the ability to delete that source branch and then go ahead and merge that and once I click merge to master or click merge and it's going to merge it to master it's going to also kick off another pipeline that's going to do some checks as well before it merges that into master once this is merged into master it will close the issue that's associated with it so you don't have to worry about going back and closing that issue so this has been just a very high level or very medium to high level quick how to do agile project management you're doing your issue planning you're you're creating your epics and you're setting up the structure of your subgroups or sorry your groups and your your agile groups that are following underneath your different value streams or specialties we're going in we're building out our product backlog with issues we're doing our sprint planning assigning issues to sprints and then your team is coming in and they are picking those issues that they're working on them and they're creating merge or pull request from that branch that they're checking out for a master and then they're going in and making the changes that are necessary they are using the SEM built in the GitLab to to get their code from the repository make the changes once they commit push those changes then it's going to kick off that auto DevOps pipeline using that CI CD piece part of GitLab and then they're able to see if it's pass or fail based on the these stages and jobs that they built inside that YAML file that helps kick off that CI CD process or that auto DevOps process and then get those results almost almost immediately but very quickly and being able to if it's a failure going back and making changes that need to be made if it's passed just merging that in the master appreciate your time if you have any questions please feel free to reach out thanks