Performance reviews are incompatible with the Agile mindset!!!

Posted: November 17, 2013 in Agile, Leadership, Process Improvement, Product Development, Scrum, Software Development, Team Building
1

Hi guys, in my last post, I explained what a performance review is, and why it fails. In this post, I am going a bit further. I explain how performance reviews are incompatible with the new way of leading people.

In modern companies that embrace Agile mindset, it is expected to focus on team work, but in reality individual performance reviews focus on us as individuals not on the team itself. When we forget ourselves and focus on the team, problems such as the ones that were referred, here will arise. Another possibility is the other extreme that is referred in Abolishing Performance Appraisals refer: “Yes, work in teams, but remember, take credit for yourself, get recognised, watch your back because you are accountable for you, and that’s what goes in your file, not the team stuff”. I do not see value in any of the situations.

During the past years, several books were published about the importance of unleashing intrinsic motivation on people during their working time. Companies keep focusing on practices that reinforce the behaviour “do this and you get that”, and this is exactly what performance reviews mean. My friend Vasco Duarte says that performance reviews are a hidden whip from your boss, it transmits the idea of: “Do what I want or there is no bonus or career advancement for you”.

Another interesting characteristic of modern management is the fact that we want to respect diversities. Like Tom and Mary say: We want to manage for diversity and capitalising on the differences in people, instead with performance reviews we create an approach “one-size-fits-all”, treating everyone in the same way forcing using the same process over and over again.”

New managers understood they need to shift a focus away from inspecting people to examining and understanding processes, instead they rely on people inspection and Management by Objectives. Processes should focus on JIT (Just in Time) way of working. Performance reviews cause supervisors to stockpile and rework feedback, guidance and development triggered by calendar rather than offering help just on the right time.

Modern management already understood that a system is not the sum of its parts, it´s the sum of parts plus the interaction of all parts. So why companies care only with the parts (this is what performance review does) instead of focusing on improving the whole system.

Below there is a picture I took from the book Abolishing Performance Appraisals by Tom Coens and Mary Jenkins. This picture is a fantastic summary of why performance reviews are incompatible with new ways of management.

Hope you did like this post.

Please contact me if you have any questions.
Cheers,
Luis

Get Rid of Performance Reviews!!!

Posted: November 10, 2013 in Agile, Leadership, Process Improvement, Software Development, Team Building
4

Hi guys, last week I wrote a post that was quite polemic and got a lot of attention. I wrote about an elimination of managers in our organisations performing an usual old management style. The old management style is obsolete and we need to think about new ways to help our colleagues and employees. The previous post can be found here.

This week I want to continue this discussion and explain why we should abolish performance reviews. I have been reading several books about the topic and I wanted to leave some ideas that I collected from the book: ““Abolishing Performance Appraisals”“

65675.strip

Our world is changing, our mode of working is shifting to empowerment, collaboration and teams. This means that each company will need to shift from managing people to help people managing themselves and the business. Many companies think that helping individuals to get better is the recipe for the organisation to improve as a whole but often they fail. Substantial organisation improvement can only be achieved by improving the whole as a complex system. Naturally, individual improvements efforts are beneficial and often necessary but too much emphasis is placed here.

What is “Performance Review”?
Tom Coens and Mary Jenkins define Performance Review in their book as: “The process of evaluating or judging the way in which someone is functioning”. It is even more interesting as in most cases managers do not have any contact with our daily work. So can you explain how they can actually evaluate or judge our work? If you know how to explain, please contact me, I am eager to learn

I think I am not alone thinking about this issue. A survey performed by the Society for Human Resources management found that 90% of performance review systems were not successful. So why do we hang onto a process that does not work? Because people and organisations think that no performance reviews means no feedback, no special help on career development and performance issues. They think their salary increases and their career development will be decided arbitrary without any input. Another important part is that people think they need performance reviews to tell them where they stand. They believe that an evaluative system will recognise it and reward them.

Why performance reviews fail?

