Performance Reviews in Agile

In my two previous blog postings, I wrote about performance reviews from employee's and manager's standpoint. Here's what I think overall (will be glad to hear from you too).


Feedback is important for human beings and it is one of the most important means of development. I agree that performance reviews are not the most effective way of obtaining feedback especially in Agile environment where there are a built-in mechanism for feedback, which is a retrospective. Effective retrospectives enforce Agile values and come from your peers. However, I still support all types of reviews in a corporate environment because it contributes to the atmosphere of transparency and continuous inspection and adaption, which are important Agile values.

There are several drawbacks but they can be mitigated:
1. People do not like to be judged. - Be non-judgmental in your feedback and prepare to take feedback from others constructively and continuously. It feels good once you get into the habit.

2. People are sensitive to feedback. - It is important to create tolerance for risk. If people are comfortable to try, make mistakes, and try again, they need feedback to succeed. Once this understanding becomes your organizational culture, feedback is welcomed rather than causes frustration from the recipient.

3. People get feedback but don't act on it. - Help your colleagues define professional goals that work for them and create such an environment where they will have an opportunity to share their success with others.

So my solution to ineffective performance reviews is: decouple performance appraisals from career development and more importantly, from compensation evaluation. Establish continuous feedback flow and a consistent and fair compensation system which does not depend on annual review. Whether it is google's promotion system or Valve's "select a peer" system, do not base it on performance reviews.

How does it work in Agile? This year, I added management responsibilities to my Agile coach role. This made me think of how we can utilize annual performance process effectively to grow our scrum masters. As a result, I decided to use goal setting process in such a way that scrum masters think about supporting company's business objectives and establish common goals for all the 12 scrum masters and their teams. We did brainstorming jointly (of course, we used stickies, silent grouping, and voting) and came up with 3 high-level goals: improve accuracy of planning, increase reliability of commit (there were KPIs associated with this to make this goal measurable, differing between teams), building self-organizing teams (this translated into different specific goals for each scrum master), and maturing product backlog quality. Each scrum master has a set of specific measurable (S.M.A.R.T.) goals associated with one of those, and will seek continuous feedback from the team, adjust accordingly, inspect and adapt.

How does it all translate to performance appraisals? First, those should not happen once a year, there should be continuous feedback, and all parties should be open to it. Second, it does not have to come from your manager, I think it is important to welcome any feedback you can get and not feel hurt or upset, kind of grow thick skin and take any feedback constructively. Third, think of it as of a way to help you become better, or help your peers become better, not as an input for your salary increase.

