High-Performing Teams

In this keynote by Shane Hastie, agile product management guru and director of Agile Learning Programs at ICAgile. Shane mentions two very interesting studies about high-performing teams. The first one is related to psychological safety, and the second one is related to long-lived teams.

Psychological Safety

In work by google to know what makes a good team in google. They found that the single most significant factor is psychological safety. That is, you have support from your team to make mistakes and learn; in other words, your team will hold your back :) They were stunned to discover that technical superiority had no effect.

In sales teams, the presence of psychological safety resulted in an increase in revenue generated by this team above the norm with 21% and the absesnce of it resulted in a decrease in sales figures below the norm of 19%. This makes 40% difference, which is huge!

Long-lived teams

In an HBR article in December 2013 titled: The Hidden Benefits of Keeping Teams Intact, They say that "at a software services firm, a 50% increase in team familiarity was followed by a 19% decrease in defects and a 30% decrease in deviations from budget" just by leaving the teams intact.

Lessons Learned from Mob Programming

Recently, I had enough time to experiment with mob programming, a revolutionary technique for developing software. It's like pair programming with 6-7 team members in stead of 2! Seems ridiculous, right? This is how extreme programming (XP) practices seam at first before they spread like wildfire!

For those who didn't hear about it, please watch this video:

To get a deeper dive, watch this lecture by Woody Zuill, the father of the idea.

Currently, mob programming is spreading so fast in the world, and people are starting to realize so much value out of it. In the Agile Conference 2017 (which I'm on the reviewers list of its program), we have two sessions on mob programming, one talks about this technique used for on-boarding large number of people, and the other talks about it in teaching colledge students.

Working With Mob Programming Onsite

Now, back to the topic. I worked with two teams to whom I introduced and used this technique. One of them in co-located, and the other is distributed. I'll introduce the setup of the onsite experiment, then will list some observations and lessons learned from both teams.

We have restructured the room, got a projector, and started the session. Here is what we've done:

1. We have dedicated an on-wall kanban board, other than the one on Jira
2. Started with three main tasks for the day, which are the most important ones so far
3. I have explained some basic rules for the game, one of which is that I'll act as the facilitator
4. Then we started!

Rules of the game

Several basic rules are put into action:

1. We'll break every now and then, probably once every 1-2 hours
2. It's ok that you leave the room for any side task, not for so long though
3. Any emerging unplanned task will be put on the backlog. We've started with three tasks on board, and ended up with about 13!
4. Work is time-boxed from 10 am till 4 pm. No other "significant" work should take place outside these working hours

How people felt about it:

"Some tasks would have never been carried-out without mob-programming them" - one team member

 It's very interesting seeing how people interact and collaborate during the session. Here are some observations I noted:

• Contrary to what I expected, technical leaders and development managers where happier with this technique. They felt more confident and more productive. Plus, they appreciated learning from other team members while mobbing!
• Learning took place in all directions. seniors taught juniors and vice versa. Old team members taught new one and vice versa. This was amazing! One can never think of what new ideas, techniques, even inspirations he'll learn from other team members unless he start working with them hand-in-hand
• Interaction and collaboration were high, definitely higher than solo-programming, probably a bit lower than pair-programming. Again, this is contrary to my expectation, which was that half of the team will take a long nap during the session :)

 Finally, here are some feedback points I got in the retrospective;

• It was fun! and joyful
• Some tasks would have never been carried-out without mob-programming them
• We used to do the same task so many times. This way, we all do it one time!
• Collaboration with the product owner is much better; we all ask him the same question, get the same answer, all at the same time
• It's a better approach to reach the best solution for a problem
• It's less suitable for small and easy tasks
• It may be impossible to work this way if we're working under pressure

All-in-all, it was an excellent experience. Right now, I'm engaged with a company doing remote mobbing as a means to train new team members in a faster and more effective way. Guess what? Still the old team members learn from new ones!

Tragedies of Performance Evaluation of Software People

I'm constantly having conflicts with managers who insist on backward methods of performance evaluation for agile teams. It is one of the miseries of software teams, because in most cases, such methods demotivate individuals and undermine team values. The issue is serious to the extent that Professor Edward Lawler wrote a recent post in Forbes magazine titled: Eliminating Performance Appraisals. In this post, prof. Edward questions whether organizations should stop doing performance appraisals altogether, because they “do more damage than good”, and “when poorly done, they create a multitude of problems”!

I felt I have a moral obligation to write something in this regard. My contribution in this post is a collection of resources and an attempt to structure the topic into three high level subtitles:

1. What's evil about performance appraisals
2. Should smarter people be rewarded more money (as a means of motivation)?
3. Using process data for the sake of individual performance

If you are a smart person suffering from a performance evaluation scheme from the middle ages, send your HR manager this post, and let him read the resources mentioned below. May be (I'm not sure) it may help.

1. What's evil about performance appraisals

First, this is an article: Should I Rank My Employees? from the Wall Street Journal. It mentions the following interesting survey:

"Stanford professors Jeffrey Pfeffer and Robert Sutton are among the most fervent critics. They cited a survey of more than 200 human resources professionals from companies employing more than 2,500 people that found that even the more than half the companies used forced ranking, the respondents 'reported that forced ranking resulted in lower productivity, inequity and skepticism, negative effects on employee engagement, reduced collaboration, and damage to morale and mistrust in leadership.' … "

Another blog by the famous software engineering management author: Esther Derby titled: Should a ScrumMaster (or any coach) Give Performance Appraisals? In this blog, Esther asks how would it be good while "psychologists know that 80 percent of people believe their performance is above average"

The topic of performance appraisal are very controversial to the extent that one of the so famous books in management in the last years is called: "Abolishing Performance Appraisals: Why They Backfire and What to Do Instead"

2. Should smarter people be rewarded more money (as a means of motivation)?

We need to change our believes that a merit system will not work unless it ranks employees into classes and every class is motivated by some more money.

This is a must-see master piece by RSA Animate: Drive: The surprising truth about what motivates us:

In this short animation, they attack very strongly the idea about motivation using financial incentives when it involves cognitive and knowledge work. At minute 1:50 till 4:15, this animation sites the results of a study done by three top universities in Engineering and Technology: MIT, University of Chicago, and Carnegie Mellon university:

"As long as the task involve only mechanical skill, bonuses worked as expected (higher pay = better performance). But, once the task called for rudimentary [basic or simple] cognitive skill, a larger reward led to poorer performance!"

Also, one of the most important books in software engineering history is Rapid Software Development: Taming Wild Software Schedules by Steve McConnell. This book was named the best Software engineering book in the year by Software Development magazine's Jolt Award. Please refer to this book to understand what motivates Software engineers. Chapter 11: Motivation is the best reference I read about motivating software engineers. In page 262, you'll find this quote: 

"At least two-dozen studies over the last 30 years have shown conclusively that people who expect to receive a reward for doing their jobs successfully don't perform as well as those who expect no reward at all (Kohn 1993). The work itself is the greatest motivator, and the more a manager stresses an external reward, the less interested the developer becomes in the work itself, and the more potential motivation is lost."

The author makes a very clear alarm that incentives has many forms which are non-monetary like:

• Dinners with company executives
• Vacation-time bonuses
• Gifts of appreciation (theater tickets or dinners for two)
• Sincere praise directed at a specific accomplishment
• Team T-shirts, polo shirts, rugby shirts, watches, pins, mugs, posters,
• Humorous or serious awards in the form of plaques, certificates, trophies, and the like
• Special events to celebrate significant accomplishments; depending on your team's preferences, and event might be a dinner at a favorite restaurant, a show, a trip, a ski day, or a dinner at the boss's house (or, for maximum effect, the boss's boss's house)
• Exceptions to company policies for the team, such as casual-dress Friday, a Ping-Pong table in your team's section of the building, free soda pop in the team refrigerator, and so on
• Special courses (outside the local area)
• Sponsorship at conferences that the organization would not ordinarily sponsor
• Grade-level promotions

You can download this book from this location.

One more article called One More Time: How Do You Motivate Employees?, which sold more than a million reprints making it the most popular article in the history of the Harvard Business Review. In this diagram, notice the particular position of the salary and it's weight as a demotivator rather than a motivator. 

Motivators and demotivators - Notice that salary (money) is not among the motivators, but rather a demotivator in case salary is not sufficient

Actually, what this diagram tells us is the same exact phrase mentioned in the RSA movie above at minute 4:50:

"If you don't pay enough, people won't be motivated. Pay people enough to take the issue of money off the table"

3. Using process data for the sake of individual performance

Forcing managers to use process data, like feature estimates, number of bugs, reported actual hours, etc. to evaluate team members will blow up the process metrics themselves. This, in turn, has a drastic effect on the process itself, making the team process-blind (not being able to improve the process based on process metrics) Being process-blind is the direct result of exploiting process metrics and reuse them as Targets, and as per Goodhart's law: "When a measure becomes a target, it ceases to be a good measure."

Why this happens? To understand the dynamics, let's recall the general rule put by Tim DeMorko, the author of the great book: Peopleware: Productive Projects and Teams's, a book which had an impact on the whole industry; the general rule is known as DeMarko's Principle:

"Effort moves towards whatever is measured"

This can happen subconsciously or even consciously; and this is considered one of the major pitfalls of measuring, as explained the this article: The seven pitfalls of performance measurement which considers: Risk of manipulation of performance data as one of them. When it comes to individual evaluation, use of process metrics becomes a real risk, and opportunity of manipulation is so widespread. Writers have been noting this again and again, to the extent that some writers like Eli Goldratt, the father of Theory of Constraints says:

"Tell me how you measure me, and I will tell you how I will behave!"

In summary, using process metrics to evaluate individuals distorts the metrics and after a while, the metrics lose their meaning and cease to reflect real process data.

A Final Word

Finally, I have to say that this topic is vast and needs a lot of effort to make a shift in the mindset of project and HR managers of software in Egypt. It is not easy, but impossible is not on my dictionary :)