The problem with performance reviews is beneath the surface in the form of underlying assumptions, i.e, the basic premises and beliefs upon which the performance reviews are built. Below you can find two tables from the same book where the authors list several assumptions and identify the problems with the same assumptions.

photo (1)photo

On the next post I will explain the clash of performance reviews with our new way of thinking in modern companies.

Hope you enjoyed this post.
Luis

Get rid of Managers!!!

Posted: November 3, 2013 in Agile, Leadership, Process Improvement, Software Development, Team Building
9

Hi guys, this blog post is the result of a chat that I had with a friend of mine today. He called me asking for an advice about team leaders within scrum teams. Right after we booked a dinner, I understood that this is a very interesting topic that cannot be discussed over the phone

As soon as we met, he told me that his company decided to insert Team Leaders in his teams. I just smiled because I knew what was coming. So I asked:

“What is the biggest reason behind this? Why did you think about this strategy?”
He explained they feel they spend too much time with 1:1′s and performance reviews not allowing them to focus on their jobs. Afterwards I asked: “Ah, so you think that getting people to do what you do not want to do is a better way to improve the company as a whole?”
He seemed a bit embarrassed and continued:

“No, it´s not about us, this is a better way to give more attention to people and help them to improve themselves and their career development plan”. I reacted to this as following:

“What factors do you have in your possession that lead you to think that a manager knows better what a person needs for his improvement than the person itself?” He did not really know what I meant so I explained:

“Managers think they know the best what people need in order to develop their skills, but in reality is the person that knows where are her/his strengths and where to ask for a support, not other way around!” Then he said:
“Yes but we need to have a person within the team that has an overview how people perform because HR demands to have an annual performance review”. My immediately thought was:

“Ah, it comes from HR! Performance Reviews Of course!!!!” I just told him that perhaps it is time to rethink their way of management. I asked if he really believes that annual performance reviews bring any value to employees !!! He replied:

“I do not think it brings much of the value but we need to know how people perform in order to distribute bonus, salary increases and all perks. So I replied:

“Ok makes sense, but if you are trying to empower teams to be independent, why not delegate that to them?” Naturally, he was shocked!
“Let me explain: you, as a manager, you have your budget, you know how much money you can spend on salary increase, why don’t you talk with the team and give the constraints to them.” For example:

“Tell them that you have 10% of budget increase to be distributed within the team. Ask them who deserves what and allow team to decide that. They are the ones knowing who performed the best! We do not need any manager or HR person saying what percentage they deserve! In our companies, we are trying to reward a success as a team but what you do is destroying a team spirit.” Take this example:

“Imagine that you, as line manager, set objectives for a developer to develop his JAVA skills. Imagine that during the development process ,the team needs his strong skills in scripting to solve some problems they have. The team as a whole was able to deliver fantastic results but you will rate this guy as a poor performer because he did not developed any skills in JAVA!!!! Do you see where am I going?” He replied:

“Uh, you are so right! I cannot imagine the face of the poor guy that will get a really crappy review whereas in reality he did a fantastic job to help the team”.
“Exactly!!! You should empower the team to take their own decisions. The same applies for training and bonus. Ask the team what perks does each team member deserves. This is a complete radical approach, so I am not asking you to do it in whole organisation, instead, try it in a small team and see the results. Learn, change and adapt. The old way of management is outdated and obsolete. One of the big problems is that we are implementing agile in our organisations but we forget other part of the organisation still uses old policies that ruin the work that we are trying to achieve”. He was completely surprised with the outcome of our conversation. I guess he expected something else but I think I succeeded because he promised that he would give it a thought about it.

In a conclusion, the title of my post does not mean that we should get rid of managers. Instead, we should get rid of managers´ job role. We are dealing with super intelligent people that do not need some random person telling them how they need to do their jobs and most importantly, suggesting what they need to improve as professionals.

If you want to know more about companies that are adopting a NoManager approach take a look here and here. Do you know any other organizations that are doing the same? Share with me.

“We need more leaders in our companies and less managers!”

Thanks for your time,
Luis

