Team Building
now browsing by category
Using VSM(Value Stream Mapping) as data gathering for restrospectives
Hi guys, in this post I wrote how can we use Value Stream Mapping as a tool to help with system thinking. Many people asked me if I could explain better what Value Stream Mapping is. Therefore, in this blog, I will give a short introduction about it and I will explain how you can use it as a gathering data for your retrospective.
Although value stream mapping is often associated with manufacturing, it is also used in logistics and supply chain, service related industries, healthcare, software development, product development, and administrative and office processes. Value stream mapping is a lean manufacturing technique used to analyze and design the flow of materials and information required to bring a product or service to a consumer. At Toyota, where the technique originated, it is known as “material and information flow mapping”. It can be applied to nearly any value chain. But how can you use this in your team?
The easiest way to do this is to grab some flip-chart papers and tape them on the wall, then divide the space in equal intervals, each interval represents a day of the iteration. Draw a line on the Y axis, this line should be on the position Y=0. If they are doing any activity that will bring value to the customer, tell to each member to draw a line on top of the Y axis line. On the other hand,draw a line under the Y axis line, if they are waiting or blocked by something. They need to do this activity everyday in order to to track all different activities inside the team. Do not forget to write notes when people are blocked or in IDLE; these notes are important to be discussed in the retrospective. The possible result can be something as the picture above seen above.
I guarantee you that you will have plenty of data for your retrospective at the end of the iteration. I tried this couple of times and I was surprised how many issues we find out, how many dependencies and blockers we had and so on. Having this information available will help the team to decide how and where they can improve.
P.S. On the picture, you can see different member roles. I know the setup is not perfect but it was what we could do at that time :) So, if you want to comment on the blog, try to ignore “non- optimal team setup”, instead focus on the activity.
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
Levels of Agile Coaching
Hi guys, this post will be short and simple and it will be focused on the different levels of Agile Coaching. Lately many people have asked me what are the differences within Agile Coaching. For this explanation I want to use a bit of what Lyssa Adkins explained in her workshop “Coaching Agile Teams”.
In her view there are three levels of Agile Coachs. Team facilitator, he is responsible to facilitate practices and collaboration on one team. Agile Coach, this level is responsible to develop teams, mentor others and advise managers. And for last Enterprise Coach, this role is responsible to develop leaders, focuses on culture and catalyses change. Below you can see a graphic how these levels are related to each other.
Team Facilitator
This person focuses on one (or two) teams that are already “up and running”. They are developing basic skills in facilitation, mentoring or training, as well as conscious communication. A team facilitator is not yet ready for Agile adoption or transformation initiatives.
Agile Coach
This person focuses on developing teams, other Agile Coaches & Team facilitators to use Agile well, including the ecosystem around the team. He is an expert in Lean-Agile practices and has chosen a knowledge domain focus (Technical expertise, business or organisational change). He possesses significant facilitation skills, some professional coaching skills, and is adept at mentoring and/or teach.
Enterprise Coach
This person focuses on developing the organisation´s capacity to use agile as a strategic business asset, including culture change, leadership development, and work at all organisation levels.
Like I said this blog was based in Lyssa´s workshop that I do recommend to everyone.
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
Value Stream Mapping a tool to help Systems Thinking
Hi guys, in this post I want to share with you a nice story that happened several months ago with one of my teams. At that time I had a team that was making the first steps towards Agile. They were a fantastic team, really eager to learn but still with the “old waterfall” mentality. They had a typical approach where the developers did development work and the testers – testing, not really a truly Agile team. I believe this is a common problem for teams that are switching to Agile: seeing only a small picture, they are not able to see the entire system. I believe they lacked “System Thinking”. But what is “System Thinking”?
Shortly explained, “System Thinking” is the ability to see the “big picture” and not to be focused on just a small part of your job. For a better explanation, I will use as an example my former team to demonstrate my ideas. In that particular team the work was arranged so that the developers had a set of User stories to work on. A finished User story was passed over to the testers for testing. The problem was that although for the developers these stories were quite simple to implement, they were quite challenging for testing because of several compatibility issues that required full allocation of testing resources. When developers ran out of User stories they were asking the Product Owner for more stories to work on. However, the PO acted rationally and did not give them any new stories until the team delivered everything to the iteration backlog. It was obvious that the team needed some help to visualize everything that was happening. How to help the team?
Clearly, the developers had their best intentions in mind: they ran out of work, therefore, they asked for more tasks. However, because of their lack of “System Thinking” they did not understand that more work for them would mean more pressure on the testing resources that were already fully allocated and, ultimately, an outcome of a poorer quality of the team effort. Apparently, the developers needed to understand that it was not anymore a matter of “us and them” because their job is accomplished when a customer gets the product, and the product would be ready when the team would act as a single unit. I have discussed this issue with some of my colleagues and they gave me a good idea: in next iteration to use Value Stream Mapping (VSM) for observing how the system behaved. This tool is a great instrument to identify different aspects of a system. If you want to use it you need to take some time to explain this tool to your team. From my experience not many people apply this in software development. VSM can be a fantastic tool to be used at retrospectives, but this could be explained in another post ;). Let´s see what happened at the iteration retrospective (an iteration where VSM was used).
By that time, the team was already familiar with the VSM and they were quite impressed with the amount of information we collected using it. Having looked at different VSMs (we created one for each different User story), it was not long before the team could see that bringing more User stories to the iteration would not translate into higher output because the testers were already fully loaded, therefore, producing more code would only mean that the testers would not be able to deliver everything on time. The team started appreciating more “System Thinking” and not just think anymore in terms of their separate “boxes”. After some discussions, the developers decided that in the folllowing iteration they would help the testers with all the testing activities to deliver more User stories as a team. In the following iteration the developers and the testers worked more as a team and the output of the joint effort of the team was indeed of a higher quality and volume.
Do you think this is something to consider when you work with your teams? What are your ideas on the topic?
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 help a team that is not performing so well - Part III
In my last post I discussed the pyramid with the five dysfunctions of a team and the appreciation exercise. If you did not see my previous posts, I would highly recommend you to have a look at them first, because this is the last post of a series of posts where I present a possible structure of exercises to help a team recover from a non-productive situation. Here I will explain the remaining exercises necessary to finalize the set of my Team Recover Exercises.
The following exercise is about reinforcing the Scrum values. Lyssa Adkins uses the metaphor of a tree, stating that in order for a team to be highly productive, they need to have strong roots. When the roots are strong and solid the tree can grow and flourish bearing beautiful fruits. Below you can see Lyssa’s example.

