Archive for March, 2013

Techniques to make sure that everyone is heard

Posted: March 28, 2013 in Agile, Product Development, Retrospectives, Scrum, Software Development, Team Building
0

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.

Cheers,
Luis

What kind of rewards should we use in our organisations?

Posted: March 26, 2013 in Agile, Day by Day life, Product Development, Retrospectives, Scrum, Team Building
2

reward1Hi 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…

Thanks,
Luis

How to use crowd sourcing for localization validation/testing

Posted: March 22, 2013 in Localization, Product Development, Software Development
1

crowdsourcing-relay Hi guys, several weeks ago, as some of you already know, me, Vasco and Wim started this project: http://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 organisation. 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
Thanks,
Luis

Change Management tool for Agile Coaches

Posted: March 21, 2013 in Agile, Product Development, Retrospectives, Scrum, Software Development, Team Building
7

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

Thanks,
Luis

The most efficient way to interview a candidate for a Scrum Master/Agile Coach position - Part II

Posted: March 20, 2013 in Day by Day life, Scrum, Software Development
2

Hi guys, in my last post I wrote about a great experience that I had when I was interviewed for an Agile Coach position. In this blog, I will write about a second experience that I had, I believe both of them are great ways to get good candidates on board. Let´s take a look at it…

First thing that impressed me when I arrived at the company´s office were friendly and super polite people. I felt we´ve known each other since ages. This is extremely important for a candidate that is nervous and not familiar with the environment around him/her. For me its strange, but there are still plenty of companies that don´t play much attention to this.

After a warm reception, a hiring manager gave me a tour around the office; this was extremely important because I could start to understand they had something that was crucial for me. For example, they had several beautiful salty fish aquariums that created a fantastic environment where I would be more than happy to work. But what really created the “wow” effect, was the amount of information radiators they had all over the places at the office. That gave me a pretty good idea about their “agile maturity”. That means, if something went wrong with the product, everyone could immediately see that something was broken.
After the tour, I was invited to go for a lunch with the team; that was a fantastic way to get to know each other.

The hiring committee took an opportunity to check my CV, my twitter account and my blog before meeting me. This allow them to “bomber” me with questions about my professional life. Based on this, they could get a much better understanding of my skills. Afterwards, they shared several challenges with me and asked me how I could help them to solve those. This is a great way for the team to evaluate my knowledge and for me to see how mature they are.

After many interesting discussions over the lunch, I was invited to participate in their Iteration Planning. Observing what kind of tasks they would need to do, gave me a fantastic opportunity to see what was their level of “agile maturity”. I believe, this exercise is more useful for a candidate than for at team itself. However, the candidate can always give some opinions and share past work experiences, allowing the team to evaluate his/her experience at these kinds of activities.

The previous activity (Iteration Planning) was followed by a series of interviews with top management. This job had both responsibilities - coaching the team and the organisation. The understanding what top management expected from me was crucial. I used this exercise to explain what I would like to do inside of the organisation and to ask them about a possible list of things that we could implement in the future. This exercise was fantastic because it allow us to align our expectations. After this, my interview day came to an end and I left the company with a really great feeling.

This blog is not devoted to techniqual things much like in my last post blog Instead, I mention several activities that can be done with a candidate in order to know an applicant better and allow him/her to know your company´s practises better. I hope you enjoyed this reading.

Thanks,
Luis

The most efficient way to interview a candidate for a Scrum Master/Agile Coach position - Part I

Posted: March 13, 2013 in Day by Day life, Scrum, Software Development
11

jobinterviewnote Hi guys, in the next two blogs I will not talk much about Agile nor software development but instead I will talk about two fantastic experiences that I had couple of weeks ago. I am talking about two interviews that I had for a position of an Agile Coach. This is the topic for the next two blogs, how to design a fantastic interview for an Agile Coach/Scrum Master position.

During all my life I haven´t experienced such an interesting interview like the one I had couple of weeks ago. Usually, interviews have the same content: “What is your best quality”, “What is your worse quality”, “What would you do if tomorrow you would become the CTO”, “What would you do if you won the lottery”, “Where do you see yourself in x years”, etc. I believe most of you will agree with me, this is by far not the best way to figure out whether we are good professionals or not. There are other good ways to figure out it. Let´s take a look at it…

First thing that impressed me was the fact that a hiring manager made a quite nice background information check; she went through my blog and book, something that I never saw before. This is quite interesting since you can obtain lot of information about a candidate just reading his/her blog, but unfortunately not so many companies do this. At this moment, I was already quite happy because I saw they were really interested about my knowledge. Now the best part comes…

After asking me some general questions they told me that we would be doing some role playing. I was: “Wow, this is cool”. At that moment I did not realize how powerful this technique is, but later on I understood how effective it is. Is there any better way to know and understand a candidate than through a simulation of a real situation? Typical questions can be prepared but if you recreate real situations live in the interview, an applicant will demonstrate his real knowledge. For a question of principles I will not mention what they asked but I will leave you some good examples to use in the future in your own company. Below you can find some examples of questions.

“Imagine that I am a developer I am completely lost and I do not know what to do or say, and I will ask: “Hey can you please tell me what to do? I am quite lost and i need some orientation”. This is a typical question where you can analyze whether the candidate is a typical command and control type of a person. If the person kind of dictates what a developer should do then you have a command and control person, if the candidate advises the developer to look for help from inside of a team, he is trying to create a self empowered team.

“Imagine that I am a developer and I like to come to the office in the morning, put my headphones to not be disturbed at all, what would you do to convince the person to try Agile/Scrum?” You can, for example, ask a person if he/she likes to fix bugs. If not, then you have a good reason to convince him to try agile, since agile done in a proper way drastically the quality of the code drastically.

“Imagine that I am a developer and SCRUM is something completely new. I do not want to try it because I am afraid of failing, and I believe my boss will accuse me of failing. What would you answer?” You can refer that you will pair with his/her line manager to make sure that he will not be blamed.

“Imagine that I am a developer and SCRUM is something completely new, how can I learn faster?” You can for example suggest a person to pair with another more senior guy to reduce the learning curve.

There are many other questions that you can use using for example Product Owner Role, Line Manager, Top managers and many more. However, the main point of this blog is to emphasize different ways of doing interviews. When you interview a candidate, try to recreate real situations. I think you will have a much better understanding of the applicant.

At the end of the interview I had a huge smile on my face. I felt so good and it was a fantastic experience. I learned a lot within those two hours that I spent with nice professionals.

Do you think this is useful for you? Will you use anything like this on the next interview that you will conduct? Next post I will speak about the second interview that I had.

Thanks,
Luis

What is an Agile Manager

Posted: March 11, 2013 in Agile, Product Development, Retrospectives, Scrum, Software Development
8

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?

Thanks,
Luis

Different coaching styles for different levels of Shu Ha Ri

Posted: March 6, 2013 in Agile, Product Development, Retrospectives, Scrum, Software Development, Team Building
8

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?

Cheers,
Luis

Shu Ha Ri a tool for Agile Coaches

Posted: March 4, 2013 in Agile, Product Development, Retrospectives, Scrum, Software Development, Team Building
6

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.

Thanks,
Luis