Lisa Cockrell & Jordan Upperman – Gitting Lean: GitLab And Our Transition To Agile Keynote

I'm really happy to introduce our next two speakers, Lisa Cockrell and Jordan Uppermann, Lisa is the director of application development at IssueTrak and Jordan is a lead full stack developer on their product. Hi, I'm Lisa Cockrell, and I've been with Issuetrak since 2004, in those 16 years, I've been a software tester, a new feature developer. I've managed the QA team and I've managed the dev team.

Today, I'm the director of development for Issuetrak and I'm also the acting Scrum master for our product team. My name's Jordan. I started at Issuetrak as an automated test engineer back in 2017 a little over a year ago, in early 2019, I was given the chance to work on the product development team as a full stack developer.

It was around this time the Issuetrak was really leaning into our adoption of Scrum and I received my Scrum master certification followed by my Scrum developer certification. Since then, I've been trying to find innovative ways for my team to evolve and further automate or streamline our processes. To give you some background on Issuetrak, we're a Web based ticketing solution that allows companies to track issues so that nothing falls through the cracks.

We are a privately owned company with over two thousand customers across nearly 40 countries. We provide cloud and premise deployment options to suit our customers unique needs. And our headquarters is located in southeastern Virginia.

We were founded in 1992 as a custom development company. In our first iteration of this product was provided in the year 2000. As you can imagine, a 20 year old product has a lot of legacy code.

So we're going to be sharing the story of our transition to agile practices in the context of our adoption of GitLab. There are a number of reasons we took interest in GitLab, but the primary reason was a feeling of tool. We were using several tools at the time and this presented innumerable challenges, one of which was the cost of having multiple different tools and maintaining user subscriptions for each member of the team resulted in costs that were becoming colossal.

There's also the complexity of coordination. Coordinating a multiple multitude of tools. Working together creates a lot of variables and thus more room for things to go wrong.

But even when things go right, there's a productivity cost with context switching between tools that should just be avoided whenever possible. We had some trepidation when it came to switching as migrations of the scale are rarely simple. A lot of planning and consideration goes into adopting a new tool such as GitLab considerations can vary from training the team on the new processes.

Potential downtime during the migration process and the possibility of data loss. Data loss could result from the actual migration process itself, or just an inability to adequately represent data from an old tool in the context of the new tool. Another major factor is any possibility of complexity or of the migration process itself.

For example, if we had to manually copy every item from one tool to the other, that would have just been a nonstarter. Thankfully, these were largely nonissues when it came to get GitLab. GitLab provided a simple, easy to use method within their user interface for migrating our repositories and tickets from GitHub or a similar option did not exist at the time, for JIRA.

We were able to use the GitLab API to programmatically import our ticket information from that platform. The GitLab API documentation by this task much more straightforward than we had initially anticipated. The ease of use did not end with GitLab's documentation.

T. departments. The impact of Issuetrak's adoption of GitLab as a one stop tool, as well as our embracing of the agile software development methodology, was huge.

Nearly all of our daily workflow tasks have benefited. We'd like to tell you about a few of the more impressive changes. While our main objective in adopting GitLab was to make our processes more lean, an added benefit was the ability to make our monthly cost lean as well.

Prior to our transition, we were using five separate tools for our daily workflow processes AppVeyor and CircleCi for our CI/CD pipelines. io for a Kanban tool we had recently on-boarded JIRA for a separate ticketing in solution as well. The subscription cost per month for all the licenses that we needed was substantial.

But once we moved to GitLab, we were able to bring that cost down significantly, a savings of about 80 percent per month. Another important way that GitLab assisted us in our transition to Agile was by allowing us to better manage our product backlog. Prior to GitLab our backlog resembled the black hole, things would go in only to never be seen again.

There was very little conformity in our tickets which made it challenging to group or categorize them at scale. It was difficult to prioritize tickets and as a result, tickets were worth at developer's discretion, which in turn made our output as a department unfocused, resulting in major time gaps between releases. At times, work would begin only for the developer to realize that the amount of information on the ticket was insufficient.

