DEV Community: Foci Solutions

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.

What is Lean Inception?

Joe Pound — Thu, 16 Feb 2023 16:35:37 +0000

This article is the first in a series of articles about our experience with Lean Inception. Be sure to check out our other posts.

Lean Inception is the combination of Design Thinking and Lean StartUp to decide the Minimum Viable Product (MVP). It is a workshop divided into several steps and activities that will guide the team in building the ideal product” (Lean Inception, caroli.org/en/livro/lean-inception-how-to-align-people-and-build-the-right-product/). It is the creation of Paulo Caroli, a software engineer who wanted to find a way to condense a four-week inception program run by Thoughtworks. What he produced was a methodology, which included a series of activities executed over one week that allows a team to set the direction and scope of a product at the outset.

In the years since its creation, the Lean Inception methodology has undergone various modifications, including adapting in-person exercises to a Miro template for remote teams. More details about the process of Lean Inception can be found at Paulo Caroli’s website.

At Foci, we have been running Lean Inception for our own internal R&D product to improve our overall understanding of the Lean Inception process—and ultimately using this process to help our clients through better product development, and help our readers with their own application of Lean Inception by sharing our experiences.

Core Concepts

The Lean Startup

Before Lean Inception, there was The Lean Startup by Eric Ries. In The Lean Startup, Ries describes the Build–Measure–Learn methodology. This methodology assumes your products are validated frequently during development with actual customers, enabling you to understand what holds the most value for them and, ultimately, what will best meet their needs. Caroli designed Lean Inception to find the first increment that could be built in an effective Measure and Learn cycle.

MVP

For Caroli, this first increment was the Minimum Viable Product (MVP). MVP has become a loaded term in software development (as we’ll discuss in our future posts), but Caroli seeks to emphasize that an MVP should be developed only just enough to allow you to test your product hypothesis.

He uses the example of EasyTaxi, a Brazilian business that allows users to request taxis online. To verify if people would actually use such a service, the original application was a simple webpage that would send an email to the EasyTaxi founder at the user’s request, at which point the founder would call a taxi for the user. While very rudimentary, it demonstrated to the founders that their project was in demand and had the potential to become a viable product.

Caroli emphasizes that the MVP is not a complete layer (like building all your infrastructure first, for example); he describes it as a cupcake—instead of a complete cake with icing (the UX ‘wow factor’), it has been scaled down to a manageable size. This approach is also commonly referred to as a ‘vertical slice’, referencing slicing a cake through all its layers, top to bottom, rather than one layer at a time. As we will see, these core concepts are essential to the success of Lean Inception activities. There are many times when Lean Inception can easily get sidetracked, at which point returning to these core concepts can help realign the work.

What is Involved?

Over a period of one week, our team went through a series of activities that established the following:

Product vision
What the product does and does not do
Initial product goals
Personas
Prioritization of product goals by persona
User journeys
Feature brainstorming
Initial technical, business, and UX review of features
Sequence and iterations for features to be delivered as part of the MVP.

Why We Did It

As consultants, we have experience working through tough challenges across multiple and varied projects. Clients often assign a series of requirements or tasks to engineering teams; however, these teams will struggle to deliver the right product when they cannot answer basic product questions:

What are the vision and goals for the product?
What are the stakeholder expectations behind these requirements?
What kind of users are you targeting?

Many clients have difficulty documenting these answers and even those who do document their work often do not share it with the teams building the product. According to Asana, the “2021 Anatomy of Work Index, which surveyed over 10,000 knowledge workers, found that less than half of all employees understood how their day-to-day work contributed to broader goals.” (Why Projects Fail).

At Foci, when we first heard of Lean Inception, we saw it as an opportunity to coach our clients through some of the most important discovery processes in a project lifecycle. Lean Inception would ensure that their whole team has a clear shared understanding and vision of the product, resulting in more collaboration, less conflict, and greater value earlier in product delivery.

What’s Next?

Stay tuned for our following blog posts. There we will explain our own experience running Lean Inception on an internal project as well as some lessons we learned and suggestions on how you can improve your first Lean Inception.

The post What is Lean Inception? appeared first on Foci Solutions.

Nullable reference types in C# 8.0

Alex Yorke — Mon, 12 Apr 2021 15:29:42 +0000

Nullable reference types are a new feature in C# 8.0. They allow you to spot places where you’re unintentionally dereferencing a null value (or not checking it.) You may have seen these types of checks being performed before C# 8.0 in ReSharper’s Value and Nullability Analysis checks.

These are potential sources for bugs, and can cause application crashes and NullReferenceExceptions. C# 8.0’s compiler supports nullable types, and can warn you when you are dereferencing a null value without first checking if it is null if the type ends with a “?”; consequently, any type without a “?” added to the end is a non-nullable reference type. For everything else, it’ll use flow analysis. In this article, I will explain how you can use nullable reference types to help make your code less prone to NullReferenceExceptions, and to make it more consumable by other APIs.

Null attributes

There are also a few attributes you can use to declare the arguments and return values for null-related code. These attributes extend the nullable types and allows the compiler to make more judgements:

AllowNull, the argument could be null, even if the type doesn’t allow it. For example, we are setting a string inside of a getter/setter to null. In C# 8.0, strings are known as a nullable “string!”, and so the AllowNull annotation allows setting it to null, even though the string that we return isn’t null (for example, we do a comparison check and set it to a default value if null.) This is a precondition.
DisallowNull, the argument isn’t null, even if the type allows it. This is a precondition.
MaybeNull, the output might be null. So, the callers have to check if the output is null. This is a postcondition.
NotNull, which means that the input wasn’t null when the call returns, even if the type allows it to be null. This is a postcondition.
NotNullWhen, which is a post condition that asserts the argument isn’t null depending on the boolean value of the return of the method. For example, say my method is bool MethodA([MaybeNullWhen(false) out string outVal], and it returns true. Then outVal isn’t null. If it returns false, then outVal could be null.
MaybeNullWhen, “signifies that a parameter could be null even if the type disallows it, conditional on the bool returned value of the method.” This means that if I were to annotate an argument with [MaybeNullWhen(false)], then the output (signified through the “out” keyword) could be null if the method returns false. This is a postcondition.
NotNullIfNotNull, “signifies that any output value is non-null conditional on the nullability of a given parameter whose name is specified”. What this means is that if I pass in a “string?” the output’s nullability is true, and vice-versa. This is a postcondition.

There are some other conditions, such as:

Why are these checks important?

These checks help ensure the safety of the code you write, and also allows other consumers of your library to know when to use null checks (and where to omit them.) While it is possible to null check every call that is null-ambiguous, it can be error-prone because:

Too many null checks clutter the code and wastes time trying to create error handlers to safely stop program execution.
You might forget to write a null check, and because there are null checks for everything else, it is unclear which method is missing a null check.

Here is an excellent example from Microsoft’s docs:

string? userInput = GetUserInput();if (!string.IsNullOrEmpty(userInput)){ int messageLength = userInput.Length; // no null check needed.}// null check needed on userInput here.

In this case, they annotated the string.IsNullOrEmpty method with [NotNullWhen(false)], which means that if the method returns false, then no null checks are needed. The annotation can be read as “it’s not null when the output is false”. These higher-level logical statements help the compiler make inferences about the code. While this sounds like a trivial comparison to do through the compiler only without annotations, it’s actually a very complex research topic.

Microsoft Pex, a “White-Box test generation for .NET” is a program that analyses every possible path through your program symbolically to discover edge cases and missing conditionals that can cause NullReferenceExceptions (and more.) While it is extremely interesting, it’s a bit outside the scope of this post.

How do I use them?

If you are upgrading a legacy project, Microsoft recommends that you don’t turn it on for everything at once, but there might be a lot of warnings and it could be overwhelming. This is especially true if your team treats warnings as errors (a compiler option), as development would have to cease for several days to fix the null warnings. This isn’t a great strategy, and so incrementally enabling null checks helps prevent an explosion of warnings that could go ignored if not addressed promptly.

There are a few ways you can prioritize adding null annotations for the first set of checks. One of the ways is to start with the very small, straightforward methods. If the method is easy to reason about, then adding the null annotations can be easier to do, and if the small method is used throughout the code many times, then it can help infer what null checks are and are not needed in larger methods. While there are potentially infinite many ways to prioritize null checks, this approach can be helpful if you are not familiar with null checking.

Conclusion

Null reference types can help make your code more maintenance friendly and easier to spot bugs, as nulls can cause unexpected problems and application crashes. While nullable reference types aren’t a panacea (as it is possible to ignore the warnings), they can help provide the compiler with extra information. This extra information can be used to deduce errors and find logic errors. Gradually implementing nullable reference types helps find potential errors without overwhelming the developers with warnings. If there are too many warnings, they could be disregarded, further causing more problems down the line.

The post Nullable reference types in C# 8.0 appeared first on Foci Solutions.

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.

GitHub Actions – Deploying an Angular App

Hannah Sun — Tue, 21 Apr 2020 16:26:21 +0000

Recently I built an Angular demo application that showcases some of the features provided by Angular. I will deploy this application to GitHub pages using GitHub Actions, a newly released CI/CD platform that can be used by open source repositories for free.

Since I already have a completed Angular project pushed to GitHub, all I need to do is to create a GitHub workflow to build, test, and deploy the Angular application to GitHub Pages. Before I start, I need to create a folder named .github/workflows at the root of my repository.

To learn more about GitHub workflow, please read workflow syntax for GitHub Actions article.

Create a GitHub Actions Workflow File

In .github/workflows, I added a yaml file for the workflow. And inside the workflow file, you can choose to add the name of your workflow by adding:

name: workflow name

If you omit name inside the workflow file, GitHub will set workflow name to the workflow file path relative to the root of the repository.

GitHub is flexible with however you want to name your workflow file, but the file has to be a yaml file and it has to be in the .github/workflows folder.

Setup Workflow Trigger

A workflow trigger is required for a workflow. I configured the workflow to trigger on pushes to the master branch:

on:
  push:
    branches:
      - 'master'

If you want to use a different trigger for your workflow, please take a look at events that trigger workflows article and on section of workflow syntax for GitHub Actions.

Create the Angular Build And Test Job

In GitHub Actions, jobs are defined by a series of steps that are executed on a runner. Each job runs on a different workspace, meaning that files and job side effects are not kept between jobs. In order to reduce build time and build complexity, I will keep as much work inside one job as possible.

Thus, the job below is created to build and test the Angular application:

jobs:
  build:
    name: Build and Test
    runs-on: ubuntu-latest
    steps: ...

The latest version of Ubuntu GitHub-hosted runner is utilized for this job. But if you want to use a different Github-hosted runner, pease read virtual environments for GitHub-hosted runners article.

Checking out source code

Since jobs do not pull down the source code by default, you need to explicitly tell the job to do so. Therefore, I add the following to steps of build and test job:

- name: Checkout
  uses: actions/checkout@v1

Setup Node.js

To setup Node.js used by the job, add the following under steps of the job:

- name: Use Node 12.x
  uses: actions/setup-node@v1
  with:
    node-version: '12.x'

Build and test job is configured to use Node.js version 12.x. If you wish to use a different version, please take a look at using Node.js with GitHub Actions article.

Run build and test

To build and test the Angular application, I added some supporting scripts to the application’s package.json file:

"build:ci": "ng build --prod --sourceMap=false --base-href /YOUR_REPOSITORY_NAME_HERE/"
"test:ci": "ng test --watch=false --code-coverage --source-map true"

As you can see, the test:ci script will also generate code coverage results for us, which will be used later down the line.

Note: To avoid MIME type error due to invalid path, you need to set your base-href to your repository name

Then, I add the following to the job to build and test our application:

- name: Install dependencies
  run: npm ci
- name: Build
  run: npm run build:ci
- name: Test
  run: npm run test:ci

Upload artifacts

To expose the results of the current job to the next job, I need to configure build and test job to upload the build artifacts. I also configured the job to upload the code coverage results, so they can be reviewed.

- name: Archive build
  if: success()
  uses: actions/upload-artifact@v1
  with:
    name: deploy_dist
    path: dist
- name: Archive code coverage result
  if: success()
  uses: actions/upload-artifact@v1
  with:
    name: deploy_coverage
    path: coverage

if: success() is used to make sure upload artifact only runs if all the previous steps passed. For more information, read context and expression syntax for GitHub Actions article.

Create Deploy Job

With build and test job completed, I can create the job that will deploy the Angular application to GitHub Pages. I add the following yaml below build and test job:

deploy:
  runs-on: ubuntu-latest
  needs: build
  steps:
      - name: Checkout
        uses: actions/checkout@v1
      ...

needs: build is used to tell GitHub to only execute deploy job when build and test job completed successfully.

Download build artifact

I add the following under steps in the deploy job to download build artifact from build and test job:

- name: Download build
  uses: actions/download-artifact@v1
  with:
    name: deploy_dist

To learn more, take a look at persisting workflow data using artifacts article.

Deploy to GitHub Pages

I use GitHub Pages Deploy Action to deploy our Angular build to gh-pages branch of the project repository:

- name: Deploy to GitHub Pages
  uses: JamesIves/github-pages-deploy-action@releases/v3
  with:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    BRANCH: gh-pages
    FOLDER: deploy_dist/YOUR_PROJECT_NAME_HERE

GITHUB_TOKEN is used to avoid providing a personal access token, to learn more about GITHUB_TOKEN, read authenticating with the GITHUB_TOKEN article.

Conclusion

Once you check in your workflow file, which should look similar to the yaml below, to your master branch, you should see a GitHub workflow starting in the GitHub Actions page. When the workflow is complete, you will see the build output and test coverage results in the artifacts section and a branch called gh-pages will be created.

name: workflow name

on:
  push:
    branches:
      - 'master'

jobs:
  build:
    name: Build and Test
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Use Node 12.x
        uses: actions/setup-node@v1
        with:
          node-version: '12.x'
      - name: Install dependencies
        run: npm ci
      - name: Build
        run: npm run build:ci
      - name: Test
        run: npm run test:ci
      - name: Archive build
        if: success()
        uses: actions/upload-artifact@v1
        with:
          name: deploy_dist
          path: dist
      - name: Archive code coverage result
        if: success()
        uses: actions/upload-artifact@v1
        with:
          name: deploy_coverage
          path: coverage
  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Checkout
        uses: actions/checkout@v1
      - name: Download build
        uses: actions/download-artifact@v1
        with:
          name: deploy_dist
      - name: Deploy to GitHub Pages
        uses: JamesIves/github-pages-deploy-action@releases/v3
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          BRANCH: gh-pages
          FOLDER: deploy_dist/angular-demo

Ensure that your repository has GitHub Pages enabled and the deployment is based off gh-pages branch. If this is set up properly, your Angular application should be deployed!

The post GitHub Actions – Deploying an Angular App appeared first on Foci Solutions.

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.