DEV Community: Federico Cerruto

Remote Agile release planning meeting

Federico Cerruto — Sat, 06 May 2023 21:13:03 +0000

Nowadays, it is common for engineering and product teams to work remotely, which makes it essential to set up virtual environments for meetings. This is especially important for the Release Planning Meeting, a key product and project management activity.
To help you get started, this blog post will show you how to set up a virtual environment for your release planning meeting using a Miro board. Before you begin, it’s important to make sure you have the following prerequisites:
A product backlog that is at least partially groomed. You can use tools like the Product Vision Canvas and User Story Mapping to help you prepare it.
A prioritized product backlog. This will help you focus on the most important items and ensure that your team is making progress on the most valuable work.
With these prerequisites in place, you’ll be ready to set up your virtual environment and get started with your release planning meeting.
So, let’s get started.

Product Backlog

To begin, you can start by writing all of your user story titles on the Miro board. Be sure to number each story according to its priority, and consider grouping related stories by epic. This will help you organize your information and make it easier for your team to review and discuss during the release planning meeting.

During the meeting, the Product Owner will use it to make the storytelling and review the priority with the teams.

Relative estimation graph

The estimation phase can start when the storytelling is finished and the team clearly knows the release goals.

The image shown above illustrates a useful tool for team-based estimation. During the release planning meeting, each developer should take turns selecting a story from the backlog and adding it to the graph. This process will allow the team to collectively estimate each story's relative size and complexity, which can help plan and prioritize the work.
When all the stories are placed, ask, in turn, every developer if wants to modify something and let the team discuss the modification.

T-Shirt Size

It’s time to create clusters and assign them a size using the t-shirt size estimation technique

It should be useful to map t-shirt sizes with story points. These could help the team during the next step: Sprint Mapping

Sprint Mapping

When planning a release, you can either fix the scope or fix the time. In the former, you need to determine how many sprints the team will require to develop all of the features in the release. In the latter, you need to identify which features the team can release within the fixed time period.
In either scenario, the velocity metric can assist. As a measure of how many story points a team can complete within a single sprint, velocity can help to determine the number of sprints needed to complete a release. For example, if a release requires 60 story points and the team has a velocity of 20, it can be inferred that the team will require 3 sprints to work through the backlog items identified for the release.

During this phase, the team adds the prioritized features to the sprint backlog until the total story points match the team’s velocity. Once this capacity is reached, the team will move on to the next sprint and continue with the remaining items in the release backlog.
This phase can help to identify cross-team or external dependencies that could also modify the sequence of work. In the image above the dependencies are the green sticky notes.
Risk Board
The participants should identify risks for the overall project and the already-known requirements. Then, they should evaluate the risks and define some mitigation actions.

Finalize

The release plan is complete. Ensure that it is accessible to all team members and let’s proceed with implementation.

Patterns for container base images management

Federico Cerruto — Fri, 23 Dec 2022 17:40:40 +0000

A lot of organizations are adopting and implementing Platform Engineering. In the book “Team Topologies” the authors write that the platform team provides internal services (reusable components) that the stream-aligned team can use.
So, a platform team builds reusable components to allow organizations to scale faster. Could container base images be considered reusable components? I think yes, it depends on the maturity grade of the Platform.
But, let’s take a step back and try to define a base image: base image (technically parent) refers to the contents of the FROM directive and it’s the image that your image is based on. Commonly, the base images are customized, adding configurations, packages, and tools needed by the applications and then needing some maintenance and security updates.
Large organizations usually centralize the responsibility of these tasks, but is it the best approach? Let’s see together the pros&cons of this approach and a potential alternative.

The schema above shows two different patterns for managing container base images: the blocks are image layers, and their coloring means who is responsible for it.
On the left side is represented the pattern according to which updates and security issues should be made by the Platform Team, then all the development teams use this image and add to it the application code. This pattern has the pro that you can fix in one place but, at the same time, the Platform Team could become a bottleneck when it has to deal with multiple demands from multiple teams.
On the right side, there aren’t common libraries then every team could create their image and does their things, according to their needs. This reduces the dependencies between teams but can potentially generate a lack of security and also a potential for chaos.

Zero Trust security with Kuma Service Mesh

