P2P salary review

How and why I have implemented a Peer-2-Peer salary review in a corporation: a case study.

Goal: optimize for fairness

A CEO raised his company's minimum wage to £45,000 a year, and some employees quit because of it [link]. Do you know why? Because the hard working, highly educated staff were pissed off that someone who slacks off all the time and had not invested much in their own development, earns the same money.

An interesting thing about salaries and having people happy, is that the absolute amounts are much less important than the relative fairness of the system. And that’s a bit counter-intuitive.

Imagine this: when hard times come, we have a war or an economic crisis, most people are fine with having to cope with those difficulties, when they know it’s a shared burden. On the other hand, they get angry very fast, when they see stupid, incompetent, corrupt people driving fancy cars and living in luxury villas.

Fairness is the most important aspect of a salary system. Fairness is what we should optimize for.

Bear in mind that your company is a part of a bigger system (the industry). Which means that no matter how fair you are, you cannot pay shit to your people. You have to be fair and competitive. Otherwise, the fairness of the larger system, also known as “getting a better job”, will bite your ass.

Embrace your ignorance

It’s quite easy to evaluate the people you work with, when you have a team of up to 5 +/- 2. However, beyond the number of seven, you can only have a dim idea of how people are doing. One level deeper (49) and you have no chance at all.

When I became the Head of a 12 people branch, which I’ve grown to around 50, it’s been clear right from the start that I don’t want to be the person to evaluate everyone.
It would be unfair, logically invalid, and still take way too much of my time.

What other options did I have?

People are split into small, self-organized, interdisciplinary teams. You could give the power to evaluate people to one of the special roles, like a Team Leader, or a Product Owner, or a Scrum Master. However, both Scrum Master and Product Owner do not have enough technical knowledge to evaluate developers properly, they are biased towards soft-skills which is just half of the picture. The Team Leader is biased in the opposite direction. And going with either would still leave me with having to evaluate those “special” roles myself.

But the biggest problem is, that once you put the power of deciding about your money in the hands of another person, you will not treat the person the same way anymore. So my self-organized, coherent teams would gravitate towards a “Project Manager with his minions”.

That’s the old way of centralized, report & control, zero-trust, competition over cooperation, UK management style.

 “I’ve also noticed that different countries and cultures place different values on control. Some (e.g. the UK) value control and the restraint that it brings whereas others (e.g. Scandinavia) value empowerment and motivation.” [Software Architecture for Developers; Simon Brown; Leanpub 2014]

I don’t like that. It’s very ineffective.

Client, market, and stakeholders

If not a Product Owner, not a Scrum Master, and definitely not a manager, who can do the evaluation? Who can verify whether people work hard, efficiently, whether they are competent and valuable?

Theoretically, our clients or the market could tell us that. We could analyze, whether people do bring us money, or bring us closer to our target. This however, can only work if the team can decide on what they work on, which business opportunities they are after. And even then, it would probably be unfair. You don’t want to punish people for taking risk, and failing. In this line of work, you want them to feel safe to innovate, fail and learn from it. At least as long as they do not put you out of the business.

If they wanted to risk the evaluation of the market, they would start their own companies.

I work in a corporation. Decisions about the products we work on are done at the Executive Committee level. Evaluating my developers based on whether ExCo ideas are profitable would be very unfair.

P2P

That leaves us with only one option really. Peer-to-peer evaluation. We have a system, where everybody has some data and a bias, nobody has the full picture. Let’s get all the data together, and do some data mining on it!

Our constraints:

• For an employee, the whole process can take up to 30min, but should stay below 15 most of the time. And that’s for evaluating ALL the employees. Otherwise, the cost is huge, since every single employee has to do it (and it’s boring).
• On the manager side, gathering and analyzing all the data should not take longer than a day.
• The system should not be hacked (and we do have some pretty smartass hackers in here), or should be hacked in a positive way
• It would be cool if the system brought us more than just the money levels. It would be cool if the system told each of our guys, what they should do, in order to get more money next time. And that needs to be as specific as possible.

Impact

Cool, we have constraints. Now what do we actually evaluate to be fair?

Hard work? This is not a treadmill. I don’t want my people to work hard. This is a software house. It’s creative work. I want them to work smart!

Results? What results? Results of a company. i.e.: money, brings us back to market evaluation, which is wrong. Results of the tasks taken by an individual, brings us back to hard work evaluation, I don’t want that. Perhaps dedication? That would make all the dedicated idiots very rich, but not help us much, so maybe that’s not the way?

How about evaluating IMPACT a given individual has on the company? Would that make sense? If we review the impact, and connect it with the money, the system should be fair.

You work hard every day to move us further? You learn at home as well, because you are passionate? And you code works in production? Perfect. Money for you, good sir!

You jerk off all day, but have brilliant ideas in the evening, that you implement in the morning, that solve a lot of problems for everyone and bring us closer to where we want to be? Why not, jerk off again, it’s fine with me. Just use the bathroom, please. And here, wipe your dick with those euros.

You are a genius, ego the size of a planet, you read all the books, you could move mountains with your infinite knowledge and expertise, you have a PhD on Agile Node.js Extreme Reactive microESB, but somehow you cannot really work with people and thus none of your solutions get into production? And you antagonize teams? People don’t want to work with you? Sorry, that’s no impact or even negative impact. No monies here.

Right, but measuring real impact is hard. And even more, could be unfair. This is a team sport, so your best people could get screwed by show stoppers, other poor people, business changes... you know, shit happens. Real impact, like the market evaluation, will feel unfair, when your best people get trashed by things they have no control of.

