Archive for January, 2013

How to help a team that is not performing so well - Part II

Posted: January 30, 2013 in Agile, Retrospectives, Scrum, Software Development, Team Building
0

In my previous post I talked about how to create a common goal for your team and I mentioned a book that I read some weeks ago(The five dysfunctions of a team). This book discusses why even most successful teams struggle to get good results. By following the link below you can find the pyramid of dysfunctions discussed in the book.

Presenting this pyramid to the team could be the second exercise. Based on my experience, most of the team members will identify at least one problem from the pyramid. Visualizing this will make them think a bit about the status quo situation while realizing that much is required to be done in order to have a great team. I think one hour should be enough to familiarise the team with the pyramid and to answer all their questions.

Since the base of the pyramid forms Absence of Trust, I will focus on an exercise for improving this specific aspect. My team tried this exercise some weeks ago. Clearly, we had problems in the team and lack of trust was one of them. To improve the situation, the facilitator of the meeting came up with an exercise for the team: “The Appreciation Exercise”. The point of the exercise is in answering the five questions presented in the following picture:

Importantly, in order to answer the fourth question the team should express their request as a wish. This was an awesome opportunity to use NVC. Although seemingly a really simple exercise, it makes a difference: the participants will connect with the feelings, emotions and wishes. But make sure you reserve half a day for this exercise, you would want to spend a good amount of time on it.

It is too early to say if the exercise really worked, but one thing is for sure - the spirit of the team after the exercise was quite high and all of us were really pleased with the outcome. I am sure that everyone left the room eager to improve the existing situation. It is important to realize that it takes time to see the results of this exercise, because these issues cannot be solved in a day or two, but they are certainly useful for bringing the team together.

After the “Appreciation exercise” it might be the right time to refresh the Agile/Scrum values, but this is a topic for my next post.

Thank you and see you in my next post,

Luis

How to help a team that is not performing so well - Part I

Posted: January 28, 2013 in Agile, Retrospectives, Scrum, Software Development, Team Building
1

Hi guys, I am sure that most of you at some point have had performance issues in your teams as well as team spirit issues. This post will be part of a series of posts where I want to talk about how to help a team to get back on track. For this series I will have a development team (Scrum Team) in mind, but this idea can be applied to any dysfunctional team. The ideas used in this post came from different sources: my own experience and the experience of my team, as well as from a course given by Lyssa Adkins and Michael Spayd that I took some weeks ago.

An important aspect that Lyssa and Michael emphasized at the course was that when you have a problem caused by the poor implementation of Agile you should address it directly, the Agile values should be reaffirmed and the system should be revealed to himself.

The problems should be addressed “directly”: you should state the problem as you see it and then ask the team what they want to do about it. “Reaffirmation of Agile” means you should retrain some of the Agile values or principles that are not present anymore. “Showing the system to himself” means showing the system to the people involved through observation of what is going on, one good exercise to achieve this can be found HERE.

I wanted to give you some background information because I believe that it will be extremely difficult to tackle a problem using any kind of activity if your team does not see that problem and, most importantly, if they are not interested in solving it. With the assumption that people will try to solve the issues, I present below activities that can be seen as a possible way to restore the energy and good practices in the team. These exercises can be used in a two-day team building exercise.

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 members of the team. In my case I am talking about a development team, so I believe the common goal is to deliver a high quality product to the customer. In this situation the Product Owner has a key role as the master of the product vision and the responsible for sharing that vision as well as for making sure that everyone understands what product should be built. I am going a bit further by saying that the Product Owner is the ultimate responsible for creating the common goal for the team.

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 the big picture and understand WHY they should work in a team and WHAT they need to accomplish as a team. In my opinion, this exercise is important for 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. The exercise should take 2 hours, which should be enough for the Product Owner to explain the vision and to answer any possible questions.

Hopefully, with the above exercise the team will have a common goal and can move towards the next step. Some weeks ago I read a book called The five dysfunctions of a team . The second exercise is based on this book, but this is something that I will explain in my next post.

Hope to see you soon in my next blog,
Luis

Constellation - A Good Exercise to “Set the Stage” At Your Retrospectives

Posted: January 23, 2013 in Agile, Product Development, Retrospectives, Scrum, Software Development, Team Building
25

Hi guys, this week I offer you a small exercise that can be used at your retrospectives, specifically, in the “Set the stage” part. There are many different exercises out there that can be used to start a retrospective, but I particularly like this one. I learned it a few months ago in Lyssa Adkin’s workshop in Stockholm (Agile Coaching Teams).This is a great exercise for people who do not like or do not feel comfortable sharing openly their opinion/feelings, at least in the beginning of the project when they still do not completely trust everyone.