Federico Cerruto — Tue, 29 Nov 2022 21:33:48 +0000

Zero Trust isn't a buzzword, in the era of the hybrid cloud and the multicloud most companies are changing their approach to security. The Zero Trust model drastically changes the way to secure IT systems, in fact, it assumes that everyone could be an attacker, so every access needs to be authenticated and authorized.
In Kubernetes, every workload can communicate with one another without any restrictions, so Kubernetes doesn't guarantee Zero Trust Security and if you want to achieve it, you need to build or use something on top of the Kubernetes network. A Service Mesh can help you to resolve this problem by managing identity, introducing authorization through mTLS, and defining traffic policies.

Kuma

Kuma is a mesh control plane for both K8s and VMs with native multi-cloud and multi-cluster connectivity. It was developed originally by Kong Inc then donated to the CNCF (Sandbox project), and now is at version 2.0.
How we can implement Zero trust security with Kuma?
Kuma allows you to manage and issue certificates in a declarative way, you can choose to use the built-in CA or to provide your existing one. In this way, every service in the mesh will have a certificate (identity) and all the connections will be authorized through mTLS. Below you can see how to enable the mTLS policy.

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default
spec:
  mtls:
    enabledBackend: ca-1
    backends:
      - name: ca-1
        type: builtin
        dpCert:
          rotation:
            expiration: 1d
        conf:
          caCert:
            RSAbits: 2048
            expiration: 10y

Ok, now all the services have an identity but, by default, all the services can communicate with each other, because of an existing Traffic Permission Policy.

apiVersion: kuma.io/v1alpha1
kind: TrafficPermission
mesh: default
metadata:
  name: allow-all-traffic
spec:
  sources:
    - match:
        kuma.io/service: '*'
  destinations:
    - match:
        kuma.io/service: '*'

Through this policy, all the traffic is allowed within the Mesh. If you want to enforce Zero Trust, allowing only some specific paths, you should define your own Traffic Policies. An example below:

apiVersion: kuma.io/v1alpha1
kind: TrafficPermission
mesh: default
metadata:
  name: demoapp-to-redis
spec:
  sources:
    - match:
        kuma.io/service: demo-app_kuma-demo_svc_5000
  destinations:
    - match:
        kuma.io/service: redis_kuma-demo_svc_6379

What are the benefits of using Kuma to implement Zero Trust security?

Kuma allows the developer to focus only on the development of the business features, ignoring all the security aspects. In this way, you prevent every team develops its security framework, reducing the cognitive load of every developer and, in a heterogeneous ecosystem, a huge code fragmentation.
Kuma also reduces the manual effort to rotate the certificates when they expire and to provide a certificate for every service of your applications. In fact, when you define the mTLS policy, every service that joins the Mesh will be provided with its own certificate automatically.

Scrum patterns for high performing teams

Federico Cerruto — Fri, 29 Jul 2022 05:56:59 +0000

Some years ago I was involved in an agile adoption process. It was an incredible experience that allowed me to work as a Scrum master and learn many new management skills through a long training on the job.

A very smart Agile Coach drove the adoption process and held some classes, one of them was very powerful and gave me a lot of insight that I applied in my daily work. The title of the class was: High Performing Scrum, it was focused on the exploration of some patterns collected and explained by the ScrumPLoP group. This is how they introduce their mission on their website:

Alistair Cockburn describes software development as a cooperative game. Scrum provides one set of rules for one such way of playing the game. The Scrum Guide is the official rule book. However, the Scrum Guide doesn't tell you the rationale behind Scrum as a whole, or behind many of its successful practices. Those rationales come out of experience, community, and the insights of its founders and inventors. The ScrumPLoP mission is to build a body of pattern literature around those communities, describing those insights, so we can easily share them with the Scrum and Agile communities.

They organized the patterns into two main categories: Product Organization Pattern Language, and the Value Stream Pattern Language, but what is a pattern language? A pattern language is the set of rules for combining the patterns in meaningful orders; as a “language” it has a grammar that can generate all sequences that are meaningful “sentences.” While the number of combinations of patterns is large, not all orderings make sense. No pattern stands alone, it’s a system, it’s tempting to cherry-pick patterns and try to apply them to solve problems in isolation, but in a complex system changes we make in one place may have unintended side effects elsewhere, so context is everything.
Applying each pattern in the broader context of the patterns that are already there helps us avoid unintentional setbacks from side effects. A pattern language strives to order patterns in a way that minimizes such setbacks.