The problem here is also the solution. You should measure the potential impact (without show stoppers), and verify it against the real history (because your perception of potential feedback may be wrong), to find out, and work out, why the potential is not used in practice.

Skillsets

How does one evaluate potential impact of others? In software development potential impact is based on someone’s skills. The better the skills, the more potential impact, though both are not equal (more on that later). So how do you measure skills in a timely and meaningful manner?

Fortunately, I’ve already solved that problem once. While hiring people in TouK company, by doing a full day pair-programming (a very good, though costly method), I came to the conclusion that to be able to make a salary recommendation, I want to to present new people by comparing them with existing ones, on 6 skill groups, which I find important in software development.

These groups are

• Hard Programming Skills (including: programming skills in relevant language, OOP/FP, frameworks, methods like XP, TDD, DDD etc.)
• Hard DevOps Skills (including: Linux administration, deployment/build pipelines, JVM/GC tuning, database tuning, etc.)
• Communication (How easy it is to communicate? Do you like cooperating with that person? Are you irritated by the guy? Does he/she read your mind?)
• Understanding (How fast can one understand new, complex stuff. How fast does one learn?)
• Self-sufficiency (Can one pretty much do anything about the software development, or does one need a lot of help and attention? Can I throw any problem at them and it will get resolved? This includes domain knowledge, broad set of skills, goal orientation, self-retrospection and adaptability.)
• Focus & Motivation (Some people can move mountains with their sheer will. They are self-driven and have intrinsic motivation. You just need to remove blockers and let them shine. Others are easily distracted, lack self-motivation or sense, constantly need pointing the direction, waste time on facebook, or in the worst case scenario, need a lot of control & reporting)

It may surprise you that hard skills take only ⅓ of the evaluation. But my experience suggests that most developers can handle rocket science mentally if you give them enough time. The problem is, that a large number of them will drop due to a lack of focus, some due to digging themselves up in just one branch, and not being able to handle the rest (self-sufficiency), for some I cannot afford the amount of “enough time” (understanding) and a large portion of the rest will never be able to communicate their knowledge properly.

So yeah, sorry, but software development is not only about programming. At least when you have to work in a team. Programming is crucial, but it’s not enough alone.

But this is cool, because if you skip those 2 hard skills, you can also use the same groups to evaluate Product Owners and Scrum Masters. That makes the whole process easier.

Round 1: Comparison

Human beings are bad at absolute values. We are good at comparison though. So my first iteration was to ask people to draw a line for each of the skillsets, and then start putting small stickers with people’s names, relatively to each other (bottom: worse, top: better). No absolute numbers whatsoever.

Since you do not work with everyone, you should only evaluate the people you feel you can. And only in the skillsets that you feel you can.

The outcome looks something like this.

Great, we have some data. Time to clean the noise.

Round 2: Explanation and refinement

After that, I would take every single person to a one-on-one, and ask them to explain their picture to me. We would talk about the bottom and top 20%. About all the issues they have with other people (usually communication). I would ask them how the person evaluated could improve their situation. I would gather feedback.

Then I would do normalization and clustering, to [-2..+2]. Like this:

Manual normalization and clustering of data took me a lot of time even at 20 people, so this part doesn’t scale.

For the second time, I decided to put absolute values: 0 to 4, and use google forms to gather feedback. I was afraid that without continuous scale, people would have a lot of trouble with comparison. Turned out, I didn’t need to worry. These is IT crowd, they understand clusterization perfectly. Discrete numbers are totally fine.

I have also added a “Note” textbox under each skillset, so that people could write down their thoughts on top/bottom 20% themselves the moment they make the decision.

The field “Who has similar skill...” is there to help people self-verify their feelings.

Still, I had a one-on-one meeting with everyone. A completely automated system could be easily hacked. A system where you have to explain yourself to a biological creature is much harder to break. And much more humane. So while my people did clusterization of data automatically, I did normalization and verification myself.

Round 3: Analyzing data

So what do we end up with? Lots of numbers.

Each column is a person. Each row describes level. Each cell represents number of votes for a given skill at a given level. The color is based on value, so you can easily spot high numbers.

A simple spreadsheet formula, and you have a number for each skillset for each person. You can even sum this up to a single number. A single number describing someone is very tempting. That represents how good the person is, right?

Not so fast.

While numbers are great, it’s the distribution that you should analyze. Why is this guy hated by everyone but 3 people (communication)? Who are those people? What is their work relation? Why are those 3 people also evaluated badly in this skillset? Why does the other guy have no estimates in Focus & Motivation? Is he acting? Is he passive-aggressive? How about this girl, so good at pretty much everything, except DevOps? Is she still running Windows at work?

I don’t know if it’s possible to automate this, but I wouldn’t even try. The distribution tells you stories. When you add additional verbal and written feedback, you get to understand the dynamics of your teams a bit better.

And you can always ask. If you want to dig deeper somewhere, you can. The beauty of this system is that you know where to dig. Understanding the situation plays a big role in normalization of the feedback.

Impact != P2P skill review

Skills are the base for potential feedback. But how about that girl over there, that never bitches about the work, never panics, even in a dire situation, with a job that nobody wants, but that needs to be done, you will just hear a soft sigh, and she’ll get it done. It’s helpful. It’s calming. Her stoic attitude, her gentle voice, and behaviour gets all the hectic boys through the hard times. There is a lot of extra value in it.

But it doesn’t get evaluated in a P2P skills review.

That’s because Impact and P2P skills review, are not equal.

To make it simple, my formula for Impact is

Impact = normalized peer-to-peer skill review + personal traits 