This stemmed from a lack of a definition of ready. The ticket template featuring GitLab proved to be extremely useful for our backlog management. We now leverage templates to communicate what information is needed when the ticket is submitted.

We have a dedicated template for every source of tickets. The product owner team uses the user story template. QA uses the QA bug report template.

Customer complaints from our TSA are added using the support bug report template. And on and on. We use the quick action feature of GitLab within our templates to ensure uniformity of labels in our tickets.

This prevents us from having to train everyone on which labels are appropriate for which kind of ticket. Instead, the appropriate template is chosen and all the relevant labels are automatically applied. Our utilization of these features has finally given us the ticket conformity that we sorely lacked another GitLab feature that we leverage heavily is the ability to customize our Kanbans.

Our team had some experience with Kanban boards prior to our transition to GitLab, but we were limited to a single board with static columns. We didn't realize what we were missing. a.

the black hole. This made it difficult to refine and groom our backlog, so much so that we were copying and pasting ticket titles into a Google sheet in an attempt to give it structure. When we migrated to GitLab our ability to leverage the Kanban boards was a game changer.

We now have multiple boards of both the group and the project levels, and the ability to select custom columns allows us to tailor these boards to our needs. O board and the Sprint board. Because of GitLab's customizable Kanban board feature, we created a new board specifically for our product owner.

this board tracks our backlog refinement process and ensures that all of our tickets meet our definition of ready. O team now has the ability to focus solely on prioritizing the work that is coming down the pipe. We created this board with three columns unrefined, groomed and ready for Sprint.

O. and placed into the unrefined column. O several times a week to discuss and design the new features, eventually creating and weighing discrete task tickets associated with those user stories.

At this point, the developers move the user story ticket into the groom's column. The groom column is not prioritized. O team to select work for the final column of this board, the Ready for Sprint column.

By the time a ticket reaches this column, each user story has a story point estimate. O team the ability to prioritize our work and estimate released schedules with more data than they had when the user story was initially submitted. Our second customized Kanban board is our Sprint board, this board starts with the Ready for Sprint column and contains a column for the rest of the development process because our two boards share the Ready for Sprint column.

We can rest assured that every ticket that appears on this board meets our definition of ready. The duration of our sprint planning meetings has been greatly reduced. Now we can simply pull tickets from the Ready for Sprint column until we've reached a weight that is equivalent to our average velocity, all without having to examine the tickets themselves.

And the ticket counts and weights are automatically calculated and listed at the top of each column. Our use of these two Kanban boards allows us to pivot with ease when necessary as bugs are found during testing. It's easy for us to quickly weigh the new ticket, remove an item with equal weight and send it back to the top of the Ready for Sprint column.

This practice prevents scope creep in our sprints, and reminds Stakeholders' that when work is added to an already committed sprint, something must come out. Our general ticket workflow has been transformed as a result of our transition to GitLab and to Scrum, as mentioned before, prior to our transition, ticket's priorities were unclear and we worked at the discretion of the developer more often than not. When the developer began on the ticket, there was minimal information, and this resulted in some features being developed without the intended context of the initial request and subsequently a loss in value for the customer.

Without a refinement in grooming efforts. It was difficult to predict the level of effort of each request, and therefore planning and scheduling were cumbersome processes. This caused deadlines to be missed and unhappy stakeholders as well as customers.

Now, with our system of grooming tickets in place, it's much easier to select a new ticket as they all meet the definition of ready, which includes estimates regarding the level of effort for each ticket. Having our backlog in a consistently prioritize fashion allows the team to select work quickly and without contemplation, further reducing the effort needed to produce deliverables. We've also implemented several systems to shorten our feedback cycles, one of which being improvements to our CI/CD process.

