DEV Community: Daniel McCrady

Increasing Velocity the Right Way and the Wrong Way

Daniel McCrady — Thu, 23 Feb 2023 19:37:57 +0000

We love agile development at Foci Solutions. One of our main offerings is to coach clients on how to use agile to deliver quality products to their customers. Along this journey we often get asked the question "How do we increase velocity". This question is complex and often times misunderstood.

Velocity is a metric that is critically important, and yet can be fairly arbitrary. What I mean by that is velocity is used to drive priority decisions, estimate the time a feature will take, and is used to measure the business value that a team is delivering. At the same time velocity will be different for every team, has a variance of uncertainty built into it, and can take multiple sprints for velocity to even have a use.

Its critical then to understand what velocity is and be aware of how velocity can move. scurm.org describes velocity as:

an indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team. There is no such thing as a Good Velocity or a Bad Velocity. Remember, it is based on relative estimations

What this means is that velocity is a number used by the development team to track how much value they are delivering to the client. What is important to take from this is that it's tracked by the development team, for the scrum team. This means that the development team has sole responsibility to how the velocity moves inside the team.

As a manager or product owner if you only care about raising velocity at any and all costs developers will achieve this in the following ways

Developers can begin to sand bag estimates during backlog grooming. What used to be a 2 point story is now an 8 point story.
Developers start to cut corners. Maybe their unit tests aren't as robust, There error handling doesn't handle as many errors, Or they don't consider edge cases as much.
Developers start to work longer hours, take less breaks, and eventually burn out.

All of these scenarios cause a bump in velocity, however the outcomes of these scenarios are often disastrous. By sand bagging estimates, developers stop feeling like their input matters, no extra value is actually being delivered with the increased velocity which makes the metric significantly less useful. If the developers begin to cut corners it will become hard to know when software is ready, increase the bug rate, increase technical debt, and make software more expensive to deliver. Worst of all if developers start to work longer hours then the velocity bump is truly temporary. The velocity will drop as developers stop having as much passion for the code they develop and the work slowly takes a toll on their mental state. This continues until inevitably the developer crashes and decides to look beyond the company to change jobs.

So how do we responsibly increase velocity without incurring negative side effects? We can find a great example of this inside of UPS. An optimization occurred at UPS where they recalculated all of their trucks routes to eliminate as many left hand turns as possible. The effects of this decision were staggering. It's estimated that this decision saved UPS over 100 million gallons of fuel every year. This kind of decision is the true way to increase velocity, by looking into the way we deliver value and doing it differently. We need to find things that can be done to increase velocity and at the same time increase value to customers now and forever. We can do this

Through automation
Through process optimization
Through planning
Through collaboration

We can spend some velocity now to increase velocity tomorrow by working to automate work developers are doing on a regular basis. Add more automation to CI/CD pipelines so developers can spend less time completing Pull Requests. Look to automate complex deployments so that a developer doesn't need to do it. Automate complicated testing plans so the a QA team can spend their time elsewhere.

Look to the process and find ways to reduce the process burden on the peoples time. This is going to vary widely based on the process you and your team has, however burdensome processes like Change Review Boards, Approval Gates, and long drawn out testing phases are often good places to look. This doesn't mean you need to make deployments riskier, however your team may need to introduce different tools, look to automation, or think outside the box to make the process less restrictive in delivering value.

Often times agile software development is often tied to doing now and thinking as we go. Taking time to come up with a solid short term plan can help in finding blockers earlier, and ensuring that the team is on the same page.

Everyone needs to come to the table and be willing to change how they work today in order to find velocity. Product Owners, QA, Managers, and even executives should be available for these discussions. Collaboration is critical to finding the largest velocity gains.

I'm sure there are other areas in your company that velocity can be found as well. Just ensure that the change is long lasting and real. Make sure the you are gaining velocity the right way.

K8s in KIND

Daniel McCrady — Thu, 01 Apr 2021 02:40:20 +0000

I have been playing around with Kubernetes lately and was looking for an easy way to get a cluster going locally. I came across Kind when looking for this solution and found it really easy to use.

It's super easy to get a cluster going especially if you already have kubectl installed. It's fast to install kind as you can just download the executable and include it in your path.

In PowerShell for example

curl.exe -Lo kind-windows-amd64.exe https://kind.sigs.k8s.io/dl/v0.10.0/kind-windows-amd64
Move-Item .\kind-windows-amd64.exe c:\some-dir-in-your-PATH\kind.exe

Getting a cluster going after installation is just as easy

Commands:

docker ps
kind create cluster
docker ps
watch kubectl get nodes

After a few seconds you will have a control plane up and ready to accept commands. I think it will be really fun to explore what can be done by having a Kubernetes cluster available in such a short amount of time.

MULTI STAGE PIPELINES & AZURE DEVOPS

Daniel McCrady — Fri, 17 Apr 2020 16:36:32 +0000