Traits

Traits are simple. Traits can be both negative and positive. Let me give you some examples, you will get it in a second:

• +Performance/Security expertise we need once a year very much
• +Public Relations (blogs/open source libs lure more good devs in)
• +Assertiveness (helps keep quality while negotiating with the client)
• -Submissiveness (can be dominated by the client, and fail due to that)
• +Iron Willpower (not braking mentally in any circumstances)
• -Low Willpower (panic!)

You should be able to identify those yourself. Like in a good role playing game, traits define a character. I know a lot of great developers, what makes them stand out, are their interests and traits.

Traits modify the outcome of skill clustering. They usualy give cumulative +1, -1 to the final cluster the person is in.

Applying salaries

Now back to the goal of optimizing salaries for fairness. We have clustered skills, modified by traits, that describe the potential impact a person has on the company. On the way, we have found a lot of interesting information about team dynamics, and we dug up all the not so obvious. After everything said and done, we have reduced the data to a single number (cluster). People in the same cluster have about the same impact. Time to apply money to this.

The problem in many corporations is that salaries are not public. At least not officialy. This is a very stupid leftover from the previous era, when an employeer wanted to pay as little as possible to his employees. But it makes no sense? Why would I, as an employeer, want to pay as little as possible? The goal of the employeer is to make as much money as possible, if I have to pay more, to get more, it makes perfect sense. So paying less to the people makes no sense. Finding the sweet spot, when the money that people make gives the highest benefit, that makes sense.

Some will argue, that money is not a motivator, after certain amount. True, that Notch (the author of minecraft) with all his billions of euros, doesn’t seem to care about another million. But Notch is not a standard employee, and people who say money is not a motivator, usually have a lot already. Looking at the market of developers though, most of them are also motivated with money. It’s not the only factor, but it’s important enough, to make them change their jobs, but the amount that would make them not care about money anymore, is never reached throughout their lifetimes. Anybody with kids can tell you that, whatever you think is enough, will probably be wrong.

So what can we do in a corporation, where we are not allowed to publish salaries?

While we cannot publish salaries, we can publish anchor points. Lots of job comparison sites (nofluffjobs.com for example) require a salary range. If you clustering ended up with 5 different clusters, you can probably come up with some names for those levels (junior/mid/senior developer, architect, senior architect, principal senior executive architect, etc.). Now all you need to do, is publish those job offers, with the money (either as a salary range or fixed), and people can compare their own situation to the whole picture.

Make a strong commitment, to always keep salaries together linked with job titles and linked with the potential impact. Promise to keep it fair for the people. And now, because titles are public, everybody knows what the salary of everyone else is.

More or less. More if you have only one number for a cluster, less if it’s a range. Still, people will be able to see the whole picture, and tell you if they think it’s fair.

To make the commitment strong, I had to fire someone, who had much more money that their position (he was a much better negotiator than an employee), and rise the salaries for all the bad negotiators. If negotiation skills are valuable to you, make them another skill group, or add them to Traits.

Benefits

There are good things and bad things about this system. First the good things.

I don’t have to be the judge. I don’t have to play an omnipotent being. It changes our cooperation a lot, the moment people realize, they don’t need to make a good impression on me. It makes them more open.

People don’t need to convince me, when they need more money. They have to convince their peers. This means we can have a honest discussion about what to improve, how to make their potential impact into the real one, or how to increase their skills. Or the perception of their skills in other people. When someone thinks he has much higher skills than other poeple think, it’s usually about the problem with communication. Or ego. It’s something you can work on. Though egos are hard to fix. But even then, you have hard data.

If it's a problem with communication, it's no more "my boss doesn't like me". Now it's "have a look, all your peers say you are bad at communication". You cannot ignore all the people. You even cannot get angry at all the people. You finally have to understand that the problem is on your side.

It takes 15 min per developer, and 1 day per manager. On average, because it varies with how much digging up you have to do.

After investigation it gives you tons of feedback, which you can give back to people. And people want that feedback. I’ve been doing it every half a year, because we had a salary review in corpo in summer, and then a bonus review in the winter. People asked me to do it more often, even knowing that I won’t change anything about the money, because they wanted to get the feedback. More feedback is better.

And it can be used for Devs, POs, SMs, QAs, System Engineers… Basically everyone who has peers.

Caveats

Beware, there are some obvious downsides.

Peer-to-peer review doesn’t work for people, who work alone. It also doesn’t work well if your teams never mix, and stay in the same setup for years. You will soon find out, that people can review only their team members. But if you have a medium sized company, and people do not cooperate too much between teams, do not share their knowledge, perhaps you have a completely different problem to solve?

It’s tempting to dehumanize (turn people into numbers) fast. Don’t do that. Let the distribution tell you stories, and dig into it. Otherwise, your system will be unfair, and unfair systems get hacked much faster. Social justice, I guess.

You cannot compare salaries between different roles (QA/dev/PO) due to different market levels. This doesn’t sound bad, but since you have promised to be fair, what happens if someone changes his position from a better paid role to less paid? Scrum Master to PO, for example? Small problem if the person can still do their old duties (potential impact is still high), but if they can’t?

Or how about someone who learns nothing for a few years? In a fast changing world of software development, skills deteriorate fast. Since the salary can never get lower, and the majority of people who still work on their skills will rise the new base (average), the same salary for years may become more and more unfair.

Sometimes, due to fairness of the system, you will have to fire someone, who otherwise does his/her job.

It’s also hard to explain to non IT people (CEO, HR) that someone can make an improvement of +40% in a year. They may not like to give such a salary rise. But it happens in IT. Well, at least you now have some hard data on it.