Becoming a Technical Team Leader (TTL)

2003 I was appointed a senior position at IBM and became a technical team leader. This appointment was based on two things. First, I have spent 3 years in development. Second, I was an excellent developer! Are these enough criteria to become a technical team leader? I've already experienced the answer myself. I have led the team the worst way one could imagine!

Since then, I have been thinking about this topic, and read the excellent book of Gerald Weinberg, Becoming a Technical Leader. After years and years of leading technical teams, the idea became very clear in my mind about what it is like to be a technical team leader; what's expected from you, what's your necessary qualifications and what's you main responsibilities?

This is an attempt to answer this question:

Technical Leadership Core Responsibilities

A Technical Team Leader (TTL) should demonstrate capability in three main areas:

First and most important: Team Support. He can motivate the team, he has the ability and art of facilitating team activities, and he can organize team work into a process oriented manner. 

Second, a TTL is responsible of nurturing/enforcing and monitoring the product technical excellence and high quality. More specifically, the TTL is not responsible of doing this, but he is responsible of making sure this is realized by the whole team. To be more clear, if the TTL has developed an excellent product by himself while the team is doing nothing, then he is still failing in this regard. 

Finally, a TTL should sponsor innovation in the team. This is different from technical excellence. It is related to the team spirit and desire to experiment and try new things and unconventional solutions. This is different for problem solving, because you can solve a problem in a dumb way! What the team needs here is someone to sponsor the activity whenever it is needed and make sure a problem is solved in an innovative, not dumb, way.

In all of these responsibilities, there is a common component of organization. The TTL is responsible to organize accumulated knowledge and information gained by the team, and make it available and easy to find and use when necessary by any team member. Also, organizing the team process, which is a responsibility which may take a lot of time and effort to monitor and foster.

If you are going to become a TTL, make sure you get enough knowledge about these topics above. It is your responsibility to become knowledgeable, or else you will spend years or fumbling in the darkness and learn by trial and error!

Well, Agile Teams Should be Appraised as a Team ... Hmmmm

It may be useful to think this way. Agile teams are cross functional, self organizing, and collectively accountable for work results. Therefore, they should receive one score at team appraisal, and hence one raise, and one bonus, and one etc.

Very true. But, appraisals have another merit other than calculating the yearly raise. It should be used an invaluable individual motivator for self improvement, specially for teams whose work products involve highly innovative and creative work .. wow!

Usually, what I have seen in enterprises is that individual appraisals were a source of all kinds of nuisances, for the individual, for his manager, for senior management, for all the organization. It is rarely accepted, and usually results in demotivation of 90% of the individuals who see the results as unfair and biased.

There are causes for such phenomena, and here are five of them:

1. Using process data in evaluation, like the number of bugs, or the code review issues, or the produced LOC per hour!
2. Using everyday events and situational happenings as evidence for good or bad evaluation
3. Mixing individual productivity and team productivity metrics, and using both interchangeably while evaluating the team.
4. Single-rater evaluation by direct manager.
5. Using the appraisal as a motivational tool. That is, let's appraise the team, and give them a raise so that they become motivated. This doesn't work, and the higher the raise become, the more demanding the team will be.

Ok, how to appraise Agile teams? I'll prepare a model for that. This model sets two objectives for evaluation: Evaluating the process, and evaluating the individuals. The metrics and techniques used to evaluate the process are completely different and disjoint from metrics and techniques to evaluate individuals.

This will be my work for the upcoming several weeks. Keep alert!