Product Development
now browsing by category
Coaching focus during Iteration
Hi guys, in my last post I explained a tool that I learned in one of Lyssa´s and Michael´s workshop. This tool is a great guidance for coaches in their coaching sessions. Now I will explain where you coaching focus should be placed. During an iteration, a coach must be aware that sometimes his coaching skills are needed to help both teams as well as individual team members. So let´s see when these different skills are needed…
In the beginning of each iteration, the coach must lead the team as a whole unit. Activities, like an iteration planning, require the coach to fulfill all elements in a group. At this point, there is not much work for individual coaching.
As soon as the iteration begins, team members approach the coach with their specific problems. Here, the coach must give an attention to each of them. At this point, the team coaching is not needed. The further the iteration proceeds, more attention towards individuals is required.
When the iteration reaches its end, team coaching is again desired. Activities, like retrospectives, are fundamental and here the coach must help the team as an whole unit. The coach will immediately address individual concerns together with the team, making the individual coaching almost no existent.
Below you can find a picture I took from Lyssa´s and Michael´s material - Coaching Agile Teams Workshop, that concludes what I wrote. The reason why I conceived this post is to create awareness among agile coaches. Coaches need to be aware that we need different skills for different situations. I believe, to be a good agile coach, we need to master not only the individual coaching but the team coaching as well.
Hope you liked this post.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Arc of the coaching conversation, a tool to help coaches
Hi guys, this blog will be about coaching. I want to bring you a simple tool that I learned in Lyssa´s and Michael´s workshop few months ago. I believe this is a fantastic tool, especially for beginner coaches. It´s a great way for them to learn how to keep a coaching session. The tool is called the “Arc of the coaching conversation” . Below you can see its representation, this picture was taken from Lyssa´s and Michael´s material - Coaching Agile Teams workshop.
A coaching session usually initiates because a coachee needs to take one or several things out of the mind and he/she needs to be heard. The coach must create the environment in order to make the coachee comfortable for a discussion. The most important characteristic for a coach is the listening part. A great coach is a great listener. Try to think about it and do not interrupt the coachee at any point. You will have an urge to interrupt him/her, you will start to think yourself that you know the answer and you don´t want to wait to give it to him/her… Do not do that, instead, let the person release the feelings. You must self-manage yourself.
At some point, you must be sure that you understand exactly the couchee´s problem. Try to use the phrases, such as “If I understood correctly, the problem is…” This will allow you to confirm the problem and give you a better understanding what does truly bother the person. After understanding hiser/h problem, start to explore the topic. At this point you should use powerful questions. Here under “Skills for Agile Coaches/Powerful Questions Resources” you can find several powerful questions that can be used. After some time, using exploration and powerful question, the coachee will find some possible solutions for his/her problem.
It is your job as a coach to help him to narrow down actions. Together you should figure out which approach he/she wants to try first. After that, specifically ask what he/she will do, by when and how will you know what was the result. This will end the coaching session.
I personally think this is a good way to keep a coaching session valuable and I wanted to share this with all of you. Hope you enjoy it and find it useful.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Techniques to make sure that everyone is heard
Hi guys, in this post I want to bring you some techniques that can be used, for example, in retrospectives. Using these exercises will help you to make sure that everyone will be “heard”. Sometimes teams consist of shy members that usually do not express their opinions that much. With the help of these exercises, they can express themselves without going out from their comfort zone. Some of these exercises were already known to me, others I learned with Lyssa and Michael
Consent Check
This exercise is to be used when the facilitator knows that the group is in an agreement or the stakes are low. This exercise will serve to make sure that everyone´s opinion is the same. The facilitator can ask “Does anyone object to ? After this, just confirm that everyone is aligned.
Roman Vote
The facilitator makes a statement, on the count of 3 people hold up their thumbs up,down or sideways. Let the team see each other´s opinions. After that, invite the ones with thumbs down or sideways to talk.
Vote with your feet
This exercise is a bit similar to the one explained here. The facilitator makes a statement: “How successful this iteration was”. People imagine a line on the floor where the left side means: “not successful at all” and the right side means: “a complete success”. People will move themselves according to their opinion. If there is a big difference between opinions, invite people to discuss about it.
Consensus Check
You can use planning poker cards for this exercise, but you have dozens of different options. The facilitator makes a statement and on the count of 3 people will show their cards. Higher the score of the cards, higher they agree with the statement. Lower the score, less they agree with the statement. As in a normal estimation meeting, if the scores are too different, invite people for a discussion.
These are small exercises that can be done in order to help everyone to be listened… Hope it was useful for you.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
What kind of rewards should we use in our organisations?
Hi guys, several weeks ago I brought you a polemic post that generated quite interesting feedback. Based on this post, I would like continue the polemic and bring you when should we use rewards towards employees. This blog is inspired by Daniel´s Pink book - “Drive: The Surprising Truth About What Motivates Us”.
In one of my posts, I explained that goals tend to narrow our focus. This is good only for activities that use the left part of the brain; simple tasks that do not require creativity. But for complex and conceptual taks, giving a specific and measurable objective can blinker the wide-ranging thinking that is necessary to come up with an innovative solution. Based on this, I would like to explain for what kind of rewards should we use the Daniel´s flowchart.
Basically, Daniel refers that we should use “If-Then” rewards when a task is boring, not challenging or when we cannot connect it to a wider purpose. This means, “If you do this, then you get that”. We just need to offer a reason for the task, acknowledge the boring task and allow people to come up with their own solutions to solve it.
When the task is not straightforward and it requires using the right part of our brain, we should impose different type of rewards. First, we should use non tangible rewards such as praise and positive feedback, and then provide useful and positive feedback about their work.
As you can see, most of organisations are doing it completely wrong. What can we all do to help companies to change? I guess its our job as Agile Coachs, Agile practitioners and Agile passionates to do something about it. Give me your thoughts…
If you want to know more about Daniel´s book you can take a look in the video below…
[youtube=http://www.youtube.com/watch?v=u6XAPnuFjJc]
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
How to use crowd sourcing for localization validation/testing
Hi guys, several weeks ago, as some of you already know, me, Vasco and Wim started this project: www.agile-localization.com. During this time we have been taking notes and thinking about several topics that we want to talk tackle in the book. After collecting all topics, we realised that we could write a pocket book in parallel with several “How to´s”. This small pocket book could attract readers that are not interested in a full story of the original book, but instead, they want practical exercises to implement within their teams/products. This is the result. Below I want to share the first “How to” and I would like to get your feedback. Your feedback would be important for me to improve and write a final text.
How to use crowd sourcing for validation/testing
Several years ago one of the authors worked in a big mobile manufacture company as a Localization Manager. He was responsible for localizing several products within the organization. These products were delivered to millions of users all over the world, so the localization quality was extremely important for the company in order to keep a good brand image. Imagine yourself buying a phone and when you start using it you barely can understand the translations. Most probably, you will not get the best image of that company. This was happening not only with customers but also with employees. They were not happy with translation quality delivered by vendors.
In the beginning, the author thought this was normal situation. The problem is that people in the team were too involved with the product and they were familiar with product features, therefore it was easy for them to be unhappy with translations provided by vendors. However, the situation started to be too annoying due to repeating complaints of translations. Everyone started to think that the organization couldn´t afford to ship products with such a poor quality level. Adding more testing would not help much, because based on experience, the author thinks that increasing testing will not improve the linguistic quality that much. So, what would be a possible solution for this?
How about if the company would use crowd sourcing to help the validation of the product? This is exactly what they did, so let´s see how it was done:
1) The author started to take screen shoots of the most important products screens. The screen shots were taken in English in order to compare the English version with the one they would have on their own devices.
2) A survey was created with a question for each different screen shot asking: “Do you agree with the current translation?” a)Yes b) No. If No, please can you provide the correct translation.
3) The survey was spread inside of Beta Community and within the company
4) A script was created to analyse all answers
5) All translations with an acceptance below 95% were written on “Improvement List”
6) An avg translation score was calculated to measure how accurate the translations were for each language
7) For each word on the “Improvement List”, the top three suggestions were collected
8) All words within the “Improved list” and their respective suggestions for improvement were sent to the marketing department in order to select a final translation
9) The changes were implemented into the product
10) The survey ran again
11) All metrics were calculated repeatedly
12) The quality was improved drastically
This is an example how crowd sourcing can help companies to increase a product quality.
What do you think? Do you think its useful or not really? Please leave me your comments :)
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Change Management tool for Agile Coaches
Hi guys, this time I want to share a simple exercise that I learned last week in the Management 3.0 workshop given by Jurgen Appelo and Mads Troels Hansen. I highly recommend this training! At the end of the training you will go back with a bunch of nice exercises that you can apply right next day at your work.
The exercise is called “Moving Motivators”. To do this exercise, you need a set of cards like these ones. The game is simple, you spread the cards on a horizontal row putting the most important values on the left and the least important ones on the right. After that you think about a change that is happening inside of your organisation and you move the cards up or down depending how the change will impact your values. When you finish, you will have a visual picture how the change will impact you and your values. Below you can find an example.
I believe this exercise can be extremely useful to use with anyone within an organisation that is being affected by changes. I imagine this exercise to be used on a daily basis for Agile Coaches. There are several people, especially middle managers, who are strongly affected when a company goes agile (more about this topic can be found here), performing this game with them can reveal their needs and their fears allowing a coach to work together with them to minimize a negative impact on the work.
Was it useful for you? Leave me your comments and suggestions :)
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
What is an Agile Manager
Hi guys, in this post I want to talk about the role of an agile manager. From my experience, middle managers are the ones that suffer more with an agile transition, let me explain what I mean. When agile is introduced at companies, there are typically three “layers” that are affected at the company: development teams, middle management and top management.
Development team is the first to be affected but their daily job do not change much. The way how they work will change radically but their daily tasks will be the same; they continue developing software to customers. I believe that with top management it´s the same. They must understand agile principles and their the implications, but as for development teams, their daily job will be the same. They will be focused on company´s strategy, not changing their daily tasks that much.
With the middle management, a lot of things change. All their daily work life changes and that´s why I believe that middle management is the part of the organisation that suffers the most. They get insecure because the scope of their work changes drastically. Let me give you a couple of examples; At one of the companies where I worked in the past, middle managers owned most of the technical decisions, they were responsible for team members´ assignments. QA managers were responsible to say if the product was good to be shipped or not and many other things typical from old “silos” companies. But, if everything changes, what is the new role of the middle manager? What are his new responsibilities? Let´s take a look…
Organisational Change Artist - he/she should be one of the persons guiding the organisation towards agile.
Boundary Keeper - reinforcing boundaries both within the team and between the team and the rest of the organisation.
Value Maximiser - one of the persons managing the portfolio of projects. He/she is like a product owner, but in a bigger scale, always asking what is the highest business value project in the organisation.
Lean Manager - will use lean thinking to improve organisational flow so that the value that teams deliver can be delivered without delay.
Organisational Impediment Remover - will navigate trough the organisation and remove all the impediments that are blocking teams to deliver value to customers.
Team Champion - will coach agile teams helping them to achieve fantastic results.
The previous definitions were taken from Lyssa Adkins and Michael Spayd workshop: “Coaching Agile Teams Workshop”. I want to add that most of the new roles do not come naturally, and they require a lot of training and education in Agile. However, I believe these are the new roles for agile managers. What do you think?
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Different coaching styles for different levels of Shu Ha Ri
Hi guys, in my last post, I spoke about Shu Ha Ri as a tool for agile Coaches and how it can help them to identify at which level of Shu Ha Ri their teams are. In this blog, I will explain what type of coaching should you apply depending on the level of your team. On the picture below you can see different kind of coaching styles for each different level (the original model can be seen in this post).
Teaching - A the name shows, at this stage you must teach the rules. The teams that are at this level they have a really basic knowledge of agile values/principles/practices. They need to have someone to guide them. Examples from Lyssa Adkins:
“Follow these rules. I have followed them before, and I know they will give you what you want. So, for now, just follow.”
“The rules work. Anything else is an impediment.”
“Everything you could need is right here, in this simple framework, so look here for your answers first.”
“Here is how this works”
Coaching - Is the next step. Here, teams have a good understanding of agile values/principles/practices, they start to interiorise them from their past experiences. They start to understand how they can use different approaches to achieve the same end result. At this stage, teams can come up with their own solutions, they just need a coach to help them finding different ways to achieve what they need. Examples from Lyssa Adkins:
“Why does this way of working work?”
“What kills it? What renews it? What feeds it?”
Advising - The last stage. In this stage, the team has fully internalized the values, principles and practices. Everything runs quite well, the role of the coach works as an advisor. For example:
“May I offer an observation?”
“That could work. Try it”
“I do not know. What do you think?”
One important thing, each successive stage contains the others. For example if a team is in “Ha” but you want to introduce a new practice or idea, remember to use a “teaching” approach because they are new to that practice so they will be in Shu for that idea. This is important because most probably you will be changing coaching styles depending on the practice or idea that you want to feed into the team.
Do you think it will help you?
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Shu Ha Ri a tool for Agile Coaches
Hi guys, this week I want to introduce you an old Japanese martial art concept that describes the stages of learning to mastery - Shuhari. Shuhari is roughly translated to “first learn, then detach, and finally transcend.” I got familiar with this concept during a training I took with Lyssa Adkins. In this post, I want to present this concept applied to agile teams and use it as a tool to help agile coaches to identify in which stage their teams are.
As an agile coach you must understand in which stage your team is in order to help the team to perform in more efficient way. As Lyssa said, if people in a team are in the “Shu” phase they are quite immature in agile and they just follow rules. If they are more mature they will be in the “Ha”, where they can break the rules safely. The last stage is the “Ri” phase where people are so mature that they can create their own rules. Below I will show you some behaviors that help you to see where the team is on the Shu Ha Ri scale. At this point I will quote Lyssa Adkins notes.
Is the team new to agile or to one another? If so, they are at Shu.
Has the team changed or dropped agile practices and lost the intention behind them? Have they mashed up agile with something else so that their practices are not even clear to them? Do they look at you cockeyed when you bring up the agile manifesto? If any of these are true, the team may have progressed to Ha too early. They are truly at Shu and need you to guide them to practice at Shu.
Does the team live by ideals in the agile manifesto? In all they do, do they stand on the side of individuals and interactions, working software, customer collaboration, and responding to change? Do they have the basic practices working well and producing new insights that let them improve each sprint? Do they pause - really pause - to consider the ramifications before they alter, drop, or adda an agile practice? Do they face the consequences of these changes squarely? If these are true, your team is at Ha and needs you to coach them to deeper expression of agile.
Has the team altered their practice of agile and done so consciously, keeping the values and the principles of agile alive? Have they broken through walls of dysfunction in their company so that their practice of agile leads to progressively better and faster delivery and higher satisfaction? Have they imbibed the skills and mind-sets necessary to be truly self-monitoring and self-correcting? If these are true, the team is at Ri and needs you to let them go.
I will explain what kind of coaching styles you should apply to each different stage in my next post. I hope this was useful for you guys.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Typical Product Owner mistakes in the organisations
Hi guys, this week I want to bring a topic about a discussion that I had some time ago with my friend. We talked about how his organization made some mistakes with the Product Owner role. Unfortunately, many organizations do not understand this new role (Product Owner), they think that a typical product manager with the title of Product Owner (PO) will do the job without any necessity to change. So let´s see what are some of the common mistakes that organizations do with the Product Owner role.
Based on my experience, the most common mistake is the lack of presence of the PO. With globalization, it is quite common to find scrum teams that are not collocated with this role. If the organization is not careful, it is really easy to have a product owner that is not there for the team when they need him, specially if he/she does not work in the same time zone as the team.
Sometimes, the reason why the PO is not collocated with the team is, because they belong to other organization. I experienced the same thing. In this case, the PO splits his/her responsibilities between the organization and the team that is developing a product. This is what makes him/her the partial product owner. There are various reasons why this happens but one common is, because of the skills of the PO in the area that is being developed. Companies should play attention to this and avoid such mistake.
On the other hand, there are Product Owners who are completely overloaded with work: the overworked Product Owner. A product owner should not have more than two teams, of course, this is a general rule and it might be possible to have more, but if he/she has more than that, it can be difficult to give full support to the teams.
In order to solve the previous problems, companies sometimes create another problem: The proxy Product Owner. This person acts as a placeholder of the actual product owner. This can lead to decisions´ delay or even conflicts. An author of “Agile Product Management with Scrum”, Roman Pichler, refers to a case where the PO was too busy to take the role, therefore a company got a proxy PO. At the end, there were various conflicts because the proxy PO was not empowered to make decisions and all decisions were supposed be made by the official PO who was never available.
On the same line as the proxy Product Owner the underpowered Product Owner is a quite common mistake. Everyone who is responsible for something but does not have the power to decide anything, probably know what I am talking about. Organizations should empower Product Owners in order to take any decisions to develop the product. If this does not happen, it´s a great recipe for the failure.
The last mistake is the product owner community. This happens to companies that create a committee to be responsible for a product. When there is no responsible person for the product, it can lead to decision´s delays. Often, most of the people involved want to reach an agreement between all parties and this will lead to lengthy meetings without any proper outcome. This is a typical case of “too many chefs in the same kitchen”.
This blog was inspired by the book Agile Product Management with Scrum.
What do you think? Any more ideas?
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
D5 Creation