Before we GitLab, we were forced to use two different tools for our CI/CD. NET Projects and CircleCi for everything else. As these tools were separate from our repositories, the CI/CD results were obscured and required us to context switch in order to consume the information that they provided.

Another drawback of these tools was the lack of control over the process. We relied on the runners provided, which may or may not have been provisioned sufficiently for what we needed them for. This method had implications with security policies for our cloud storage and set up times in terms of debugging problems in our pipelines.

A major setback was the monolithic nature of the pipeline execution as a single stage. The GitLab CI/CD functionality allowed us to create multi stage pipelines, which greatly aided in troubleshooting failing builds, build failures can be viewed via the GitLab user interface, and the multi stage pipeline allows us to easily pinpoint the step that failed without having to retry the entire pipeline or go digging through log files. Today, it's much easier to block a merge request if the pipeline fails, which reduces the number of bugs that are entered into our product.

The ability to host our own runners has also been a game changer. We have sped up our pipelines by ensuring dependencies are present before starting our builds. Another major benefit is the ability to control the security policies on the runners themselves, rather than using access keys to interact with our cloud resources, we set AWS identity access management rules on the runners themselves, which makes it easier to store our build artifacts.

But it has also allowed us to start leaning into infrastructure as code as a company. We leverage infrastructure as code through the automated deployment of Lambda functions with associated API gateways. We've developed internal tool sets that employ infrastructure as code like our track bot, which runs our Slack integrations.

But we'll talk about those later. We also use it for our Help Center resolution service, which drastically reduces the amount of coordination that is needed between our development team and our tech writers. Another way we use infrastructure as code is our self-service site deployment app, which lessens the frequency of requests from our sales team to our cloud team by allowing a site to be automatically deployed to production with the click of a button.

Finally, our Webforms processing service, which provides the ability to host a custom form for unauthenticated ticket submission into an Issuetrak application also runs as a serverless Lambda function. This infrastructure is defined as code within our GitLab repository. T.

department uses infrastructure is code to maintain user permissions in AWS via IAM rules. While we use infrastructure as code for some of our EC2 in development, such as is the case for automated Selenium testing infrastructure, our cloud operations team uses that much more substantially for automating the process of standing up new servers and our customer cloud, which has been a major milestone in our revitalization as a DevOps team. Adopting GitLab and our switch to Agile have both increased our ability to ensure the quality of our code.

In the past, our developers employed the bad practice of merely throwing tickets over the wall and therefore the QA team's only resource was the developers documentation on the ticket with no prior knowledge or understanding of the feature. This practice, unfortunately, allowed for unnecessary refactoring, which had the potential to cause problems that went unnoticed by testers. Without our Scrum processes, we were guilty of cowboy coding and as a result there was little collaboration when it came to the development of new features.

And this created a lot of technical debt by generating an inconsistent code base. We now practice a technique known as paired testing. Developers will pair with a tester before a single line of code is written to discuss the intended changes and potential concerns either person has regarding the plan of action.

This allows developers to gain crucial. This allows developers to gain crucial insights from the minds of testers before starting the code. The pair's continued communication throughout the life cycle of the ticket prevents a substantial amount of rework.

GitLab helps us achieve this by allowing multiple assignees on a ticket simultaneously, a feature that wasn't offered with the other tools we were using at the time. The feature of linking merge requests to tickets in GitLab allows testers to review the code that was modified and to catch potential unnecessary refactoring problems. Gone are the days when testers were completely in the dark, and today we have far fewer unintended consequences when our product is released to the wild.

Stakeholder feedback is another important tool we use to ensure code quality. In the old paradigm, feature acceptance was very disorganized process, various stakeholders would make requests, often directly to the developers with little cross communication with their cohorts. Of course, these requests were never documented.

The results, changing priorities, shifting requirements, rework and delayed output. This exact scenario happened when we were asked to implement a quick search bar in our product, the desk of the developer responsible for this feature, quickly became a common destination for businesses and employees of the company. This resulted in bloated functionality that in production was so non-performing that it ended up being removed altogether.

