Karma Driven Development (KDD)

As a preface

It all began in February 2014 with an invitation to attend the AgileDays2014 conference. In the evening of the same day I sat on the conference website to highlight topics of interest to me and plan a visit to the reports. After 5-10 minutes, I already watched the recording of the performance with AgileDays 2013 “Freedom and Responsibility” by Anton Volkov from Alternativa Platform.

The main issues highlighted in the report is that many employees simply spend time at work, few have a sense of responsibility. Moreover, there is no team responsibility, but there are excuses, many excuses. Here there are problems with efficiency, quality, constant monitoring of employees is required. Everything suits everyone, there is no desire to change.

In order to nurture a sense of responsibility you need:

• Voluntary acceptance of responsibility. For example, when a person himself calls the deadline for completing a task, he accepts responsibility. And if the term is lowered from above, there is no question of accepting responsibility, it is on the one who lowered the term;
• Freedom of choice - people have the right to decide what kind of work to take, choose a strategy for solving the problem, with whom to work (determine the composition of teams);
• The consequences (positive and negative) of the decisions made, actions and inaction. For example, I handed over a well-executed functional on time, received the recognition of colleagues and, possibly, an additional monetary reward. Or, admitted a bug in the grocery environment, get scolding and censure from colleagues.

The result was an interesting methodology in which each employee (including directors) has an individual public rating / karma that accrues when the agreements are executed in a timely and high-quality manner (more on that below) and merges when the risks described in the agreements arise.

An agreement is an agreement between the contractor and the customer. Consists of completion criteria and risks. Has value in karma points, as well as the value of each individual risk.

There is a single list of agreements in order of priority. When a team takes something to work, it itself determines its composition (the freedom of choice with whom to work is realized) and the period of implementation. The composition of teams dynamically changes from agreement to agreement, depending on the necessary competencies to achieve the goal of the agreement.

Thus, employees have almost complete freedom - the choice of how to solve the tasks, the choice with whom to work (team composition), what tasks to take, etc.

To karma

At that time, the company where I work was actively introducing flexible methodologies. It is funny that almost everything that Anton spoke about in the first part of his speech was repeated with slight differences. Even the ScrumTrek team visited us (Askhat, hello! Do you miss us?). I can only say that my attempts to "sell" the ideas I liked were unsuccessful.

Half a year passed, the magic of Agile did not descend on us. The quality did not increase, the speed remained almost the same, as before, constant monitoring was required. But there was talk of introducing KPI in IT. Here it dawned on me that karma is the only sane KPI that can actually be used in IT. This thought was voiced by the leadership, but I was not heard. In the end, the global topic with KPI in IT was hushed up, but I decided to continue the topic with karma at least in the sphere of my influence. If someone is interested in the scale, then these are 17 people involved in the development process - developers, project managers and analysts.

The introduction of karma

A methodology presentation was made for the entire development team. I must say right away that about half of the group was initially skeptical of this idea. Some of them after some time still realized what a delight and joined the supporters. The rest got involved already at the implementation stage (and where should they go from the submarine?). Those who accepted the idea immediately formed an initiative group and the work began to boil. Everywhere, where the word WE will appear further, it should be understood as an initiative group for the implementation of KDD.

When we began to dive into the details of the methodology, questions immediately began to appear:

• How to determine the cost of the agreement so that no one has questions and does not spend too much time on this?
• How to adapt our workflow to the methodology?
• What are the principles for prioritizing tasks among several projects?

I bring to your attention the final version of the adapted methodology.

Karma

Individual rating / reputation of each person.
Accumulation occurs through the high-quality implementation of agreements (see below).
The decrease occurs when the risks specified in the agreements arise, as well as when the load is low for a month.
To simplify the calculations, we equated 1 karma to the cost of 1 person-day. Thus, each employee has a plan equal to the number of working days minus vacation and sick leave. At the same time, low load can be considered less than 80% of the plan.

Karma has 2 indicators:

• Month indicator - in case of exceeding the plan, it can be used to calculate the increasing coefficient of the bonus part of the salary;
• Accumulative indicator - shows how generally a person is useful for the company. Here a monthly delta accumulates between the plan and the fact. At the same time, we make sure that no one processes it. A rested developer is much more effective than a tired one.

Agreement

An agreement on solving a problem between a customer and an executor. Consists of completion criteria and risks. Has value in karma points, as well as the value of each individual risk.
Customers can be any employee with the appropriate competence.
The executor can be either an individual employee or a team. If the team deals with the agreement, then the cost of the agreement is distributed to all team members in proportion to participation (%) in solving the problem.
Teams are not fixed. People independently determine with whom to cooperate in order to fulfill one or another agreement.
The contractor himself evaluates and agrees on the cost and terms of implementation with the customer.