Another mistake I made, was giving not enough anchor points. I've published two salary ranges (mid and senior), because it was very difficult to get my corpo to agree on anything oficially. At that time, I had 5 clusters from P2P review. Some people who just got promoted or hired to senior level, expected to get the top range of this position, while the truth was, 70% of seniors were at the beginning of this salary range. My clusters and published anchor points were not one-to-one, and that was confusing to people. Fortunately, people trusted me enough for this to not be a problem. I just had to do some explaining.

But all of that is nothing, compared to the biggest benefit of P2P salary reviews.

And the biggest benefit is: I had this system running for two years and people liked it.

At least that was the overwhelming feedback that I got. And that makes me happy.

Animating Developers, 4 months later

Four months ago I had a chance to present Agile Skills Project and experiments we do at TouK, to create a learning ecosystem and culture of constant improvement. Time to report progress of our experiments.

Map of New Ideas

The request came from our HQ (Headquarters, which is our group of main company owners): lets use Jira to gather ideas and initiatives about how to improve our company. You know, Keizen style.

The reasoning is, that though some people, including myself, always loudly present their opinions, new concepts, and basically try to change the company from the ground up (whether the stakeholders like it or not), others need some encouragement and a safe way to suggest ideas for improvement.

Our map of new ideas is a simple Jira project, where anybody can suggest anything he/she thinks is worthwhile. The new idea is verified by a group responsible for deciding whether it's in line with company's profile and possible with our current resources. If so, the idea and needed resources, are assigned to someone who, from now on, is responsible for making it happen. It doesn't have to be the person proposing the idea, but quite often it is. The ideas are also grouped by the area they correspond to, one from culture, evolution, fitness, relations, survival or contribution.

As for the moment, our statistics look as follow:

• Proposed: 36
• Selected: 6 (waiting for a victim)
• Assigned: 8 (but not started yet)
• Ongoing: 6
• Refused: 1
• Finished: 26

Things that appear on the map vary, including for example other experiments described here (Weekly Workshops, OCRs), open sourcing some libraries, drawing diagrams of all the systems we create for our main clients (very useful for new developers) or creating database environment for regression tests on Oracle.

As you see, it goes quite well, and I believe it's a great way to get your developers involved in the company improvement. As a side effect, people feel they have more influence over where the company is heading, which is always good and gives a nice motivational kick (“Hey look, now I'm not only building software, I'm building my company as well!”).

Thing to remember: this is a map for company-wide ideas. In the beginning there was a confusion over whether stuff about how to improve one's project/team should be here, but since our teams are self-organized, there is no need to involve the rest of our company. The power is in one's hands anyway.


Weekly Workshops

Every Friday at 4pm, we have a one hour long technology workshop open to everyone. It usually takes the form of a lecture, with slides, some coding, and examples, but the form is open. Other features are not, and that is very important for it's success.

This is a concept I've borrowed from Supermedia Interactive, when Piotr Szarwas was still the head of the development department and my boss. I'm sure it's popular in many companies, but Piotr taught me how to do it correctly.

The goal is to share knowledge and learn new things.

The date and time are set in stone. Every Friday, 4pm. It's during our work hours, so we had to choose time, which won't stop or slow down our normal development. Since our sprints are week long, Friday 4pm is usually after the retrospective anyway. Let's face it: at 4pm on Friday, we are either busy putting down some fires, learning, or slacking off anyway.

Everyone can present anything, as long as there are people who want to listen to. We keep a calendar on confluence for coordination. We also have a page with suggested topics, where people put things they would like to listen about, for others to pick up and investigate. One rule is very important thought: if we do not have a volunteer for next Friday, we are going to pick one.

Yes, the participation (as a lecturer) is mandatory for everyone. It basically means, each developer should give at least one lecture per year. No excuses.

At first, there was some turmoil about that. People do not like to be forced to do anything. But the first drawing showed that it's a good idea. Randomly chosen people were giving great presentations. The reason is, that everyone has something interesting to show, it's just that a carrot of general appreciation is not enough sometimes. Sometimes you also need a stick. That's how a human mind works.

So what are our workshops about? Here are a few topic examples:

• Clojure – lisp for java programmers.
• Rapid Application  Development using Grails and Vaadin
• Smartclient: RAD even faster.
• Apache Hadoop and projects around it.
• JBoss Envers – easy entity auditing
• How to get users from Gmail and Facebook: OAuth 2.0, OpenId, Spring Security and Spring Social in web applications

Weekly OCRs

I've already described that  in here so I'm not going to repeat myself. What has changed, is that we have it on a weekly basis, we have it split in two: java and database OCRs separately, and that we have designated people responsible for making it happen (not for leading the meeting, but for choosing a victim, if there is no volunteer).

Java OCRs are held on Friday at 3pm, for all the same reasons as given above for workshops.

I've noticed that some people see it as a chance to brainstorm and refactor some really troublesome code, they work with, which they normally do not want or have no time to touch. That is a great idea, and since we use our own code for OCRs, and since we actually try to commit the changes, it's more like getting help for your project, than only sharing some thoughts.

Database teams do it in a little different way, but not being there, I'm not inclined to explain it.


Quest system during work hours

The quest ecosystem described on Agile Skills Project web site, about which I've been talking on Agile Warsaw is a great self-motivational tool, but the question we had, was how a company can help people get it started? My idea was, that having everyone choose his own mentor and booking an hour a month to talk with him about the progress or lack thereof, can do the trick. But that assumes, people are working back home to meet their goals, which is not true for everyone. Witek Wolejszo wanted to check whether making it a work-time activity will spread the technique to those, who don't want to use their free time.

