Coaching
now browsing by category
Why do we lose time with root causes analysis in Retrospectives?
http://www.flickr.com/photos/erikveland/
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.
Do retrospectives more often!!!
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.
Change one thing at a time!
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 why we should only change one thing at a time during the iteration.
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?
Retrospective Smells
http://www.flickr.com/photos/brian-fitzgerald/
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.
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.
Target Conditions - A way to move towards your “Company Vision”
Hi 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”.
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.
Coaching Dojo
Hi guys, some weeks ago I discussed the “Coding Dojo” topic, the post can be found here. This week I want to explain how you can apply the same concept to coaching. This is something that I have been thinking of organizing in Munich.
A coaching dojo is an activity where coaches gather together to practice their coaching skills. These sessions are a great way for coaches to improve their skills. It´s an opportunity for them to apply the “Arc of coaching” or to be aware aboutwhat are their thoughts while coaching.
Everything starts with a pre-selection of a problem selected by a coachee. The dojo runs with two people working in a pair in front of an audience, one of the persons acts as coachee, the other as a coach. The coach tries to help the coachee with a problem. The topic should be professional topic, here you can find the reason why you should not take chose a personal topic. During this time the audience observes how the pair is conducting the coaching session.
A session takes between ten to fifteen minutes, after that the audience is invited to provide feedback about how the coaching was conducted. When the session is over, a person from the audience switches with one of the pairs. The remaining person changes the role in order to be a coach and a coachee. For the first session you might want to keep the same pair and ask them to change positions after the session in order to enable both persons to try different roles. This will allow everyone in the room to participate in this activity.
I believe this is a great way to help coaches to practice outside of their professional environment.
Becoming a high performing team
Hi guys, some time ago I discussed how important it is for a company to have a vision, here you can find more about it. In this post I would like to discuss about the same topic but on a team level.
Currently I work as a Coach for teams that are performing really well and they are delivering a great business value, yet I think we could do better. I have been thinking in several ways how to help them to a next step and how can I help them as a coach to make this happen…
This post covers examples of what I want to try with teams and I would like to get your opinion on this topic. These team members know what they need to do as a team which sounds great, but as a coach, I believe I can help them to achieve more… I feel they the team doesn´t have a vision nor a purpose, they do their daily job without knowing where they want/should go. My job is to help them to become a high performing team. What I want to try has three parts:
1) Set the Product Vision
In my humble opinion, the first thing that we must ensure in order to have a successful team is to establish a common goal for all team members. In my case, I am referring to a development team, therefore I believe the common goal is to deliver a high quality product to a customer. In this situation, a Product Owner has a key role as a master of the product vision and a responsibility for sharing that vision as well as making sure that everyone understands how product should be built. I am going a bit further by saying that the Product Owner is ultimately responsible for creating the common goal for the team.
“Vision without action is just a dream.
Action without vision just passes the time.
Vision with action can change the world.”
by Joel A. Barker
A possible exercise would be to ask the Product Owner to prepare a press release and then to present it to the team. With this exercise, the team will be able to see a big picture and understand WHY they should work in the team and WHAT they need to accomplish as a team, but be careful PO should not define HOW the team should work, that is team’s reponsability. In my opinion, this exercise is important because of two reasons: on the one hand, if everyone in the team knows what they need to do, the exercise is reaffirming the common goal, while on the other, if the team members do not have a clear idea what their common goal is, having this exercise will help them to create the necessary common goal.
2) Help a team to define their definition of awesomeness
It´s extremely important to help the team to find their own definition of awesomeness, help them to create a “dream team”. To do that start a brainstorming session asking everyone what is the meaning of “awesomeness”. If they think about an “awesome team” what that represents for them… You might want to break the topic into smaller pieces, for example:
- Technical awesomeness: Being able to release in every check in, 100% test coverage, 0% manual testing, ATTD Gurus, etc.
- People awesomeness: The best group of individuals in the world, the team that have more fun, the team that helps each other at every moment of the day, etc.
- Innovativeness awesomeness: The most innovative team in the world, the team always come up with new cool ideas, etc.
There are more other examples, I´m sure you will have plenty of ideas. Be DEMANDING with yourself.
After this exercise, you will have plenty of ideas about what an awesomeness team means. Help the team to create their final version of their “Awesome Team”.
3) Help a team to select their values
I believe everyone acts based on their values, therefore defining team values is an extremely important activity. This is a powerful exercise that brings people together. Defining values is a way to select a behaviour of people in some circumstances. For example, if you define a humour as one of your values (one of my previous teams did it) it means they want have fun during working time. Every time things were getting boring they referred to this value reminding them that something was missing and they would have needed to do something about it in order to bring some fun into a daily work. This is just a small example, you can come up with thousands more.
In my opinion, if your team is a Scrum team you should remember Scrum Values:
Focus: Because we focus on few things at a time, we work together well and produce excellent work. We deliver valuable items faster.
Courage: Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
Openness: As we work together, we practice expressing how we’re doing and what’s in our way. We learn that it is good to express concerns so that they can be addressed.
Commitment: Because we have great control over our own destiny, we become more committed to success.
Respect: As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.
The team does not need to adopt Scrum values but adopting and referring to them frequently helps to improve a scrum team. On top of these values I would select two or three more to help the team to create their own identity. Here you can find a big list of values to serve as input.
Go and Try it
I am thinking of doing this with several of my teams. I do not know what an outcome will be but I am quite excited to see how they will react. What do you think about it? Any cool ideas to help here?
Enable Pair Programming Rotation
Hi guys, few weeks ago I wrote a couple of blogs about pair programming: “Intro Pair Programming” and “Ping Pong programming“, I believe these techniques are extremely useful to share a knowledge within a team.
This week I will explain how you can enable Pair Programming rotation. This idea was taken from the book Agile Coaching from Rachel Davies and Liz Sedley as well as the picture below. I believe pair programming is not enough, we need to enable pairs to change within a team, otherwise we will end up in a situation where only some pairs know a part of a product.
A trick is to work with the team to design a “big visible chart” to increase a visibility of what they want to track; in this case partners with whom they paired. This makes it easy for the team to see whether they are improving or not.
In this case team can use a pairing ladder to show who is paired with who and how often. Below you can find an example of this pairing ladder.
This was a short post to give you some ideas how can you enable/track pair rotation within your team.
Hope it´s useful.
Show me the direction, I will find the way!!!
Hi guys, lately I have talked a lot with some of my friends from various companies and industries, and I have found a common trait: People spend too much time in fire fighting mode!!! I have been thinking about this topic, and I guess this is time for me to express my ideas and get your feedback.
I believe there are several reasons that force people to spend most of their energy on fight firing mode. Nevertheless, the one that I believe is one of the most important one causing the biggest problem, is the absence of a strong vision. People must feel connected to something bigger, greater, something that makes sense to them but this is not enough… They must know what is an ultimate vision, otherwise they will be lost within their daily activities.
So what can we do in order to improve this situation?
Define Vision:
First, we must define a simple vision/mission. Something that is so simple that even a 6 year old kid can understand. Let´s take a look into Toyota’s example: “Produce cars using a process that is 100% efficient without any waste”. Simple but powerful.The company knows that this vision is impossible to reach but keeping this vision in mind allows all employees to follow a direction. Employees know that their job is to improve the process continuously until they reach 100% efficiency, this will never happen, yet it´s a good way to keep a continuous improvement culture.
Give Small steps towards the Vision:
In the book “Drive” written by Daniel Pink, the author refers that SMART goals might have a negative impact on people’s performance. When we create SMART goals, human brain tends to do just what is necessary to reach that goal. Most of the time we could achieve much better results, but because the goal states a “Specific” part, we put just enough effort to reach that part, not doing any effort to go further. If you want to know more about this topic check my previous blog here. A second trap from SMART goals is the fact that often these goals are imposed by a management, instead of being created by people who perform a job without creating an ownership feeling.
Because of previous reasons, I believe Toyota´s approach is more adequate. Toyota uses a different approach: “Target Conditions”. These conditions are small increments that are defined by employees in order to pursue a big vision. These are not goals imposed by managers, these are experiments created by employees. Since the approach was created by them and not imposed by someone else, they will have a stronger ownership feeling allowing them to perform better. When a current target condition is achieved, they will create a new target condition to pursue a big vision. This is a fantastic way allowing people to work on their own solutions. Many people are extremely smart, they do not need to have managers telling them what to do, they just need to have someone showing the direction. “Show me the direction, I will find the way!”.
Conclusion:
Naturally, this is not enough to change a company or an organization, but with a help of this post I hope to create an awareness of the topic. When people do not have a vision and do not perform small steps towards that vision, I believe, that it will be extremely difficult to go out from the fire fight mode within a company. I am looking for volunteers that are able to try my ideas in their own companies. I would love to know if you are able to implement a bit of this idea at your company :) If not at your organization, maybe in a department where you work.
What do you think guys? I would love to hear more from you.
D5 Creation