Success Criteria for Retrospective Topics

Posted: October 30, 2013 in Agile, Coaching, Process Improvement, Product Development, Retrospectives, Scrum, Software Development, Team Building
7

reclaiming_gods_hopeHi guys, this blog will be short and simple . My last posts were about the reason why we should chose a single topic to take out of a retrospective and why we should do a proper root cause analysis for a selected topic. In this blog, I will introduce something new that I believe we should define more often: “Success Criteria for Retrospective Topics”.

I guess now you are thinking: “Oh my god, this guy is crazy, a success criteria for a retrospective improvement topic…!?” Let me explain my idea before you criticise. Most of the times, we perform certain tasks without thinking how do we consider them to be successful. How do I know if what I did was successful or not…?

Few weeks ago, a Scrum Master who I coached, asked me for an opinion about something that a team decided. I answered asking him “How will you know if what you decided will help the team or not? How do you know if what you decided is making things better?” He stayed silent and I assume he did not have any clue. This is just an example, however, I believe this is what happens in 90% of any cases, we do a lot of things without thinking what is a success condition of our actions.

For example, in many industries, a PDCA cycle (Plan,Do,Check,Act) is not uncommon. Basically, we plan what we want to do with a success criteria, we do what we planned, we check the success against the success criteria and if the implementation was successful, we chose something else to improve, if not, we try something else that will solve the problem (this was a super simplistic explanation for you to get the idea).

So my idea is why not start using something like this in our retrospectives? I do not want to create anything formal or any process out of this but just to force us to think about our actions to see if what we do actually helps or harms us.

What do you think about this idea? Is it something crazy? Give me your feedback please

Thanks,
Luis

Why do we lose time with root causes analysis in Retrospectives?

Posted: October 27, 2013 in Agile, Coaching, Process Improvement, Product Development, Retrospectives, Scrum, Software Development, Team Building
9

Roots_by_cesarpb Hi guys, in my previous post I explained why we should chose only one issue to improve in our retrospectives. This time I want to discuss what to do with that “single issue”.

One of the big reasons why I am writing this blog is because I believe I failed as a coach during last weeks, and I want to share this with you so that you do not do the same mistake. During last retrospective, one of my teams came up with nine topics to improve and most of the topics were super general, like for example: “improve communication”, “be more responsible”, “take more ownership”, etc.

Having a long improvement list is actually a quite common smell of a retrospective (more here). So what should you do in order to avoid this problem and what can you do to leave the retrospective with a good understanding of the problem? In my opinion, you should chose one simple topic to improve as I explained in my last post. If you have several topics on the list, ask your team to do a vote session. Ask them to chose what is the most drastic problem they should fix.

After having selected the biggest problem, we should spend some time to understand what is the root cause of the problem. I think this is one of the most important parts of a retrospective where a team will truly understand what is going on with a system. Without understanding this, your team will not be able to fix the problem.

All mentioned topics, like: “improve communication”, “be more responsible”, “take more ownership”, they are simple symptoms, they are not the root causes. People need to stop and understand what affects communication, why people are not responsible or why they do not take ownership of their tasks.

So please if you are a coach, scrum master or anyone responsible for facilitating a retrospective, make sure that teams chose one single topic and they go deeply to understand it. I just want to make sure that you guys are aware of a common pitfall, I did this mistake myself during last weeks but I am sure there is a lot of people who do the same.

Hope you enjoyed this post.

Please let me know what you think.

Best Regards,
Luis

Do retrospectives more often!!!

Posted: October 23, 2013 in Agile, Coaching, Process Improvement, Product Development, Retrospectives, Scrum, Software Development, Team Building
0

Hi guys, in my last post I explained why I think we should take a single item out from a retrospective. This post received some interesting feedback. One of the examples is: “If a team is big or if items are small, there is no point taking just one item.” My opinion is still the same: we should stick to one item at a time. We all work in complex systems, therefore, when we solve any problem around it, there is a big possibility that the whole system will change. This will force us to take a step back and re-assess what is wrong with the new system. If we had several topics to solve, most probably those topics became obsolete within the new system.