We begin a retrospective with a welcome to the team members and with setting an affirmative goal for the session and this is where the “Constellation” exercise can be used. Like I have already said, due to the cultural backgrounds or the personality of team members, answering some questions can be difficult for some, but this exercise can help, because people do not need to speak in order to answer questions. He-he, now you might start wondering, “How could it be possible to answer questions in a team meeting without speaking”? Here is how we can do that…

Start with making an open space, move tables and chairs around, if needed. Put an object on the floor and explain to the team that this object is the center of the Universe and kindly ask them to form a circle around it. Explain to them that you will read some statements, and while you are reading the statements you would like them to move closer to or farther away from the “Universe” depending on how true the statement is in regards to them. So, if they really agree with the statement they should move as close as possible to the “center of the Universe”; if they do not agree with the statement, they should step back away from the center. Once you read a question, let the team observe the “system”, as Lyssa said, “Let the system reveal itself”.

You can use any topic you wish for this exercise, e.g., “How mature is our continuous integration process?”, “How mature is our automated testing process?”, etc. Just choose a topic and ask several questions related to that topic and let them see where they stand. Like I said, they do not need to give verbal answers at all, they answer with the movements by showing their position in the “system”. You could do several questions until you feel a good vibe from the team. To benefit fully from this exercise, you could ask the team in the end: “Where were you surprised with the shape?” and let them talk to each other a bit.

As a next step, you can, for example, ask the guys to form small groups of no more than three people each and ask each group to write down what they think would be the most important issue to improve. Of these issues you could then routinely select the most urgent issues to be improved in the next iteration. After that just agree with the team who will be responsible for what and close the retrospective.

So what do you think about this? It was useful? Leave me your comments.

Thanks guys,
Luis

Long -Term Relationship Is Something Recruiters/Headhunters Do Not Understand!!!

Posted: January 21, 2013 in Day by Day life
0

Hi guys, this week I bring to your attention a completely different topic… it has nothing to do with software development, it is more related to human behaviour, specifically – it is about headhunters. In the past years I have been seriously investing into my professional growth. Subsequently, I did not escape headhunters’ attention, as it seems. Practically every week so far I have been getting more and more various contract offers, but to be honest, I am getting fed up with the incompetency of the majority of these people. Let me elaborate on that…

Like I have already mentioned above, during the past few years I have been investing quite a lot of time and money into my professional development, only on books I have spent a fortune last year, and I do not even want to mention conferences and training. And it does not end here, during the next months I am planning to invest even more into my training. Are you wondering why I do this? Simply because I have a thirst for knowledge and learning and I am keen on learning ever more . I want to excel with my knowledge!

Those of you who have been in the industry for some years already know that, unfortunately, not everyone is eager to spend the time and money on books and expensive training. So, shouldn’t people be rewarded for putting much effort into their professional growth and get paid salary above the industry average? It seems, though, not everyone thinks so…

Let’s, however, start from the beginning… It looks like most of the time when headhunters contact us they do not even bother to check properly our profiles… They, probably, make a search with just some keywords to get a list of names, and then hit the “Send” button to send messages to those people on the list. They only call us when we change our contact info. Don’t you think they could get answers to the basic checklist questions about us by just looking through our LinkedIn profiles - the very place where they find us? But it looks like they do not even bother doing that. Instead of using the time on the phone to discuss a project on offer, they ask us questions they could get answers to if they only could bother reading our LinkedIn profiles.

Having covered on the phone the boring checklist, they finally get to the question about our rates. As I have already mentioned, once investing so much into the professional growth, you expect a reward for that, don’t you? I do not consider myself an average specialist, I think I am a good professional and I am valued in my company. But when I mention my salary expectations, the reply I get from headhunters is that I ask above the average pay, to which my answer is that I do not consider myself an average specialist, if they want an average worker, they can find dozens of them on the market, but if they want someone above the average - they can count on me. If the communication is via emails ninety nine per cent of the times they do not even bother to reply back after that, which I find quite unwise.

Here is where I think they underestimate long-term relationships: they seem to be working on separate assignments – from case to case and they don’t look beyond one separate task… Though, I am convinced that every now and then they get customers who request highly knowledgeable professionals, beyond the average, no matter the cost. Pooling resources by staying in touch with those professionals beyond the average would, most probably, help them get the needed resources - when needed… Moreover, as we all network, by maintaining good relationships with us they could even get help from us in finding the right candidate through our networks. However, they seem to be overlooking such potential.

I do not like generalizing and, I must admit, I have come across fantastic headunters/recruiters that do wonderful work, but, unfortunately, it looks like they are mere exceptions to the mainstream of headhunters.

I would appreciate your opinion here… Do you agree with me, or have I just had bad luck most of the times?

Thank you so much,
Luis

How large stories can impact learning

Posted: January 16, 2013 in Agile, Process Improvement, Product Development, Retrospectives, Scrum, Software Development, Team Building
5

