Karma Driven Development (KDD)

As a preface

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

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

In order to cultivate a sense of responsibility you need:

• Voluntary acceptance of responsibility. For example, when a person himself calls the deadline for the task, he takes responsibility. And if the term is put down from above, there is no question of accepting responsibility; it is about who released the term;
• Freedom of choice - people have the right to decide what work to take, to choose a strategy for solving the problem, with whom to work (determine the composition of the teams);
• Consequences (positive and negative) of decisions made, actions and inactions. For example, I passed the high-quality performed functionality on time, received recognition from my colleagues and, possibly, additional cash rewards. Or, made a bug in the product environment, get a scolding and reprimand from colleagues.

The result was an interesting methodology in which each employee (including directors) has an individual publicly available rating / karma, which is accumulated with timely and high-quality implementation of agreements (more on this later) and “merged” when risks arise that are spelled out in agreements.
')
The agreement is a contract between the performer and the customer. Consists of completion criteria and risks. It has the value of the glasses of karma, as well as the cost of each individual risk.

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

Thus, employees have almost complete freedom - the choice of the way to solve the tasks set, 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 practically everything that Anton was talking about in the first part of his speech was repeated here 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 did not succeed.

Half a year has passed, Agile magic has not descended on us. The quality has not increased, the speed has remained almost the same, as before, constant monitoring was required. But there was talk about the introduction of KPI in IT. It was here that it dawned on me that karma is the only sane KPI that can really 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 presentation was made of the methodology for the entire development team. I must say at once that about half of the group initially reacted skeptically to this idea. Some of them, after a while, nevertheless realized what the charm was and joined the supporters. The rest were already involved in the implementation phase (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 next, it should be understood as an initiative group for implementing 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 any questions or spend too much time on it?
• 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 implementation of high-quality agreements (see below).
Reduction occurs at the occurrence of risks prescribed in the agreements, as well as at low load during the month.
To simplify the calculations, we equated 1 karma to the cost of 1 man-day. Thus, each employee will receive a plan equal to the number of working days minus vacation and sick leave. At the same time, less than 80% of the plan can be considered a low load.

Karma has 2 indicators:

• The indicator of the month - in case of exceeding the plan, can be used to calculate the increasing coefficient of the premium part of the RFP;
• Accumulative indicator - shows how generally the 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 recycles. Rested developer is much more effective than tired.

Agreement

Agreement on the solution of the problem between the customer and the performer. Consists of completion criteria and risks. It has the value of the glasses of karma, as well as the cost of each individual risk.
Customers can be any employees with the appropriate competence.
The executor can be either an individual employee or a team. If the team deals with the agreement, then the agreement cost is distributed to all team members in proportion to the participation (%) in solving the problem.
Commands are not fixed. People independently determine with whom to cooperate for the implementation of an agreement.
The contractor himself assesses and negotiates the cost and timing of implementation with the customer.

We have been struggling for a very long time over the question “How does the price of an agreement arise in the AlternativaPlatform?”. Whatever one may say, the imputed price can appear only if you carry out the analysis of the task and estimate the methods of implementation, and this requires a huge amount of time. I personally was not ready for such a load, this problem reduced all the advantages of the methodology to nothing. After some time, enlightenment descended ... And what if we apply a commercial approach. The performer himself voiced the cost of work and completion dates. It will be enough for me to evaluate the agreement at a very high level, and if it seems to me that too high a price or a term has been named, I will simply ask for an “estimate”. On this and stopped.

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



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

The customer comes and asks to shoot his leg.
You can of course do it right away, sort of like we even did great work and did exactly what we were asked about. Only then the customer will come again, but with the problem "Shot through the leg hurts, do something." We will smear ointments and sculpt adhesive tape.
And you can ask the question "What are you asking for in order for what?" And then it turns out that the person's leg just scratches.
We: "Let's just scratch our leg"
Customer: "And what, is it also possible?"
(I do not know who the author of this story is, I heard it from Askhat from ScrumTrek. Here is a brief retelling in my interpretation)

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

• completion criteria are formed - positive usage scenarios approved by the customer;
• Risks are evaluated - negative scenarios.

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

In order to take a task for implementation from the queue, the employees themselves carry out a technical assessment, determine how long and with what composition the task can be performed, as well as voice the desired price in karma. The result is a signed performance agreement.

It was very interesting with quality control. Initially, this stage was planned to be the same as in the AlternativaPlatform, i.e. all tasks need to be dragged through the necessary quality centers depending on the task (quality of the design of the database structure, quality of the code, UI / UX, etc.). If the task does not pass through the quality center, the team gets a minus in karma. Type nothing bad work to do. So, there were heated discussions on this topic, it is almost impossible to formulate development quality standards in such a way that they suit everyone, there are a lot of tastes, especially in terms of code quality. Plus there are times when the code, although there is something to correct in it, seems to be not so bad as to be fined for it.

As a result, the mandatory quality centers were reassigned to the centers of competence (hereinafter the CC), where any employee can turn to the task of review. Thus, an appeal to the Central Committee became optional. In addition, 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. Just gave the review task - you already get the bonus. Skeptics immediately dropped out, mumbling about the fact that all this is not necessary. On the contrary, they were the first to begin submitting 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 performer receives another 10% of the cost of the task.

What good have you received from the introduction?

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

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

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