Agile Ethics

Agile started as a discussion of lightweight software development methods. At least, this is why in February 2001, 17 software developers met at the Snowbird, Utah resort. When I talk to people about what attracts them to Agile, I frequently hear that simplicity of approach resonates with them. Remove unnecessary complexities and waste, and do whatever is meaningful and productive, in a way that works now and here. That is beautiful.

This is not what attracted me to Agile as a concept though. I was fascinated by a simple fact that those people were talking about efficient ways of writing code, and yet they started with values. This did resonate with me. Developing machine code and thinking values – as counter intuitive as it may seem and as organic as it can possibly be.

I have been thinking about the value of having values recently. Specifically,  starting last week. I am trying to comprehend the concept of “prioritizing values”. How can you prioritize values? It’s either a value and then it is a priority, or it’s not, and then, there is no need to prioritize anything. Have you heard of work/life balance?  “I have my values but I am doing whatever is best for my family.” Does it mean I can lie or I can betray someone’s trust if I think this is best for my family? This puzzles me and yet, as a Coach, I hear it sometimes.

Throughout years, I’ve learned to understand the concept of “work/life” balance and yet I do not get it. When I am talking to my colleague or helping my son do his homework, am I a different person? Do I divide “me-at work” and “me-at home”? Do I have different values depending on where I am and what I do? Do I feel happy in a different way when my code finally compiled, or when an employee got a chance he has been waiting for, or when my son does subtraction without counting physical objects? Am I working when I write my Agile blog at 2 am in the morning or am I actually relaxing because I enjoy doing it? I think that the concept of “work/life” is made up by unhappy people who think that when work ends, life starts. Luckily, not so for many of us.

Going back to ethics. When I was a child, ethics for me was no different than etiquette. I associated ethics with eating with the right fork and it seemed to me just another unnecessary constraint humans establish to add unnecessary complexity to their lives. As a child, I implemented a lightweight process of eating everything with a spoon. Worked for me.

When I learned that ethics is a set of moral principles, the concept seemed even duller. Until a week ago when I finally understood why Agile is more than a framework for me. What resonates with me that these 17 people in Utah came up with the principles based on their beliefs. They did not think in terms of “work/life balance” or “I hate to do this to my team but I have to do whatever is best for my family”, they thought about what matters most and based their principles on the values they believe in. This is what ethics is for me. It’s our beliefs in what is right and what is wrong. And right for my team and right for my family are not in conflict. Just because there is one right, and it is the choice that I make.

 I believe that it is not material that the product of this Utah gathering was the Agile framework of software development. If this group of people were in aviation, they would envision an amazing plane which will fly faster than any other comparable plane. If it were an economics theory, it would explain many processes in the modern world that we are still trying to comprehend.

No matter what the area of knowledge is – right values create meaningful things, and this is what Agile is for me. Meaningful approach based on firm beliefs in right or wrong that resonate with me. And I find it hard to believe in “what is best for my family” concept because our values do not change when we come home from work. Otherwise Utah gathering would never happen.

Workplace 2020

 

I do not believe in coincidences. Actually, I do. I just think that most coincidences only seem to be such. Each time I am amazed by a coincidence and start thinking about it, I manage to figure out the reason for it. Here’s a recent example. I read a book about 2020 Workplace and listened to a presentation by Agile coaches at Spotify at NYC Scrum.  There were multiple great points in each, but two parallel thoughts fascinated me.

The book described the onboarding process in a 2020 company. A new employee joins the company. Actually, it is not exactly a new employee because she has been coached by the company and introduced to its business since middle school. But today, during the first day of her employment, she is having virtual meetings with three potential managers who share their vision and suggest work responsibilities to her, hoping that she will select each of them as a manager. And she is responsibly taking the challenge of finding the one whose vision and passion to the work resonates with her. And once she chooses this manager, she will rotate throughout the company during the first year of her employment growing to know the business and people until the chooses where she'd like to work.

The presentation from Spotify coaches was staged as an onboarding process where all participants had to imagine that it’s our first day with the company, and the coaches are telling us a compelling story of company’s values, structure, opportunities, and innovative ways to engage employees. They were not talking about Agile principles, rules, ceremonies. They were talking about the spirit, the “guilds” that promote employee collaboration based on their interests, about support within domain-based "chapters", the unity of "tribes", the ease of choosing and moving to a team, and freedom in selecting practices that work for a team.

I was talking to product owner today about killing team’s motivation with constantly changing priorities, about demotivating them by not releasing their work into production and by not sharing any actual impact of their work with them. And the product owner told me he has nothing to do with it because he has no choice. He depends on his manager, and his manager depends on his bonus. Plain Maslow's hierarchy of needs. No choice here.

All of a sudden it struck me what I liked in the book and the presentation above and what I do not understand in this product owner’s reasoning. 

In the book and in the presentation, the freedom of choice is as organic as ability to breathe. This is what makes us people, this is what motivates us and makes our lives meaningful. World literature is based on the dilemma whether we have choice over our destiny, or our lives are pre-determined by an outside power or environment we're in, whichever it may be. 

In order for our professional life to be meaningful, we want to be able to make our choices, good or bad – but those will be the choices we made. Not the product owner, not the circumstances, not even ROI – we want to work on things that are meaningful, on things that matter to us, and do so with the people we trust who motivate and inspire us. And we want to be able to make a choice.

This is what my responsibility as an Agile coach is: to ensure that teams have choice in making their professional life meaningful and their work emotionally rewarding. I just wish I could find better words in sharing my vision with the product owner. I am not giving up though. Not until his team is giving him another chance. I’ll buy him “The 2020 Workplace” for Christmas. Or Daniel Pink’s “Drive”. Or share Henrik Kniberg’s 15-minute speech about the essence of Agile. I am not giving up on him – he deserves having a choice, too.

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