Eight people with different background and free time activity were chosen for a month long experiment, where they would choose an educational goal and try to achieve it within working hours.

The feedback was generally negative. People complained for these main obstacles:

low quest priority (everything for the client is more important) ends with process starvation
quests as defined were things to be done alone, and we prefer working with other people (pairs)
no motivation from quest done for yourself only, when it doesn't have an immediate use and no one else is waiting for the outcomes

At the same time people didn't think it was a totally bad idea, but would rather like, if quests were somehow corresponding to our current products and projects and had defined timeboxes.

This made us close the experiment and start with two others, described below. We do not know yet how these will work out.


Task exchange board.

When creating a backlog for a project, there are usually some tasks for which the domain knowledge available to team members is not needed. This include investigation into new libraries and technologies (spikes), setting up things very technology oriented (auditing by Jboss Envers, excel export via  Apache POI, etc.), creating black-box and/or open source libraries, writing proof of concepts or collecting and releasing some tools from the project as an Open Source libraries. All those tasks are candidates for Task Exchange Board.

When a backlog is done, the team can decide which tasks to put onto the board. These should be estimated like on a sprint planning, should have a defined time expectation or a timebox (in case of spikes) and Definition of Done.

Once on the Board, anyone in the company, even from different project or department, as long as he has enough time (i.e. his PM/team leader has nothing against it), can pick up an interesting task and do it using the budget of the team which created the task.

This way, people can do something important and interesting in a new technology, on full time, without changing the current project. If you have enough of what you are doing, this may be a productive brake for you. If you are currently only supporting some existing project or waiting for bug reports, why not to do something interesting and learn something new on the way? This may be a equivalent  of a quest for those, who do not have any time at home.

These tasks, may also be done by members of the team which created them.

One important thing has to be understood: since the team creating the task doesn't know who is going to take it, it's up to the guy taking the task, to finish within or before estimated time. Basically, if you are not sure you can finish this on time, or do not want to risk spending your free hours on it, don't take it. This should not slow down the development time. If it did, no team would put another task on the board.


What technologies you want to work with?

This time-fridge contains
technologies we do not use anymore.
ZX-Spectrum, Commodore 64,
Commodore 128; Amstrad,
Macbook Air...
Old kind of stuff.
We are an old company :)

We have a team of guys responsible for assigning people to new projects or moving them between existing. This team has a sky level view on what's currently going on in the whole company, all new and planned projects.

So far, the team was making up decisions based on their own perspective of what one is capable of. We wanted to change it a bit, to make TouK a better place for people who feel a rush on some technology, so we created a confluence page, where everyone can submit what technologies he would like to work with.

Now, this looks very simple, but frankly speaking, I wasn't aware (and I believe nobody else was) of how often some of technologies would be mentioned by different people. As an effect, we can see now, that we have a lot of developers wanting to take part in a full-Grails, Java free project. While in theory, every team can decide for itself, what technologies it uses, seldom someone would take such a drastic, risky step, as changing the language for the whole project. By gathering information about what people would like to work with, we can create a team very dedicated and motivated to use some technology. That may pay off pretty well.

We shall see, whether the guys assigning people to projects, will take that into account.

More to go
There is a lot of stuff, we haven't tried yet. This includes for example mentoring, RPG character cards, exchanging knowledge with other companies by switching developers for a few days. Hopefully, I'll have more to report in a few months.

Video from my presentation at Agile Warsaw

Here's the video from my presentation and the discussion about Agile Skills Project and our experiments in motivating developers at my company, that I had a chance to show at Agile Warsaw.

Do not ask my why the camera is 100% time focused on the wall, I have no freaking idea :) The voices are there, and that matters.

You can either watch it on Parleys: http://parleys.com/d/2019 or right here. Be warned: it's in Polish.

Agile Skills Project at my company

Unfulfilled programmers

Erich Fromm, a famous humanist, philosopher and psychologist strongly believed that people are basically good. If he was right, then either our society is a mind-breaking dystopia or we have a great misfortune of working in a field that burns people out, because many IT people I know are more like Al Bundy than anyone else.

Why is being a couch potato something wrong? Happiness can be achieved in many different ways, but not by passive pleasures. One way of pursuing happiness is by self realization and while self realization can happen in any activity, it's makes perfect sense to have it at work, where you spend one third of your life time anyway.

But many developers I know, consider work as something boring at best, dreadful at worst. True, programming can be awful, when you have to dig deep into a terrible code base without any perspective for a change, but IT is vast and you can always find something interesting, and once you learn it, you will find a way to make money on it, either by changing position inside your company or changing your employer altogether.

Yet most unhappy IT professionals don't do anything to change their situation. The main reason for that is, because it requires a lot of learning, and learning at home is not the most beloved activity for a couch potato.

So why are developers turning into couch potatoes in the first place? Why the last thing a typical developer will do back home is learning and polishing his skills? There are plenty of reasons for that.

The three main roots of an IT couch potato

First, our work is tiresome. Nearly every job offer you can find mentions “able to work under pressure” and “flexible long working hours” in the requirements. This translates directly to the “burn-out” phenomenon.

Second, the technological landscape is changing overwhelming fast. Unless you work for a slowly adapting institution like a bank, your skills will be outdated in a few years time. Sure the deceased Sun, god help us, granted Java developers four years of relative stagnation, but that's an exception and it's going to end soon enough anyway (unless, of course, these are just convulsions before slow death of technology). You better learn and you better learn fast, or you'll have no other option than to promote yourself into management.