If you read the book: “Toyota Kata” written by author Mike Rother, you will find exactly the same comment. People think that choosing one single topic for improvement would make a company really slow. But in reality, Toyota improved much faster than any other car company. So how is this possible?

The trick was that Toyota did not wait long to analyse if the change had any effect. They did not wait for a next weekly meeting. As soon as they implemented the change, they immediately verified if it caused any impact or not. So my question is: Why not to do the same with our software development process? Why do we wait for the end of a sprint or the end of a project to do a retrospective? If we start to do small retrospectives on a daily basis we are able to understand much better what is an impact of our actions. If we do short and fast retrospectives, the speed of learning is unbelievably fast.

Let me give you an example, yesterday I went for a coffee with a colleague of mine “Marcos Garrido” he told me that few years ago he had a difficult team. That team could not deliver anything for the last two years. He thought how he could help them. He took a drastic approach and he started with the basics of agile. He started with sprints of a day, YES exactly that ONE SINGLE day!!! A working day looked like this: planning around 8:00AM, daily after lunch and Demo and Retrospective before leaving home. Do you know what happened? In 4 weeks, they delivered more value than during two previous years. Marcos received awesome feedback, and the team felt that a speed of learning was something great.

In conclusion, I want to say is: chose one single topic to improve, implement changes, see how the system react to the new changes and if needed, choose a new topic without the need of waiting for next retrospective. Retrospectives are actions that should be triggered on daily basis, we should start analyzing what we do more frequently. I truly believe that all of us just “do stuff” without really thinking what and how we are doing it.

Hope you enjoyed this post.

Please let me know if you have any questions.

Thank you,
Luis

Change one thing at a time!

Posted: October 21, 2013 in Agile, Coaching, Process Improvement, Product Development, Retrospectives, Scrum, Software Development, Team Building, Uncategorized
2

Hi guys, I have been talking a lot about retrospectives during last weeks. Mainly because our project, “Getting Value out of Retrospectives” was built but also because of my active participation in Retrospectives. I collected some insights that I want to share with all of you. Therefore, I want to discuss how many items should be taken in the retrospective to be changed during a next sprint.

During my experience as a Scrum Master and Agile Coach, I experienced that many teams tend to collect a long list of items (that need to be changed) during a retrospective. This is a common mistake spread not only in software industry but also in our society : how many of you have/had a long list of “improvements” on the wall or in some excel sheet? The intention is good, but is this really useful?

Mike Rother refers in his book: “Toyota Kata” that “Whenever we alter any one thing in a process, we create, in effect, a new process with possibly new and different characteristics. This means that once we have implemented one or two items from an action-item list, then the rest of the items on what predefined list may no longer suit the new situation and new priorities at the process”. Taking this into consideration, is it really useful to have a long list of improvements?

There are ways to change several topics at the same time within a system, for example applying Design of Experiments(DoE), where multiple variables are changed at once, but only few people are able to apply this technique. We want to create organizations where everyone is involved with continuous improvement. Applying DoE means that only few people within an organization would be able to participate in continuous improvement efforts and this is not what we want.

Based on previous explanations, I believe a right thing to do is simply take one topic out of retrospectives at a time. Select the topic but make a proper analysis of that same topic. Understand what is a root cause of a problem, you can use techniques such as 5 why’s. After understanding what is the root cause of the problem, you have necessary information to fix the problem during a next sprint.

What do you think about this post?

Was it useful for you?

Let me know.

Thanks,
Luis

Retrospective Smells

Posted: October 16, 2013 in Agile, Coaching, Process Improvement, Product Development, Retrospectives, Scrum, Software Development, Team Building
4

stinkHi guys, last post I wrote about pre requisites for a good retrospective. In this post I will write about the opposite: “Retrospective Smells”, this means that I will mention several things that you should play attention if it happens to you. These are signs that your retrospectives are not being effective. I want to highlight the fact that I did not create this list myself this will be a copy of the book Agile Coaching by Rachel Davies and Liz Sedley but I still think it is worth to share this with all of you.