To sum it up, I agree with Mary Poppendieck that it is important to create an environment where you have a coach, presented with a challenge (Mihaly Csikszentmihalyi's flow), provide and are open to feedback, and foster dedication. How you do it is up to you, but if you find an effective way to incorporate performance reviews in this process, go ahead. Just remember not to be judgmental, rather, use it as a feedback mechanism and as an input to creating goals for your colleagues that will help them become better professionals, better leaders, and better team contributors.

On performance reviews - from manager's standpoint

This posting is Part 2 of my posts on performance reviews. These two postings are easier to read as a sequence because all of us are the recipients of  a performance review, but only managers have both experiences. Before I became a manager, I thought of performance review as a time and effort consuming but very rewarding process for a manager. I have seen a few managers doing it really well and helping employees with assessing their strength and opportunities for improvement, and coming up with a solid plan to work on those. This is a direct opportunity to develop your staff and make a positive difference in their professional growth.

I've heard from some managers that they provide ongoing feedback and if their direct reports need performance review, it means that a manager is not doing a good job. Take a pause for a second and reflect on this thought. Do you agree? As nice as it sounds, I personally do not. Ongoing feedback does not replace the need for detailed cumulative feedback which will then provide direct input into development goals and planning for this employee for the coming year, as well as into promotions and increases (or lack of those) for this employee. This does not have to happen once a month, I personally found out that once a quarter is a good frequency, but it is different from immediate feedback.

What are the inputs into performance review?
1. Last year's performance review and list of development and performance goals (if applicable).
2. Company-wide guidelines on the process and any pre-defined skills in the appraisal system for this role.
3. Role description for this position.
4. Feedback from multiple stakeholders from Business and Technology (if applicable) in different categories.
5. Your data/facts throughout the period of review and your opinion as a manager.

What is the output?
1. Weaknesses and strengths defined, discussed, and agreed upon.
2. Honest conversation about opportunities for improvement.
3. You either discuss development goals at this meeting or right after.
4. For the performance goals, you will have to collect input from you team, product owner (if Agile), business sponsor, and other stakeholders as relevant.
5. Good feeling of creating self-awareness and a plan to accomplish the employees professional aspirations on an individual basis.

Does it always happen? If you are a good manager, then often.What are the challenges? I've experienced three most common ones:
1. The employee is not interested in a dialog (tired, busy, does not see value, etc.) Whichever the reason is, manager's goal is to explain value while choosing more comfortable time.
2. Employee disagrees, e.g. if a manager suggests to improve a skill, and employee responds that this is actually his or her strength while assuming the manager is just not aware of what s/he is accomplishing. In this case, I suggest that the manager takes a genuine effort to observe this employee well enough to be able to assess the value provided, and if the employee lacks self-awareness, provide open feedback or do one of self-awareness exercises, e.g. http://www.estherderby.com/2012/05/self-awareness-matters-finding-your-filters.html.
3. Sometimes all employee is concerned about is tying performance to salary increase. Performance review is the time to review employee's strength and opportunities for improvement, as well as further growth. I do not suggest to discuss salary or promotions during performance review. It is important to explain that while there is impact, there is no immediate direct dependency, e.g.high appraisal does not immediately result in title and salary increase. Those employees have to be educated about the purpose of performance review. Manager's responsibility in this case is demonstrating value of this process for employee's development.

What do you think?

Scrum Master - Role or Profession

http://www.agileconnection.com/article/scrummaster-role-or-title

On Performance Reviews (from employee standpoint)

Many people hate annual performance reviews for a number of valid reasons. At a recent conference, I sat next to an engineering manager with 14 direct reports who told me: “If my employees ever need a performance review, it means that I am a poor manager.” His point was that if he does not provide ongoing feedback and needs once-a-year campaign for this, then he is not a good manager. There is even a book by Samuel Culbert “Get Rid of the Performance Review!: How Companies Can Stop Intimidating, Start Managing – and Focus on What Really Matters.”

S. Culbert identifies 12 problems with performance reviews:

1.           Performance reviews focus on finding faults and placing blame.

2.           Performance reviews focus on deviations from some ideal as weaknesses.

3.           Performance reviews are about comparing employees.

4.           Performance reviews create a competition between boss and subordinate.

5.           Performance reviews are one-side-accountable and boss-dominated monologues.

6.           Performance reviews are thunderbolt from on high, with the boss speaking for the company.

7.           Performance reviews mean that if the subordinate screws up, then the subordinate suffers.

8.           Performance reviews allow the big boss to go on autopilot.

9.           The performance review is a scheduled event.

10.         Performance reviews give HR people too much power.

11.         Performance reviews don’t lead to anything of substance.

12.         Performance reviews are hated, and managers and subordinates avoid doing them until they have to.

There is even a web site:  http://ihateperformancereviews.com. As it is stated there, “We hate performance reviews. We don't hate the idea behind them, we hate how most big corporations implement them. It's inefficient. It doesn't work. “ Guess what they tell you next? “We're here to change that. We make performance reviews work for you.” What is your take away? Mine is: “It is not performance review concept that is bad. It is poor implementations that make it inefficient and sometimes even harmful.” This reminds me of Agile. I believe in Agile because I know it works. When I am told that Agile is no good, I know I am dealing with a poor implementation of this framework.

So – I know this too well myself. At my previous job, I hated performance reviews. They were totally inefficient. Throughout a year, my manager was carefully maintaining a list of my successes and failures and took pride in making my performance reviews highly detailed. I was well aware of my failures and successes myself, so this did not add any value except for the ratings that I got. For me, these ratings are an HR tool, I do not need them, I have my own scale of measuring my successes and failures based on the effort/courage/risk that I took, and no one knows that better than I. If the ratings were used for salary increases, then having them would make some sense. Interestingly though, the year that I got an average of “outstanding”, I got 0 salary increase because by that time my salary was at the limit of my position range anyway. I did not get a title increase either, so I wondered why my time was even wasted on reviewing something I was aware of with the ratings that have no impact on anything. 

And this was not my time only. My manager was a highly intelligent professional whose time could have been better spent otherwise, and in addition, performance reviews were not his strong point anyway. I remember that during a performance review, I gave him my feedback and he stated that this is my review, not his, so this is the wrong time for that conversation. But this will be covered in my next blog post on managerial view on performance review.

First year into my current job, I had my first performance review which totally changed the way I thought about this process. My manager provides ongoing feedback on a daily basis which I appreciate and find very helpful. While daily input highlights specific examples, situations, behaviors, it takes an extra step to see a pattern. This is what annual review is like. While my annual review had specific examples, it indicated my areas of strength and weaknesses, many of them I was aware but did not think they were that obvious, some of them I was not aware and did not know my actions were perceived this way. During my performance review, I shared some thoughts on how I am planning to improve identified weaknesses, and got specific input and advice on those. In addition, my manager got feedback from a significant number of our colleagues in different roles – manager, product owner, scrum master, team member, executive director - and gave me citations without specifying their names. He insisted that respondents provided opportunities for improvement, so the feedback was specific and actionable. I loved it.

What did I learn about myself?

I am rigid. Hmm… I never thought of myself as rigid, and I still don’t. I listen and I am eager to compromise and put myself in others’ shoes regarding things that are not of a primary importance to me. As an Agile Coach, I am passionate though regarding things that I believe in such as standing at standup meetings, or having a scheduled day/time for sprint reviews (demo), and I take time to talk to the teams about the reasoning and the negative impact of sit-down standups or demos with no stakeholders because of last minute notice where the team feel discouraged rather than excited. And I always state it to the teams and I thought that this knowledge is well received, but I found out this is not the case.

What I learned though is that I am perceived as rigid. This was the biggest win. I did not adjust my beliefs, I adjusted my behavior. So I talk more about the reasons and – unlike me a year ago – I let teams try and fail (any they inevitably fail), and then we discuss the reasons at a retro and go back to standing standups and repeated demos. And sometimes teams continue this practice (I have one team that strongly feels this way) and this hurts their productivity, and – you know what – I am not going to force them, but I will continue providing feedback and working with them until they mature enough to see the value in standing. And for now – let them sit at a table checking their smart phones and losing focus – and I am not going to force them but I will highlight specific cases when participants do not hear questions they are being asked or replies are not related to the topic.

Actually, I think I have been a little bit rigid and I still am – at heart – but now I know that you cannot force people do right things, you have to give them time to understand this. Otherwise they will eventually roll back to bad practices anyway. Such a basic wisdom but it took me a performance review to figure it out.

What else did I learn?

Opinions are subjective. One respondent says that my communication is highly efficient, the other says that my communication needs to be improved. A set of post-presentation surveys gave my presentations a high average rating of 3.8 out of 4, while one of respondents says that my presentation skills are poor. A question: Should it bother you if you get any controversial reviews? My answer is: No. It is important for me not to take any of this controversial feedback personally but, rather, seek for ways of improvement. Even if I am good in something, negative response means that there are still ways to improve (aren’t there always?). So what I derived is my communication may be good but the level of details has to be better targeted to the level of my audience. Or, my presentations are generally not bad but I tend to speak fast and I should ask for more input from the audience.

Based on my performance review and citations provided, I came up with my improvement list and then improvement plan. Once I compiled the list, I put it on the wall and the file on my desktop. I check it frequently and I move ahead with my plan. I may not become the best presenter in the world (maybe not even on my team), but I know that I am getting better. I have read some books, listened to a few outstanding speeches, gave it some thought, and practiced a lot. So – right or wrong – this feedback was a great trigger for me to work on something and become better in it. And I told my manager that it has been my best performance review ever. I got great input into setting up goals for this year and inspiration to work on a number of good things, which I know will make me a better professional.

So – the point that I am making: performance appraisal process is good. It is bad implementations that make it inefficient. I encourage you to think how you can take advantage of your performance appraisal, what questions you can ask your manager, and which action items plan after you get it.

My next blog posting is on a different perspective. This one was from employee standpoint. In the next one, I will talk about what you can do for your direct reports as a manager but I plan to do it differently. I won’t talk about how you can benefit from the process, rather, I will talk about greatest mistakes managers do in their performance appraisals and how these mistakes may hurt their employees and their morale, and even lead to consequences these managers would never foresee. Trust me – I have made some of these mistakes myself and suffered from others, so I will be glad to share my firsthand experience with you.

I welcome any feedback. What is your experience with performance appraisals? Did you ever find those helpful?

On Pareto Principle

It has been many years since as a part of the Online IT team at a media company, I was part of the team effort in self-training in agile including prioritization techniques. During our mock up scoping exercise, a concept came up that 80% of value come out of 20% of requirements. We discussed where 80-20 concept applies in software development some further and came up with quite a long list of how this principle applies: 20% percent of project deliver 80% of value , or 20% of the team members deliver 80% of work. The latter has to be validated though – I hope this is Pareto exception J

Then, a few month later, I took an advanced project management class and learned about the Pareto chart and distribution types and where and how it applies.

Vilfredo Federico Damaso Pareto (http://en.wikipedia.org/wiki/Vilfredo_Pareto ) (15 July 1848 – 19 August 1923), born Wilfried Fritz Pareto, was an Italian engineer, sociologist, economist, and philosopher. He made several important contributions to economics, particularly in the study of income distribution and in the analysis of individuals' choices. He was the first to discover that income follows a Pareto distribution, which is a power law probability distribution. The pareto principle was named after him and built on observations of his such as that 80% of the land in Italy was owned by 20% of the population.

The Pareto principle, also known as 80-20 rule, helps define efficiencies for multiple systems – in software development and far beyond. Not that is universally applies – but thinking about this rule helps re-evaluate approach to project scope, resource allocation, and personal productivity. How? Just one example. In agile prioritization while prioritizing features and placing those on sprint backlog, we can try to identify those 20% that will actually bring 80% of value and acknowledge that while product backlog is never exhausted by deifnition, we are constantly delivering the need 80% to the business.

Hmmm. How universally is the distribution actually applicable? We are not talking income in Italia – can we apply this curve to software development? One of my colleagues actually tried to apply bell curve distribution to performance appraisals at an HR seminar on the topic. I personally advise against applying Pareto principle to bonus distribution though J

The 80-20 rule is applicable to multiple other situations and environment. Please provide your suggestions – and the one who provides the best input will receive a Pareto award. The winner will be selected by a poll – so total transparency and fairness is guaranteed.

And in conclusion, what is obvious to me is that 20% of the readers of this blog post will provide 80% of the valuable comments and Pareto samples. Are you in?

P.S. This  posting is my first attempt of taking a different look at familiar concepts. I’ll see whether it is of an interest to you. If it is, I am ready to continue with a new look at Deming and Plan-Do-Check-Act cycle. Or maybe you have your own views or suggestions for good candidates for the “Known Unknowns” category. Or does “Unfamiliar Familiars” sound better?

On Leadership

What is the modern perception of a leader? How is it different from what it was ten years ago? How it is applicable to our everyday work reality? No matter whether you a in a managerial title or not, did you ask yourself this type of questions?

Not that I have an answer. But I think it’s important to ask those questions once in a while. Each of us is a leader – in one capacity or another – but not always we realize that, or acknowledge the responsibility that comes with leading others.

I know what was a common perception of a leader in a workplace ten years ago. Someone knowledgeable who has the answers and provides clear and detailed directions to the team. Good communicator. Fair. More like a mentor and advisor.

How is team motivated in this case? It’s easy. As Agile Manifesto states, we are all good citizens. Team members in general want to please their managers and to be considered good contributors by  their peers. It’s in human nature. Things may get different but that’s for a different topic. So level 1 in team quality – compliance – is easy to achieve.

What this approach lacks? Buy-in from the team. Thus – level 2 in team quality: creativity. Level 3: Sense of ownership. Growth opportunity – in literal sense. Ability to grow up as a professional and start making decisions on your own. In the case of a decision-making manager, this is a leader by title and a governance tool but not someone who serves the team in terms of team-building and providing the members with the opportunities they need to succeed.

Is this getting different in a modern world? It is and it is not. People are not necessarily changing easily. In technology, however, we are more prone to change – because of the nature of our industry. We won’t survive professionally without constant learning – and this means the change by default. That’s why agile concept – self-organizing and self-building (self-maturing, self-governing, etc. etc.) teams – emerged in IT.

This does not mean that we lack managers who give orders – and teams are following those (remember, we are all good citizens by nature), however, we have the new breed coming – those who see management function in serving their teams – making them more efficient by satisfying their needs – shifting decision making and ownership to their members and empowering them with ability to think creatively and take  ownership. And the process has started – and I can see it well with the emerging USES agile team – and not just IT members of the team. And it’s a good picture.

I really like the concept of leadership as a service. And this concept is not a new one. Mahatma Gandhi said: “The best way to find yourself is to lose yourself in the service of others.” This concept perfectly applies to project management, any other area of management, or leadersip in general. It is so important to be a servant, not a manager who gives instructions but leader as a team member who builds trust and promotes respect. This is the key to team’s success.

I listened to a webinar on leadership and project management. The presenter was talking on  leadersip and success as it relates to project management. She said: number one driver for project success – guess what? Business case with proper ROI calculated? Resources? Careful planning? Fixed scope? No! Trust between team members. If this is not achieved, this results in slower delivery, lower quality, knowledge trasfer gaps, high maintenance costs. And number one recipe for failure? The environment where people are afraid to admit their mistakes, where collaboration is not promoted, where individual success is above team’s success.

And this is fundamental. Project success is not about technologies and processes. It is about people. So if we fail as a team, it means that we are not ready to take ownership, to makes decisions, to put our success as a team over each member’s personal contribution.

And what is leader’s role on the team? Serve the team by building it based on trust, respect, open communication. That’s why a new term comes into play: leadership as a service. I think this term reflects the nature of modern leadership very well, and a manager is a service provider to the team in the same sense as SAAS vendor provides a service to its customer.

What do you think?

How My Team Decomposed Agile

Below is my submission to NY SPIN Process Nightmare Session in April 2012. This submission was selected, and I had a chance to present to the audience of software professionals. It was a great experience both having a chance to present and to listed to my fellow presenters about their experience. My favorite question from the audience was "If you did it all over again, what would you do differently"? Guess what I answered?

Anyway, below is the submission.

An “Agile Hammer”

(How my team decomposed agile)

Summary. Have you ever heard of a hammer analogy when people talk about scrum adoption? Imagine you need to put a nail down and decide to use a hammer, but you do not see the value or just don’t know how to use the hammer. So you decide to decompose it into two parts. Now you can use a handle or the metal part to put the nail down, and either part is more effective than a bare fist. But only when you use the hammer as a whole the way it’s intended to be used, you will be able to achieve true efficiency. This is what my story is about: how my team adopted agile by decomposing it, and as we were progressing with our implementation, we realized the value of all the missing ceremonies and ended up with an efficient “agile hammer”.        

How did it happen?

In 2005, when Agile adoption rates according to Forrester research were about 15%, I was a project manager on a team of 13 (6 developers, 3QA, 2 BAs, dev manager, and I) responsible for development and support of an enterprise level proprietary application. We were a waterfall shop and I quite enjoyed my role of a PM – my 10-page Gantt charts gave me a sense of accomplishment and I felt I was in control as long as my MS Project Plan was updated on a daily basis. The only downsize was normally towards the end of the project when I was able to accurately assess progress and it would become obvious that after 6 months of hard work and one week into QA testing we are completely off track and something needs to be urgently done. Then, I would alert my business stakeholders, risk and issue logs would start growing exponentially, and for another 3 months my team would lose any sleep trying to catch up. 4 QA cycles later, after descoping or phasing out nearly 50% of functionality, we would deliver working software, then struggle to fix post-production defects for another two or three weeks, and after celebrating the fact that the nightmare of that release is behind, we would start new projects slowly, giving a chance to developers to relax a little bit during requirements gathering. Despite the team working crazy hours, the business was never appreciative citing long time to market, low quality, and lack of visibility into the project progress.

And then one day dev manager called a meeting and said: We are going Agile. I thought he meant: We are going crazy – because at that time we were into the “meet-the deadline-or-die” phase of the project when the business informed us that because of a competitive product which was just release, the work we were doing for 6+ months was useless and we had to start requirements gathering cycle all over again. So I asked what he meant by Agile, and he said that this is a new framework which will help us adapt to the changing business needs and we would be able to produce working software within two weeks. We all laughed. Our application was a multi-tier multi-technology enterprise level platform with a distributed team in 3 countries working on it – how was that possible? Quite possible, he said, and here are the rules: you meet every day for 15 minutes, have a business stakeholder dedicated to the team and available every day, you stop doing hourly estimations and assign abstract point to your requirements, which are not requirements any more – they are called stories, and when you are done, you invite the stakeholders and show them the work. We said that it is insane to move from 9 and 12-month projects to two weeks, and besides, how do we know if it works? Retros, he said, it’s like lessons learned, we will inspect and adapt, and this way we will continuously improve our practices.

We decided to give it a try. The first few months were a nightmare. Our daily “sit down” meetings were one hour long, we were constantly stepping on each other toes. Our product owner was telling the team to switch to a different project mid-sprint. Acceptance criteria were not available. Product backlog was not prioritized. We decided not even to try estimation – this was too complex to grasp. We were not meeting our commitments. Our retros were more about complaining how painful this experience is and how we miss waterfall with uneven load and unhappy business stakeholders. We started moving towards agile more: implemented story point estimation, started to stand during daily meetings which miraculously became shorter, started parking discussions and answering only three standard questions, our retro became focused with action items which we were tracking. The business gave us a stellar feedback, and after sprint 5, we were stunned when someone on the team noticed that we stopped having post-production defects. However, we still had our mini-waterfall within each sprint: requirements gathering, development, QA, and UAT. We even split the team into two, so that their cycle overlap and eliminate productivity loss. We thought we were doing as well as it is possible until a during sprint 12, someone from QA said that she wanted to do some development and was successfully trained. One sprint later, we need additional QA resources and one of the developers volunteered to help. We merged back into one cross-functional team and abandoned mini-waterfall.  At that point, we thought we cannot become any more productive, but our productivity tripled, and other business units decided to try agile because our stakeholders were as satisfied as never before. It was not perfect and commitments were still occasionally missed, but we as a team – no longer divided into business and technology – were confident of our ability as a team to deliver high quality work while growing professionally and enjoying what we were doing.

This team-level transformation took us over a year, and now looking back, I realize that we made a natural move from agile piecemeal to a standard scrum implementation. While being able to realize some benefits right away, we were step by step implementing standard practices – stand up meetings, story point estimation, retrospectives – and moving towards Agile. Each step made us more successful, but only when we connected all the dots, we were able to see exponential growth of productivity. This reminds me of an analogy I came across in one of the blogs. Imagine you need to put a nail down. Take a hammer. Let’s say you do not see the value or just don’t know how to use the hammer. So you decide to decompose it into two parts. Now you can use a handle or the metal part to put the nail down, and either part is more effective than a bare fist. But only when you use the hammer as a whole the way it’s intended to be used, you will be able to achieve true efficiency.

Since this first experience, I worked as a scrum master on many teams, and finally moved to another employer and became part of team that is responsible for company-wide transition to agile. In my role of an agile coach, the first thing that I tell our teams is: Agile requires discipline, do not try to pick and choose until you master it well. Only then, you will be able to determine what sprint duration, what estimation technique, and team composition is optimal for your team. Follow Agile framework that you chose step-by-step, otherwise you will learn the value of Agile as a whole the way my first team did, through painful trial and error, through a “hammer” approach.