[youtube=http://www.youtube.com/watch?v=t3kKechcwYM]
Commitment is the state or quality of being dedicated to a cause, activity, etc.. A commitment should never be broken and if it is broken it was not a commitment but an empty promise and a lie. In the Scrum world this means that everyone involved in developing a product is committed to working towards a common objective.
Courage is the ability to confront a fear, pain, a danger, an uncertainty, or intimidation. In software development all these feelings will be always present and it is up to the team members to try to dispel anything that prevents them from being successful.
Openness is the ability to be open to new ideas, new approaches and new ways of working. This is a fundamental state in Agile software development because every day teams encounter different problems that need to be approached differently, being open is mandatory for achieving success.
Focus is the process of selectively concentrating on one aspect of the environment while ignoring other things. In software development this means teams should completely concentrate on one topic at a time, they should not start a new topic before finishing the previous one.
Respect is a feeling of deep admiration for someone or something elicited by their abilities, qualities, or achievements. In Scrum all team members interact closely, respect is mandatory for such relationship to work.
In this blog, you can find another point of view about Scrum values. I believe one hour should be enough to refresh the Scrum values with the team. After this exercise they will be ready for a more practical approach.
At this point, with the values written on a flip-chart, the team is ready for a new exercise. Make sure to reserve half of a day for the next exercise. By now you will need a tool to help the team recap the basics of Scrum and I believe the Lego Scrum is highly effective for that. The goal of the game is to simulate every aspect of the Scrum process: the team members will be asked to build an entire city using Lego blocks. The team will have to put in practice everything learned previously. More details about the Lego Scrum can be found here.
After all these exercises I believe the team will be ready to start all over again and start working better as a team delivering software products of higher quality.
I am not expecting to find a super productive team upon arriving to the office right on the next day after the exercises :) This is only a starting point, like I mentioned in my SECOND post, there can be five dysfunctions in a team and the exercises that I proposed are just for tackling the most fundamental problems, such as lack of trust. It is up to the Scrum Master or Agile Coach to continue working with the team in order to help them to overcome problems and to become highly productive as a team.
Hope you’ve enjoyed this series of exercises. If you want to try it in your own team, I would like to ask you for a favour: please, come back and share the results :).
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 help a team that is not performing so well - Part II
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,
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 help a team that is not performing so well - Part I
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,
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
Constellation - A Good Exercise to “Set the Stage” At Your Retrospectives
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.
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 large stories can impact learning
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?
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
Goals trap!!! Be careful when your boss establish performance goals…
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 :)
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