We solved this through our adoption of Scrum, which requires a dedicated product owner as well as separate reviews. O approval is now required at several stages throughout the development cycle, using another favorite feature of GitLab. We now mark the user stories blocked until work completes on all the associated discrete task tickets.

We have a dedicated column on our Sprint board named Active User Stories, where user stories are placed when any of the work tickets have been chosen for the current sprint. Once the story loses its blocked indicator. O Team at the next Sprint review.

We also now insist that all changes in requirements be documented on the tickets themselves, ending the verbal communications that would often be lost in time. This has dramatically improved our transparency. Speaking of transparency, GitLab's out of the box, integration with Slack allow stakeholders a quick peek into our daily lives.

Certain actions within GitLab will cause a post to appear in our DevOps Slack channel. Those actions are when tickets are opened, closed and notes are added as merge requests are open, approved and merged and build failures because of posts that channel as well as a Scrum master. This channel is my gold mine.

It is literally a wealth of information about my team's productivity. Finally, I'd like to share ways in which we've made use of the GitLab API in order to minimize the amount of work we have to do manually. The first home brewed slack integration we've implemented was a tool for automating our branch maintenance.

To give this some context, when we release a new update, we push to master and then merge master into all of our protected branches. We've since automated this process using Slack Express Lambda, but most importantly, GitLab's API. The first thing that takes place is a developer will enter the command into Slack.

If that user is green-lit to continue the process, they will be given a confirmation box, if that's like user is not authorized, they'll simply get a message indicating that they can't proceed. If the user selects to continue, our bot will automatically create a merge request for every protected branch in our project and then systematically check for conflicts using to GitLab API and finally prompt us to either finalize our merges when no conflicts are found or let us know that we need to do it manually and review the changes otherwise. This has helped us streamline our release process and reduce the potential for human error.

The last integration I'd like to demonstrate is a tool we created for distributed ticket weighing. Here's a ticket I'll use to demonstrate how it works. A Slack user will enter the ticket URL along with the slash command in order to initiate the process.

Using the GitLab API, our bot will automatically pass the URL and determine the project, issue number and title of the issue that then tags all the users we specified in our application. Next prompts viewers to vote for a way they deem appropriate for the issue. A major benefit is that a post the whole description as a snippet within the Slack thread.

This way the team doesn't even need to open get allowed to participate in the story section, which was a complaint we had when using a more generic tool in the past. If you notice up on the top, there's now a new row that's been inserted which contains the names of users we have received a weight from. These people have voted, but their vote remains hidden to avoid inquiry we can now weigh tickets asynchronously, which is super useful in these times of distributed work environments.

Once either everyone on the waiting for lists has weighed in or the reveal button is clicked, we move to the next day. Here we can see the weights selected by the people who have weighed in were then presented a drop down with the weight options and a button to finalize a selection. Users can at this point select the appropriate weight after whatever discussion is needed.

Once that's done, the dropdown and button are replaced with an indicator showing final decision, but also updates the original post. So the channel we use for this part stays pretty clean and easy to navigate. Here's where the GitLab API once again comes into play.

As you can see, the ticket has now been updated with the weight of two and it's undergone the label changes unique to our process and added a link directly to the thread in Slack where the discussion took place, allowing us to regain the context that led to the decision whenever needed. This is removed multiple manual steps that used that to take place for every ticket prior to its consideration for work. If you find this tool like it might be useful, it's actually an open source typescript express app we built and you can find the project on GitLabunder the name GitLab-Slack-Story PokerBot.

There's a configuration file within the project that can be used to easily modify the process to fit your team's needs. Well, we're just about out of time, so I'll wrap up Agile and GitLab. What were we doing without them?

Our product development team is almost unrecognizable now compared to where we were over two years ago. We made the switch and so can you. You belong here.

Thank you to GitLab for inviting us here today. And thank you for watching.