Third, just how long can you sit by your computer everyday? Yeah, I know, some people spend years playing WoW, Eve and alike, barely moving. I am a sinner myself, with Steam reporting over 350 hours in Modern Warfare 2, 200 hours in F.E.A.R. 2 multi, and countless months of my life wasted by Sid's Civilization. But for not-addicted, it's just simply stupid, not to mention unhealthy, to have your ass integrated with the chair. No matter how comfortable it may be. There is more to life than that.

Case Study at my company

It all started with a few SQL programmers grumbling about how they are bored to death, and how they would like to switch to OO programming. I'm not a person who waits, so next thing I did was asking our management if they could move those guys to Java/C# projects. And the management was all for it, with just one requirement: they would have to first learn our technology stack at home, not to be totally lost and unproductive. After all, the more technologies an employee know, the more valuable he is for the employer (think about switching people between projects).

A few months later and nothing has changed. I'm asking sql guys how the learning is going, and I get the answer: it hasn't started yet.

Now, I know the best way to learn something is by hands-on experience at work. After all that's why I've been changing my job a few times: to have a real world experience. It's easier to learn french if you move to Paris. And learning at home is hard because of the aforementioned reasons. The very same reasons, why you get only 650 people on a free conference, like Javarsovia.

So what can we do, then? How about we remove all the obstacles? How about we make learning at home fun, satisfying and profitable. How about we provide  motivation and feedback. How about we also solve the never-ending dissonance between employee's financial and employer's productivity expectations on the way. Sounds interesting? Let's try, then.

First: make it profitable.

Up to some point, people get motivated by money. It won't work if you are already earning enough to pay for everything you need, but in a country like Poland, to be able to build/buy yourself a house, you have to be making many times the average salary. So here, money is still a major motivator. Every year, every developer goes back to his boss and says: I want more.

Guess what, your boss wants to pay you more. No kidding. After all Henry Ford's said:

“There is one rule for industrialists and that is: make the best quality of goods possible at the lowest cost possible, paying the highest wages possible”.

Highest wages. You boss really wants to pay more. But to stay in business, the company needs you to either improve the quality or productivity. Both mean more money to the business, and more money to pay you with. If you consider that, the goal of a developer who wants to learn something new (or get better at something) is on the way to make the company more profitable. After all, this is software development – you never know what technology you gonna need tomorrow.

This works both for completely new stuff, and for learning something that company is already quite good at. If you know several technologies that the company is working with, you are more valuable, because you can handle more projects (you boss may think in terms of reallocating resources).

After thinking about all of this I went to my bosses and asked them: will you pay more to the people who learn different technologies at home? Even when they can't use them right now at work? Will you give a rise to those Oracle guys, if they learn Java?

The answer was: definitely! They actually said that every time a developer asks for a rise, they ask him back: what have you done in the last year to improve your market value? What have you learned? Because every time an employee's market value increases, the company's value increases.

Simply speaking: more skills means more money. Both for the developer and for the company. It's amazing, how often people forget about it. Making it crystal clear can give you a motivational boost to do something at home and a nice perspective. You don't have to switch your job to get a rise. You need to learn more, and they'll happily pay you more.

Second: make it easy

The main question with learning is where to start from? And for software developers it's the most important, most difficult question, because there is no way to learn everything, because spending years studying can be simply a waste of time, if the technology is dead/outdated the moment you get productive with it. What should I learn or why should I learn at all, if the risk of wasting the most precious thing in my life, my time, is so high? How do I decide what to learn.

Lets make learning safe and easy.

Your best bet is to start with something that has much longer life expectancy, something that will help you right away, no matter what a technology you have to work with in your next project. And something that is relatively simple to learn: agile skills.

These are skills of an agile developer, well established, well recognized, and not going away any time soon, because we still do not have anything on the horizon that could surpass them.

Yeah, I know, the world 'agile' is so popular nowadays, that even my grandma is agile, but lets go for a solid list of things agile. No bullshit theory, no marketing mumbo jumbo, give me a precise, distilled and refined list of things I should learn, things that will help me, things worth spending my time on.

Here it is:

The Agile Skills Project

The project is all about self improvement and learning. It's a great inventory of “ isolated, learned, practiced, and refined” agile skills, with definitions, resources, descriptions of steps to mastery and success stories. Take a look at the “Pair Programming” page, for example.

All the skills are divided into different areas: Business Value, Collaboration, Confidence, Product, Self Improvement, Supportive Culture, Technical Excellence. You even get a nice mind-map with it.

This is a single reference point for all those who do not know where to start or where to go next. All these skills are in high demand on the market and with a very long Time-To-Live. The best thing is though: no matter what technology you gonna work with tomorrow, you can benefit from them.

I took the list from the website, tidied it up a bit, refactored it for the needs of my company, and proposed it as a Request For Comment, a wiki page, where everyone gets to discuss and shape up the idea, before we give it to the management.

Soon we had a discussion. It wasn't easy to make everyone understand the concept, but after a while people joined in, and we added some more stuff.

Level up!

The Agile Skills Project is more than a simple index. It tries to create a learning ecosystem, by defining quests:

"Quests" are on-the-job experiments, self-assessments, peer-reviews, course experiences or other activities intended to help a person better apply a particular agile developer skill set.

It's a bit like a Role Playing Game. You have your quests, you do them, you get experience. For experience you get more money and new toys (technologies) to play with.  It's fun. Billions of MMORPG players cannot be wrong.

But to make that happen we need something every game has: feedback.

Third: give feedback