Hi guys, this week I got inspiration for the post from a conversation that I had with one of my colleagues. I was explaining him the book that I read during my holidays - “Drive“. We went through many topics, but the one we discussed most was about Casual Friday, let me explain what it is.

In case you are not familiar with the term, you can think of it as a relaxed work day, the day when people are already in anticipation of the forthcoming weekend . In the context of our discussion this pertained to that specific time that Google made popular with its employees: when they can use their time to do whatever they want, of course, within the company activities, but not necessarily related to their on-going projects.

The conversation continued for some time when he suddenly said that he cannot really do that, he does not have time to try this Casual Friday. He then explained that each their iteration takes two weeks, so if he starts using a day per week off the project they will have only eight days left and then they cannot deliver much for that iteration. At first, I could not understand him, so I decided to dig into it…

I asked him, “How come you cannot deliver anything in eight days? How long do you take to finish a story?” However, when he told me that each story usually takes six to seven days, I understood their problem. Of course, if they take seven days to deliver a story and if something happens, say a small delay, it would easily take them the whole iteration to deliver that one story, but they will not have any time for Casual Fridays.

In my humble opinion, they are just accepting too large stories. It would make sense for them to break these large stories into smaller units so that they could have more deliverables at the end of the iteration. Then I suggested that he tries an experiment: they could start creating smaller stories, say two-day stories, and they could see how many stories they would accomplish within the iteration. If everything goes well, they could deliver up to four stories per iteration and still have their Casual Friday.

I cannot promise that this would immediately solve their problems and allow them to have their Casual Friday, but I think they might be one step closer to it, because I truly believe that smaller stories are much better than the large ones.

This was just one example that demonstrated how large stories can have a negative impact on the development work. Here you can find more examples that explain why smaller stories are better for your development process.

What is your opinion about it?

Thanks,
Luis

Goals trap!!! Be careful when your boss establish performance goals…

Posted: January 14, 2013 in Product Development, Team Building
15

Hi guys, 2013 is here now, so first of all, I would like to take this opportunity to wish you all a successful New Year! I hope you had a relaxing time with your families and friends. During my Christmas holidays I read a great book - “Drive”. It made me think about what really motivates us. Part of the book talks about goal setting, which I think is a perfect topic for my first post in 2013. As it is the beginning of the year, I am pretty sure that soon most of us will have this “popular” meeting with the management to define our goals for the next six months. But is this really a good thing? Let’s dig a bit more into it…

How many of you heard that goals must be SMART? Do you actually think it is a good definition for goals? SMART stands for Specific, Measurable, Achievable, Realistic and Time-scaled. An example of a Specific goal for a company could be increasing the market share, as compared to a rather general goal of becoming more profitable. In order to see if an objective was achieved, we must make it Measurable by attaching a number to it, for example, to increase the market share by 3%. Objectives must be Achievable, which means that the company capabilities and the market environment should allow them to come true. Realistic means that objectives must be within the company’s reach, to expect an employee to become next Freddy Mercury might be a bit too ambitious . The last one, Time-scaled, means that an objective must be attached to a time-frame, for example, in 12 months you will sit down with your boss again and see if you reached your targets. Are you familiar with this definition? Do you agree with this approach? Let’s see what some studies proved regarding this topic.

According to the studies discussed in the “Drive”, goals tend to narrow our focus. This does not sound too bad, right? After all, it is good to be focused in order to stay concentrated on a specific task and not get distracted by secondary aspects. However, in reality this is good only for activities that use the left part of the brain, i.e. for simple tasks that do not require creativity. But, as Daniel warns in his book, for complex and conceptual tasks giving a specific and measurable objective can blinker the wide-ranging thinking that is necessary to come up with an innovative solution. For example, if someone has a target to increase the revenue by 5%, they will draw a plan to achieve a 5% growth and no more. Consider that if they did not have that specific growth number, most probably they would think of many different ways of achieving growth, and most probably they would increase the revenue by more than 5%.

Another problem with specific and measurable goals, in my opinion, is that reaching them becomes the only thing that matters. Some people would prefer shortcuts to get there, even if it means making ethical compromises. On a larger scale, this may cause systematic problems for the organization: unethical behavior, increased risk taking, cooperation between the teams may deteriorate because it is not that unusual that the teams get conflicting goals that might be the source of inter team tension, and last but not least, general motivation might decline.

“Give a manager a target and he will do everything to achieve it. Even if he has to destroy the company in the process” by W. Edwards Deming

Personal goals that people set for achieving mastery are usually healthy. But goals imposed by others, such as sales targets, quarterly returns, standardized test scores, etc. can, at times, have detrimental side effects. Therefore, you must be careful when you set goals in your organization. Please, do not take me wrong, I believe we must have a direction, a company goal, in order to know where we are heading. But I really am skeptical about the SMART model. What do you think about this model? Let me know your opinion

Thanks,
Luis