Ideas fest
The team members are asked to call out ideas without discussing what happened in the last iteration. This does not work because problems are glassed over. Actions may not be connected to resolving problems and tend to be about trying out cool stuff rather than fixing what is not working.

History lessons
This retrospective is rather like an archeological dig that results only in lists of “what went well” and “what needs improvement” but no actions. This can improve communication as the team gradually understands what’s happening. But because there is no discussion about how to improve, change is left to individuals rather than planned into the next iteration.

Change the world
The team commits to an ambitious list of actions without considering wether it has time to get them done in the next iteration. This leads to disappointment because the actions do not get done and the team adds more actions to the list every retrospective.

Wishful thinking
Actions discussed are rather vague with no owners such as “improve communication” or “do more refactoring”. These are not actions; they are problems to work on. without more discussion, the team does not really know what to do to implement these pseudo actions.

No time to improve
The team takes five to ten minutes after their iteration demo to have a quick chat about how things have been going and calls that a retrospective. This is a sign that the team sees no benefit in retrospectives. If individuals do have ideas for improvement, they they face a struggle to implement them without a forum to get support from the team.

Hot air
The team spends the retrospective grumbling about how bad things are without taking responsibility for improve the situation. This may be cathartic and release tension in the team but can easily turn into a blame game. Retrospectives are about making changes for the better, and than cannot happen without some discussion of what the team can do.

These were the topics that Rachel and Liz wrote. I really think they are useful for all of us and that’s why I wrote them here in this blog post.

Hope you think they are useful.

Thanks,
Luis

Retrospectives Pre-Requirements

Posted: October 14, 2013 in Agile, Coaching, Process Improvement, Product Development, Retrospectives, Scrum, Software Development, Team Building
0

checklist-67Hi guys, our project (mine and Ben’s) is almost done, we are finalising last details and this post is one of the last pieces. I will write about: “Retrospectives Pre-Requirements”

Like Rachel Davies and Liz Sedley refer in their book: “Agile Coaching”, retrospectives provide a way to engage with team members in improving their processes in direct response to problems they face. Unfortunately, it is not uncommon to meet teams that have already tried retrospectives and have given up. So where is the problem? To run successful retrospectives there are several items that need to be present and this is the topic we want to tackle.

Norman L. Kerth refers in his book: “Project Retrospectives” five important ideas in order to have a successful retrospective: “The need for the ritual”, “Naming the process”, “Prime directive for a retrospective”, “The darker side of the retrospectives” and the “Retrospective Facilitator”

The need for ritual
Usually humans do not stop to reflect in any project, this is not a natural activity, that’s why it´s so important to formalise a behaviour and make it a ritual. Rituals are important because they serve to bring people together, allowing them to focus on what is important and to acknowledge on significant events or accomplishments. It is extremely important to not use a retrospective to identify only negative parts of a project. In each project there are positive outcomes and these ones should be celebrated like any other small victory.

Everyone that is involved in a project should be involved in a retrospective: a retrospective has a huge potential for learning and it should not be limited to any of a team member. Another reason why everyone should attend is the fact that everyone see issues in different ways. This contribution is extremely important to come up with better approach for the future.

Naming the process
In our industry, retrospectives are named differently. Some of the names are: “postmortem”, “post partum”, “post engagement redress”, etc. In Agile software development this process is called “Retrospective”, nowadays this is a popular name. In my opinion, it is important to name the process in clear way to have everyone’s understanding. Usually a team knows what it means but is not uncommon to have top management that doesn´t understand what is the meaning of it. I guess “Retrospective” is a simple and self explanatory word.

Prime directive for a retrospective
One of the basic ingredients for a retrospective to be successful is a factor “safeness”. People must feel comfortable to share their problems, opinions or concerns. It is common to realise that things were not performed in the best possible way, when this happens people must feel comfortable to say things out loud and suggest different ways to approach the same problem. Norman explains some techniques to create a “safe” environment within teams in his book . Additionally, Norman tells us that before starting a retrospective, we should communicate a prime directive:

“Regardless of what we discover, we must understand and truly

believe that everyone does the best job he or she could,

given what was known at the time, his or her skills and abilities,

the resources available, and the situation at hand.”

I personally used this idea several times and I can guarantee it really works.

“The darker side of retrospectives”
During my life I had opportunities to see several retrospectives to be transformed in complain sessions. It is quite common when a retrospective is not well facilitated. It is important to understand reasons that people complain about and this can reveal lot of problems, but if a complain session goes out of control it can ruin the full retrospective.

People do not do it with a bad intention. They simply exteriorise what is affecting them, they have some needs that are not being fulfilled and they need to symbolise their emotions. The problem is the fact that a receiver is put off by the complain and immediately enters in defensive mode attacking back, this can end up in a non- productive retrospective. If all retrospectives end this way, people start to see retrospectives as useless and they will stop attending them.

One technique that I use is to request people to express themselves in form of “wishes” instead of accusations. This changes the tone of voice creating a “safe” environment, as it was explained above, having a safe environment is one of the most important things for a successful retrospective.

The retrospective facilitator
All previous topics are extremely important, yet if we do not have a good facilitator, a retrospective most likely will be a disaster. To become a good facilitator, an experience, training, and a lot of self study is required. Before starting a retrospective, the facilitator should have a clear idea about what he/she wants to get out of that session. For an experienced facilitator this is more or less easy but junior facilitators require a help from experienced leaders. Each retrospective has different problems to be tackled, a trick is to get right exercises to attempt right problems.

My advice is to start with small projects where people know each other for some time and have already worked together. Another good option is to pair with more experienced facilitator, this gives an opportunity to learn with a mature leader in real time . With time, people can consider larger problems and larger teams. Becoming a good facilitator takes time and effort, do not rush, otherwise an outcome might not be what you want.

This is a topic that I wanted to bring you, hope you like it.

Do you have any comments or ideas for me? Please let me know as this will be part of our book.

Best Regards,
Luis

Target Conditions - A way to move towards your “Company Vision”

Posted: September 23, 2013 in Agile, Coaching, Leadership, Process Improvement, Product Development, Retrospectives, Team Building
0

IMG_0684Hi guys, some weeks ago I spoke about the importance of having a vision for a company, that post can be found here. In this post I will explain a possible way how companies can educate their employees to work towards their “Company Vision”. This blog post is inspired by the book “Toyota Kata” written by Rother. All pictures are taken from the book.

If your company is a small start up, I believe it´s easier to understand what they need to do in order to work towards a company´s vision. But how can you do the same if your company has thousands of stakeholders? This is what we will discuss in this post.

A Vision is something blurry, vague and very distant. The path is unclear and cannot be know in advance. So how do we find and stay on the path? The answer is to create “Target Conditions”.

IMG_0685

Across an organisation, people should work towards a vision using successive target conditions. A target condition typically represents a step closer to the vision and a challenge that is not achievable with a current setup within a company. As Rother wrote in his book: “You can think of a target condition like a much shorter-term desired state that is more clearly defined than the distant vision. ” Likewise the vision, a target condition is not a financial or an accounting target, instead is a description of a condition. When a target condition is reached, another one is created.

When a target condition is defined, it is not optional nor easily changeable. A tutor gives all freedom to a responsible person who figures out “how” to achieve the condition, this is where Toyota is really good: People Empowerment. Humans are good at solving problems and arranging new ways to achieve new levels of performance and that´s why Toyota gives a power to people to come up with their own solutions. The picture below summarises what was discussed in this post. This blog post is a brief introduction, during the next weeks I will continue explaining “target conditions” more into detail .

What do you think about it? Do you think the concept can be useful for your company/organization? These and other topics will be discussed in our MeetUp “Creating High Performing Organizations in Munich” if you want to join us do it here.

Best Regards,

Luis

Older Entries