OK, so we have a bit of motivation (money) and a list of goals (agile skills). Who is going to give us quests, and who is going to tell us we did a good job? How will we have our feedback?

The first and most important thing, is to see the results of you actions. Otherwise you loose focus and motivation (money can only get you that far). Therefore you should create a list of quests you have done. Put it on the intranet or somewhere, where you can show it to others. It's important, because you are going to share it with your mentor.

Yes, a mentor. Choose someone from your company, someone you trust, someone you respect. It doesn't have to be an Einstein. Meet with this person once a month, during your work-time. An hour should do. Discuss with your mentor what quests you want to accomplish this month. Could be anything, reading an IT book, learning new programming language or taking another step to master one of the agile skills from the list. Tell your mentor when you'll be done. Meet together again next month, and either put the quest in your done-list, or mark it as 'failed'.

The role of the mentor is to listen to you, remove obstacles, help you choose a good path and give you feedback.

You'll be surprised by how much the meeting with your mentor motivates you. It works much better than money: you don't want to fail in the eyes of the mentor, because this is the guy you respect, and you want him to respect you as well. And once you see your constant improvement by filling the list of quests done with your mentor, it gets addictive.

Smells corporate?

How is this any different to what you can sometimes see in a corporation, with a year long plan of tasks your boss is giving you to accomplish to get your bonus?

Well, first of all, these will be your quests, chosen by you. Second, you will choose your mentor as well. Your boss usually doesn't know a thing about what you are doing. Third, it's all about your self-improvement, not meeting some company goals. You get better at something, the company gets better at something. After all a company is not much more than the people working at it.  Fourth, it's a fast feedback cycle, you do not have to wait till the end of the year to get it.

And finally, it may be a bit corporate, because I have never seen any small company doing anything like this. But even if it is, it still seems like worthwhile. Anything to get me out of the couch.

Discuss

It's a bit too early to tell whether the idea will be successful. We have just started. Fo me it is already helpfull, because with a list of quests done I have have a feeling of progress. If you'd like to discuss this, and other ways to animate software developers to do something more, I'm leading a meeting at Agile Warsaw group about it, on the 20th of September, 19:00. Feel invited.

By the way, here you have a trial of "other ways to animate" from our internal TouK Code Jam Party, we held a week ago. Doesn't look mych corporate, does it? 

Tomek's tray notes on Scrum

As Nigel Baker was giving his speach titled "10 tips that ScrumMasters should know, (but probably don't!)" at Winter Agile Tuning, Tomasz Przybysz was taking notes on a paper tray. I've heard the talk was pretty good and a few people were trying to copy his tray. Since the original presentation is not yet available, I thought I'll help with putting my own photo (phone quality) on-line.

Maybe Tomek will take a while to put some insight into his notes? What say you, Tomasz?

Click on the image to get the full (readable) size version.

Winter Agile Tuning Review

I've found Winter Agile Tuning conference purely by accident, reading someone's blog. I have to admit that I've never heard about it before event though it was a second edition already. As I had ma chance to talk with, Jakub Dziwisz, one of the organizers, I understood why. Jakub didn't think about it as a country wide conference, more like an way to animate local Agile society. Well Jakub, I've counted at least four people from Warsaw and quite a bunch of speakers from abroad, so I believe you'll do well with changing your target audience expectations for the next edition.

Having an Agile conference somewhere nearby (I consider Cracow nearby as it's 3h by train from Warsaw) in a suitable time, is a good enough reason to go. After  I'd checked the website I knew, I cannot let it pass by. The program was interesting, with some well known names (i.e. Szczepan Faber, guy who wrote Mockito, the best mocking library in Java world), it was practically free of charge (50zł) and it was starting at 2pm on Saturday.

2PM! Do you know what that means? It means that you do not have to get up at 5am to catch a train or at 4am to get there by car. You don't have to be totally exhausted, intoxicating yourself with gallons of energy drinks. You don't have to get there a day before, wasting a perfectly sweet Friday night. It means that you get up at 8am, like normal people, you have enough time to eat lunch, and after the conference it's exactly the right moment to go to an afterparty.

I wish all the conferences would start at at least at noon.

Back to the event. I went there with a friend of mine, Tomasz Przybysz, one of not so many programmers I've met, that actually cares about the quality of his work, and as there were two tracks and two of us, we've decided to split and exchange the knowledge during breaks.

I've chosen the 'Craft' track while Tomasz went for the 'People'. That was a pretty good choice of mine and I only wish I could be on '10 tips that ScrumMasters should know...' by Nigel Baker. But let's start from the beginning.

Sweetest acceptance tests

The first lecture was given by Bartosz Bankowski and Szczepan Faber. At the last moment, they've changed the topic of the presentation from an enigmatic 'Be a VIP and rid your WIP' to 'Sweetest acceptance tests'. Can't say I was disappointed.  They took us through an example of working with Sweetest which is a sort of a plugin to a wiki that allows for a very fluid and direct translation between a wiki-defined set of acceptance requirements and automatic (junit) acceptance tests.

How does it work exactly? It's quite simple: you talk with your client, you both write his requirements in a wiki, the tool creates junit automatic acceptance tests for you. Here's a demo.

It fits very well with a TDD/BDD approach and allows you to have a bit more contact with the client, as the client can see on the wiki what his own acceptance requirements are and which are already implemented.

Lately, we've spent two days creating acceptance test scenarios for my client in doc format, which could allow him to formally say 'yes'. We've been doing it by checking his requirements (again), checking whether we have implemented them right, and writing all down.  The thing is, that since we do TDD/BDD, we already have all the tests that tell me whether his requirements are met, because we start implementing a new feature by writing a test for it. The main failure of the situation was that we've been writing those scenarios AFTER the whole project was implemented. Had we had them written down BEFORE, maybe even had them connected to unit tests, we'd be done before we've started.

That's what Sweetest is for.

Not that it's something totally new. If you're doing TDD you are already implementing client's requirements as tests (or at least you should start every feature with a single test for it, and then go down the implementation and Red-Green-Refactor line up to the point when it's fully working and is fully covered), but everything that helps with communication, well.. helps. And as in my example, can save you a few days writing docs.