Many years ago, I wrote a blog post about TFS and DevOps. A lot has changed since then, with multiple versions of the build pipeline being released, but it continues to be one of the most trafficked articles on our site. Microsoft has worked hard to create a better experience for build automation and continuous integration – so I worked hard on updating this walkthrough. Recently, Microsoft released the idea of multi stage pipelines that work and feel much like how GitLab CI works.

In this post I’ll walk through a basic YAML file and show how you can get a C# project up, built, and tested quickly.

Setup

We need to have a project that is checked into DevOps before we begin. I have a repository that I made for this blog up on DevOps. that is a basic dotnet core console application and a unit test project that goes along with it. At the time of writing this blog post you will also need to turn on the multi-stage pipelines Preview Feature in order to get the best view for these pipelines. You can do that by clicking on the user settings button

Then click on preview features

Then ensure that multi-stage pipelines are enabled

First Steps

First we need to add a YAML file into our project. I tend to put this file directly at root and name it azure-pipelines.yaml. Then we need to define our stages. A stage is a collection of jobs and can be run concurrently or can be dependent on another stage successfully completing. For this quick project we will have two different stages

Build
Test

In order to define these stages in our pipeline we need to write some YAML like

stages:
  - stage: build
    displayName: Build
  - stage: test
    displayName: Test
    dependsOn:
    - build

this will give us building blocks to add our jobs. If you check this file into DevOps and navigate to pipelines you can see that we have a pipeline defined without any runs associated to it.

Adding a Job

A job runs on a build agent. By default DevOps provides hosted build agents. These agents are a pre-configured VM that have a lot of different development tools pre-installed. I’ll be using the hosted agents for this post.

Let’s add in some YAML to add a job that will build our dotnet solution. We can do this in one of two ways, we can use a DevOps “task” or we can write a script. Tasks can provide a lot of features that you would normally need to script yourself. These can be very helpful, however it also hides a lot of what is being run. I tend to try and use tasks as they get updated regularly to add additional features and fix bugs. Microsoft hasn’t made tasks to solve every problem however so you will need to write some scripts eventually.

Example as Task

variables:
  buildConfiguration: "Release"

stages:
- stage: build
  displayName: Build
  pool:
    vmImage: "Ubuntu 16.04"    
  jobs:
  - job: build_dotnet_solution
    displayName: build dotnet solution
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: build
        arguments: '--configuration $(buildConfiguration)'
- stage: test
  displayName: Test
  dependsOn:
  - build

Example as script

variables:
  buildConfiguration: "Release"

stages:
- stage: build
  displayName: Build
  pool:
    vmImage: "Ubuntu 16.04"    
  jobs:
  - job: build_dotnet_solution
    displayName: build dotnet solution
    steps:
    - script: |
      dotnet build --configuration $(buildConfiguration)
- stage: test
  displayName: Test
  dependsOn:
  - build

In both examples I have added a variable to set the build configuration setting for the pipeline. Variables are very helpful and DevOps also provides a lot of pre-defined variables for you. You can ready about them here.

Artifacts

Now that we have our job running and our solution is being built. We will probably want to retain these files. We will need to artifact these files if we want to use them in a different job, or we can download them later for manually testing the build.

variables:
  buildConfiguration: "Release"

stages:
- stage: build
  displayName: Build
  pool:
    vmImage: "Ubuntu 16.04"    
  jobs:
  - job: build_dotnet_solution
    displayName: build dotnet solution
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: build
        arguments: '--configuration $(buildConfiguration)'
    - publish: $(System.DefaultWorkingDirectory)/src/demo-project/bin/$(buildConfiguration)/netcoreapp3.0/
      artifact: source
- stage: test
  displayName: Test
  dependsOn:
  - build

Once the build is completed you should see the artifacts on the build page. You can download them and use them in different jobs now.

Testing

Now that we have our code built, we can go ahead and run the tests for our application. DevOps also has the ability to show us test results through its dashboards. It’s easiest to use the task for this, as the task has capabilities to upload the tests results for us.

variables:
  buildConfiguration: "Release"

stages:
- stage: build
  displayName: Build
  pool:
    vmImage: "Ubuntu 16.04"    
  jobs:
  - job: build_dotnet_solution
    displayName: build dotnet solution
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: build
        arguments: '--configuration $(buildConfiguration)'
    - publish: $(System.DefaultWorkingDirectory)/src/demo-project/bin/$(buildConfiguration)/netcoreapp3.0/
      artifact: source
- stage: test
  displayName: Test
  dependsOn:
  - build
  jobs:
  - job: test_dotnet_solution
    displayName: test dotnet solution
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: test        
        arguments: '--configuration $(buildConfiguration)'

With this, you now have a basic build and test pipeline that will run with every check-in to your repository. There is a lot more that can be done, such as managing environments and performing releases. I hope that this is a good starting block to get you moving with DevOps.