So, let's have a look at a language described by Jeff Sutherland who believes can help new teams to have a good start and can help make even the best teams even better.

Jeff's project language unfolds like this:

First, just get started. Start with Stable Teams.
Next, decide how you are going to size your releases every Sprint. Start developing and establish a velocity (see Notes on Velocity) and bring it into statistical control: use Yesterday’s Weather.
Next, work on getting stuff Done (see Definition of Done instead of foundering in rework. It takes teamwork to do that. Use the pattern Swarming: One-Piece Continuous Flow.
Interruptions are one of the largest potential killers of velocity. You need to know how to deal with interruptions during the Sprint. We presume you have a ScrumMaster, but you need a more finessed technique that suggests a framework of discipline to make interruptions visible and structure how you deal with them. Try Illegitimus Non Interruptus.
Focus on quality from the beginning, every day. Early on, strive for Good Housekeeping.
Stuff happens, and dealing with emergencies is a discipline. Align the organization to deal with emergencies using the disciplined replanning of Emergency Procedure.
The heart of Scrum is process improvement. Get into a rhythm of improving your process every Sprint with Scrumming the Scrum.
Part of improving is to measure—but measure more with the heart than with raw numbers. Drive forward with the Happiness Metric.
Revisit how you are sizing your Sprints. Instead of pushing the team to take more and more into the Sprint, refocus on Yesterday’s Weather and give yourself room to improve. Try Teams That Finish Early Accelerate Faster.

It's very important to apply one step at a time, if you change multiple things at once, it’s hard to know which one led to an improvement.
I tried it with my teams getting impressive results and generating a lot of enthusiasm for both in the team and the whole organization.

If you want to discover and try other languages, you can surf the Scrum Plop website and look for a sequence that is designed to address a problem you have or to improve a particular aspect of your team/organization.

DORA metrics: a Google open source tool for tracking them

Federico Cerruto — Wed, 22 Jun 2022 20:29:46 +0000

DORA stands for DevOps Research and Assessment and is a research group acquired by Google in 2018. Their goal is to help organizations achieve high DevOps and organizational performance with data-driven insights. In their 2018 book, Accelerate, they identified a set of metrics (4) that could help organizations measure their team's software delivery performance, to improve them. Improving the delivery performance will have an impact on the business

These four key metrics are:

Deployment Frequency: how often an organization successfully releases to production. This metric doesn't say if you are releasing valuable software or not, but if you don't release frequently there's nothing to measure
Lead Time for Changes: the amount of time it takes a commit to get into production. This metric should be very useful for improving the release process: if it's too long maybe the process needs some changes.
Time to Restore Services: how long it takes an organization to recover from a failure in production.
Change Failure Rate: the percentage of deployments causing a failure in production. From a business point of view, it’s essentially an indication of the business risk of making changes.

The first two are velocity metrics, the last two are stability metrics.

I looked a lot for a tool that could help my team track these metrics. I knew that Jira, Gitlab, and some other tools implement these features but I was looking for something with a high level of customization, and not so coupled to a specific product (we use different systems for deployment, change, and incident) and one day I incidentally discovered FourKeys.

FourKeys is an open-source project developed by Google, it consists of a generalized ETL Pipeline that can be extended to process inputs from a wide variety of sources. The pipeline ingests the data into Bigquery and then they should be displayed in a Grafana dashboard.

The Github repo contains all the instructions to set up and run the project, here instead we can focus on the architecture.

The events are generated by your development environment, or better to say, by the tools you use in your dev environment. Gitlab, Github, Tekton, and Circle-CI are supported out of the box, and you can easily extend the supported set of tools.
The handler is a Cloud Run endpoint, it collects the event and pushes them into the appropriate Pub/Sub topic.
Another instance of Cloud Run consumes the events, makes some transformations and then inputs the data into BigQuery. At first, the data are sent into a raw events table (it's your operation log). From there, some scheduled query read from the log table and write to three different tables: Incidents, Changes and Deployments.
These tables are used to calculate the metrics and show them inside a dashboard.