I've been to another conference in Cracow last year where Szczepan was presenting Mockito framework. Just like the last time, his presentation was vivid, fluent, interesting and straight to the point. That's what makes a happy Panda.

Let them speak in their own language

Next was Konrad Pawlus 'Let them speak in their own language. How we enabled domain experts to build acceptances tests - case study'. Konrad shared his experience with developing Test Driven software for financial market. The clue was to allow domain experts, guys used to Excel, to verify software in a way that was familiar to them.

To do that Konrad (or his team) created a Visual Basic tool, that could convert xls files with example calculation to a scripting language, and then fire up this scripting language in a similar manner to junit tests. At the end, domain expert could verify everything down to the last number (and knowing that Excel actually creates a lot of errors with rounding that is very important), create new tests to check scenarios they never thought about before.

This is quite a cool way to bring customer into testing and have a robust feedback right away instead of getting a lot of bugs and change requests at the end. It's not something new as well, there are frameworks like FitNesse by Robert C. Martin that accomplish this, the thing was that for some clients/projects you need to have an exact Excel equivalence in calculations, which means simulating Excel's errors as well. Even those, the customer is not aware of. That's where it's nice to actually verify everything back with Excel.

Estimation of software complexity in Agile projects

After that came Jarosław Swierczek with his 'Estimation of software complexity in Agile projects'. Now that was quite cool and controversial lecture. Jarosław stated that SCRUM's poker planning is nothing more than an expert estimation, something that have also occurred to me some time before.

Don't be fooled by the 'expert' part, expert estimation is nothing more than calculations based on intuition, something which may work for experienced people and repeating projects, but often end up with pulling numbers out of your ass. Sure, the poker thing helps a lot, having other people verify your 'out-of-ass' calculations helps as well, but it's still intuition. We would wish that it's at least heavy wizardry but it's not. It's not science at all.

Jarosław Swierczek stated that according to some statistics a bit more than 70% of expert estimation is wrong, when wrong means more than 30% difference. Unfortunately I had no chance to ask him where did he have this percent from and I believe that this may not be true for poker planning (does intuition work better for a group?), so it all stays as anecdotal evidence.

Anyway, he was able to show us a nice, scientific formula for estimating complexity and time-cost. Things that were especially interesting:

- You need at least two years of historical data (estimations of complexity and time + the actual results) to be able to do anything more than 'pull numbers out of your ass'.

- You need to choose a formal method of calculating complexity and stick with it (event the Functional Point method is not that bad)

- Complexity has got NOTHING to do with the time it takes to finish something

- How much time it takes, depends your team's performance, which should be calculated from sprint to sprint, which is depending on stuff like technology/experience/distractions, and can actually be calculated by expert method ('my intuition tells me I'm gonna be super fast/slow because I have a lot/little experience in this technology')

Jarosław has got his own consulting company Aion www.aion.com.pl where they help other companies with estimating complex projects, so of course you should be wary about marketing bullshit, but what he presented made a lot of sense to me.

Journey through tests and prototypes

The fourth lecture was given by Piotr Trochim, a game developer (his current linked-in profile shows CD Projekt RED, the company behind 'The Witcher'). Piotr was talking about TDD in game development, a situation which is quite different to typical enterprise/b2b/Internet development in that you create a hell lot of prototypes of different ideas before actually deciding what you are going to put into the trunk of your repository.

Well, we (Internet/intranet software developers) actually create a few prototypes too, especially when changing the technology, so it applies as well to us.

Since creating well written prototype does not pay off in the long run and only slows down the prototyping, Piotr suggested this change is TDD cycle:

- First create a working prototype or a few prototypes (max 4h) if you need to have to choose between something. Don't worry about tests, do it as simple and fast as possible.

- Decide whether the idea/technology is fine to be used on production

- DELETE the prototype(s) completely (never commit the prototype as it is very badly written)

- Now write the solution again, using TDD and best practices

- When you're finished, create a tool to help monitor/debug the solution. This could be anything from stuff as simple as logging annotation (so you can turn logging into debug mode and see what happens), to state visualizers.

For me the most important part was to NEVER commit the prototype and always delete it completely. This is something I've seen way too often, when programmers commit a completely chaotic prototype just because it works and try to extend it later with very poor results. It usually ends in refactoring bigger/longer than actually writing the same stuff the proper way.

It was also interesting to note, that while Piotr is using C++ for development, he creates most of the prototypes in C#, as it's simply easier.

Yeah, I wouldn't like to return to C++. The expressiveness of this language simply sucks.

BDD and Ruby On Rails using Cucumber and Rspec

Last lecture was from Pawel Wilkosz about BDD and Ruby On Rails using Cucumber and Rspec. Frankly speaking I was tired, I don't work with Ruby and using TDD for more than last 4 years I didn't have much to learn in here.  That's where I'd rather be on 'People' track, where all the guests were having an Open Space kind of discussion.

And then there was an afterparty, but that's a completely different story.

You can find official pictures from the conference in here.
All pictures by Krzysztof Dorosz.