We fought for a very long time on the question “How is the price of an agreement born in AlternativaPlatform?” Say what you like, a sane price can appear only if you analyze the problem and figure out how to implement it, and this takes a huge amount of time. I personally was not ready for such a load, this problem nullified all the advantages of the methodology. After some time, insight descended ... But what if we apply a commercial approach. The contractor himself announces the cost of work and deadlines. It will be enough for me to evaluate the agreement at a very high level, and if it seems to me that the price or deadline is too high, I will simply ask for an estimate. On this and stopped.

As a basis, Kanban is used with the following statuses and status transitions:



Before moving a task to the queue for analysis or implementation, almost every request from a business is tested by the universal question “What do you ask for in order for what ?”. The thing is that a business usually comes to IT with a turnkey solution and almost never designates a goal. In order to fully satisfy the needs of the business, we need exactly a goal. We call this step an express analysis — the result of the step is the formulated goal and the decision “we take it into work or reject it”.

The customer comes and asks to shoot his leg.
You can of course do it right away, sort of like we did great job and did exactly what we were asked. Only then the customer will come again, though with the problem "Shot foot hurts, do something." We will smear with ointments and sculpt a band-aid.
And you can ask the question “What do you ask for in order to what?” And then it turns out that a person’s leg itches.
We: “Let us just scratch our foot”
Customer: “Can you also do this?”
(I don’t know who the author of this story is, I heard it from Askhat from ScrumTrek. Here is a brief retelling of my interpretation)

As you can see from the diagram, we can have up to 2 agreements for a task, separately for analysis and separately for implementation. Made for decomposition purposes, improves the accuracy of the assessment.
In addition, a dedicated analysis step is needed so that an unambiguous understanding of the problem appears. For this:

• completion criteria are formed - positive use cases approved by the customer;
• risks are assessed - negative scenarios.

A direct transition to the implementation queue, bypassing analysis, is possible for small tasks, where you just need to take and do, there is nothing to analyze.

To take the task for implementation out of the queue, the employees themselves conduct a technical assessment, determine how much time and by what composition the task can be completed, as well as voice the desired price in karma. The result is a signed work execution agreement.

It turned out very interesting with quality control. Initially, this stage was planned the same as in AlternativaPlatform, i.e. all tasks must be dragged through the necessary quality centers depending on the task (the quality of designing the database structure, the quality of the code, UI / UX, etc.). If the task does not pass through the quality center, then the team receives a minus in karma. Like there is nothing to do poorly. So, there were heated discussions on this topic, it is almost impossible to formulate development quality standards so that they suit everyone, there is a lot of taste, especially in matters of code quality. Plus, there are times when the code, although it has something to fix, seems to be not so bad as to be fined.

As a result, the mandatory quality centers were reassigned to competence centers (hereinafter the Central Committee), where any employee can apply for a review. Thus, an appeal to the Central Committee became optional. In addition, in order to stimulate appeals to the Central Committee, we proposed the following:

• For a simple desire to get feedback on the work done, the performer (person or team) receives an additional 10% of the cost of the task. I just gave the task to the review - you are already receiving the bonus. Skeptics immediately muttered out, muttering about the fact that all this is not necessary. On the contrary, they were the first to turn in tasks for review to the Central Committee;
• If the Central Committee had nothing to recommend (the work was done perfectly) or if changes were made in accordance with the recommendations, then the contractor receives another 10% of the cost of the task.

What good have you gained from the implementation?

At the time of publication, we have been working on KDD for about a month. While we work only in plus and accumulate statistics, i.e. Cons for risks have not yet been launched.

• Perhaps this is self-deception, but it seems to me that the work began to be done faster and better simply due to the presence of a digitized performance indicator and reviews of the Central Committee;
• The activity is absolutely transparent - now I am much better guided by what subordinates do, without having to go down to micro-management;
• The psychological climate has become better due to the independent choice of whom to work with;
• The effect of personnel sanitation - unnecessary people are identified that no one wants to work with;
• No need to kick anyone, people themselves come and ask for an agreement;
• Standups have become really fast and efficient. Previously, in a team of 7 people, a standup could take 30-40 minutes, now 17 people fit in 15 minutes!

I want to note that the interim results coincide quite strongly with what was voiced in the report of Anton Volkov. For me, this is an indicator that the methodology really works.