My NYC Agile Day 2012 Observations, or IT is All About Simplicity

On September 20, 2012, Ilio Krumins-Beens and I co-presented at Agile Day NYC. It was a wonderful energizing event with several hundred participants from all over the world masterfully organized by Joe Krebs and the team.  I was excited to meet Harrison Owen, inventor of Open Space, who presented at a self-organization track and also participated in the Open Space next day. I was excited to meet Dave Thomas. I follow Dave on twitter and always enjoy hearing his perspective, whether he talks about lean principles or  suggests to retire object oriented programming. Dave is always mind provoking, never boring. Another topic of interest was a participatory workshop of advanced social games led by Stanley Pollack who uses these games with NYC youth to promote friendship and overcome violence. And of course, it was exciting to present and to hear feedback from the participants.

All the presentations I listened to were outstanding. I attended keynote by David Thomas who spoke about a number of topics he is passionate about: lean, OOO principles, requirement elicitation, customer experience. However, throughout all his speech there was one major thought: seek simplicity, do not try to over-engineer - neither the process, nor the technology. According to Dave, OOP is unnecessarily complex, why can’t you use a flat data file or Atom feed? Why would you try to create a 1000-page requirements document if the users in a neighboring department have already automated functionality using excel spreadsheet? Open your eyes, look around. Be simple. Simplicity is organic. It is natural. That’s what we all should be looking for.

Surprisingly, this was the note of Harrison Owen’s presentation at self-organizing track, too. We, human beings, try to plan and control. We create meetings with long agendas and fail answering questions. What is the natural way for a meeting? Invite those who’d like to contribute, those who are passionate, those who are interested, and if they exist, they will come. Don’t bother bringing in others because they will not add value, they will only demotivate the ones you are actually looking for. Bring in those who WANT to contribute. Don’t answer, ask questions. 

The following day, at Open Space, Douglas from American Express asked Joe Krebs and me a beautiful question: “would they come if …?” Would they do it (whatever it is) if they were not paid for doing it? Would they treat you with such a high respect if you were not their manager? Would they work as hard if they did not expect a reward? 

Eva told me that Ilio’s and mine presentation stood out among others. I was surprised because it was a day of excellent presentations and asked why. The answer was “because you are not professional speakers. Because you speak from your heart and it shows.” Isn’t that the power of simplicity? Talk about something you care about in the way that you feel about it. Nothing more simple that that. Thank you, Eva, for this simple and yet so profound thought.

And finally, at a games session, Stanley Pollack taught us how to unleash the way we feel and not be afraid to show it. After five minutes of the “tossing bag” game where I was blocking the flow of throwing the bags which were falling all around me, Staley and Heang asked us what we felt about the team members. When throwing and catching bags, all I could think of not dropping them, but once asked the right question, I said that I think Marco who threw bags to me paused to let me catch up at the expense of having Maria (who was throwing bags to him) being upset to him for failing to catch, and I found that Marco very thoughtful. In addition, Monica who was getting the bags from me, never showed any disappointment that I started throwing her pairs of bags trying to catch up, and after couple of attempts became very skillful in this role. I liked that she did not show me disapproval nor gave up despite having to get a few bags from the floor. Just a few minutes spent with a group of people I’ve never met before, several brief conversations, couple of games, and there is one thing I know for sure: I want to be on a team with Marco and Monica. No complex interviews, no tests designed by psychologists, just a simple workshop, and in the end, I know who I am compatible with professionally and psychologically. We humans are complex systems, no question, but the way we feel, think, change, self-organize, is actually very simple. Because simplicity is organic for us despite all our attempts to create complex rules and regulations. Same thought again.

When I was leaving the Open Space next day, Mary Pratt told me something that perfectly concluded these two amazing days. She  reminded Ambika and me that Agile evolved from something that was called “lightweight software development methods”. No wonder simplicity was my tune throughout two NYC Agile Days. 

Thank you, Joe, Ilio, Heather, Dave, Mary, Monica, Ambika, Marco, Douglas, Harrison, Stanley, Heang, and many old and new friends that I met at Agile NYC Day and the Open Space. We share interest in Agile, desire to learn, and passion of sharing. What can be more simple than that?

Agile Certifications

Further to my previous post on PMI-ACP, below is a link to my prezi.com list of Agile and other relevant certifications:
http://prezi.com/_7xp7tjkhczo/agile-certifications/

The most important point about taking certification for me is the cause. If the cause is to get a promotion, this may have some immediate motivation for some, but they rarely succeed. If the cause is to be better contributor to the team, it is a good cause and this individual has more chances at passing certification exam.

In terms of which certification is better, it is more about you personally. Who are you - scrum master or you have project management background? Are you on a scrum team or you use a different Agile framework? What certifications you already have? What is your primary role on the team? Add this information to your professional desires and beliefs and do not worry which certification is more prestigious. It is all about what is right for you!

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?