Am I getting better?

Our technical director put this very picture into each presentation with a comment: “I want you to be like them.”

Greetings, dear reader.
')
In the atmosphere of interaction, flexibility and close interaction (in the bourgeois - Agile and DevOps) there is such a thing as Continuous Learning. In essence, the general idea is to recognize a simple fact: no matter how hard you work, whatever professional you are, you can always be better.

In order not to cause an inferiority complex, I made it a rule that my efficiency is 95%.
These figures are taken from the ceiling, but it gives me the right to realize that I am sufficiently involved in the process, I try to squeeze the most out of my opportunities, but there are always 5% of which I lack to the ideal. Gaining new knowledge, I try again - but the numbers always remain the same - 95% and not a percent more.

However, every time I ask the same question - am I getting better?

In Scrum, there is such an interesting process as refinement (or estimation). Each team member holds in his hand a deck of Scrum poker cards and prepares to show a card with the number of points for each story. The story is discussed, decomposed, chewed to the smallest detail until absolutely all team members understand exactly what needs to be done and how. At the moment when a consensus is reached the owner of the product says the sacred phrase: "Evaluate?". On one-two-three players show a map, looking at each other's ratings, and, if they differ, discuss again until everyone comes to the same assessment.

There are many ways to determine the assessment, but we in our team (given that we are not developers, but engineers) took the following criteria as a basis for evaluation: duration, complexity, risk, uncertainty, and interaction with third parties (read by neighboring teams).
For example, there is a task - to inventory all the subnets that we use. This is not a difficult task, in principle it is enough to climb on the core routers, look at the virtual switches in VMware, in case of emergency - chat with other engineers or scrape the bottom of the box looking for old documentation. However, you can spend a whole week, or even two, looking for each ipshnik. And how to evaluate this task?

But there is another task - for example, to master the dynamic inventory of Ansible, in the particular case - the same VMware. It is also an easy task at first glance, but if you go deeper, another question will arise - how to group? By tags, resource pools or networks? Or build large groups based on data centers and subsidiaries in clusters? Do I need to add ESX hosts or just guest virtuals? This task, in addition to the "complexity", has a criterion of obscurity.

Well, the very pulp. We take as a basis that the “biggest task” that will take one engineer for 2 weeks is equal to 5 points. From here comes the following negative point:

• The Fibonacci sequence does not have the numbers 10 or 15 - how to estimate if the task takes 2 engineers for the whole sprint?
• In this case, the team speed remains fixed at X * 5, where X is the number of points. How then to objectively assess the ability of the team to grow?

Denote the standard task

Above it is already clear that it is not the most correct decision to make an assessment based on the deadlines.
Then we take some standard task - for example, to prepare for the development team 1 server. The server can be hardware or virtual, it must be installed / created, the OS must be installed on it, ipshnik assigned, added to the domain, backups and monitoring configured, documentation recorded, server transferred to the stakeholder. The story is standard, every member of the team will cope with it, no one needs to explain / train anything to anyone - 1 point.

Being based on a certain standard, a person understands: “An hour to do this, half an hour to this, I still need to roll, well, I can do it in a day.” Having a standard, you can evaluate other tasks in a similar way, even with a large amount of uncertainty.

For example, Puppet - the neighboring guys accompanying the front have already eaten a dog on it, and we don’t use it much (well, we don’t need much mind to write the nodes and the roles). And here's the situation - you need to write your own module for amavis so that mail scanners can be deployed in 5 minutes, instead of an hour. The benefit is obvious, the benefits are unmeasured, Infrastructure-as-Code is the same. But no one can write modules. And here is another chain - to smoke manuals, go to the guys for the best practitioners, develop, prescribe a test environment, test, fix, test, fix, add a module to Puppetfile, etc. - A lot of everything. This is where an engineer can give up slack - fearing many "ifs" he may overestimate the task or, even worse, underestimate. But if we recall the "skeleton" of the task, we can at least approximately understand how much effort , blood, sweat and pain this task will cost.

The number of standards may vary:

• New Ansible Role - 2 points
• Diagnose because of what the server fell - 0.5 points
• Roll out a new version of the product - 1 point (CI / CD is adjusted!)
• To explore a new product - from 2 to 5 points
• Well, and so on

Thus, a certain productivity is formed, a plank is set, which must then be increased. But the original problem “am I getting better” remains.

How to solve it?

Based on velocity

An additional advantage of the evaluation is the ability to measure results and compare with previous sprints. Here on this sprint was 10 points, I just came to the office, and my colleagues spent a lot of time to get me up to speed. Here we have already reached 15, a little, but 2 engineers were on vacation. Already 20 points, cool, but this is a basic level. From thorns to the stars, you can move to infinity. Velocity is one of the basic metrics for measuring the potential of a team, but if you take it as a single objective criterion, then Scrum Master / PO, expect that your colleagues will begin to evaluate tasks twice or three times as much. :)

The situation with the skeleton of the task - server delivery is different. When the task “weighs” 1 point, we understand that you need to create a server in vmware with your hands, put an OS from a template, set an ipshnik with your hands, install NRPE and configure Veeam to backup this machine - and what if everything is automated? Here we have the configuration of the machine in Terraform, the CI striggers the build, the server will be added to the desired group in the dynamic inventory based on the tag, the other build will be cleared VIC and the role with the agent for Nagios will run, and the script will run to add the server to the backup schedule. Does this mean that task effort is reduced? Of course.

In this case, task templates need to be revised, and this may adversely affect performance in the end. And here another criterion appears.

Deliverables

It is important not only the amount of consumed story points, but also the practical benefits of the labor produced. It is measured in a very abstract way - in our case, it’s generally at the stakeholder's smile size, but it’s much better to say “Our team for this sprint migrated all servers to the new domain, the old one can be annihilated” than “Our team for this sprint closed 50 tasks points. " 50 points, wow cool, what have you done?

But again, let's make it a rule that more deliverables - the team works better, what can go wrong?

Here is another case - preparation for Christmas. For our ecommerce platform, this is a special time, and all-all-all developers, engineers and analysts give up all new features and get ready to answer the following questions:

• Will the front-end be able to handle 1 million requests per minute?
• Can the mailer handle 1 million emails per day?
• Will the platform handle more than 9000 orders per hour?
• What about WMS?
• Can the net handle it?

Later we will report on how we have strengthened our infrastructure with crutches , but this cannot be taken as deliverables - next year this question will become again and the wheel of the Samsara will give another turn.

Is the team considered to be working poorly? Not.

So how do you know if I'm getting better or not?

Job.

I went around all our Agile Coachs, hoping to get a special standard answer to this question. The answer was received - there is no special standard answer. But there was one good guess, and her name is Work.

Under the work refers to the amount of time spent on one deliverable. The time is calculated empirically from the story points - at the output you can get the ratio of the result to the effort expended.

As a result, I, both as an engineer and a team member, understand that if I delivered 4 deliverables for 20 points, then the average temperature in the hospital is 5 points for one deliverable. In the next sprint will be 10 to 30, and then - 15 to 40.

In this way, I will understand whether my team has become faster, smarter , taller, stronger , more efficient, and if I, as an engineer, have become stronger than yesterday’s.