Scrum
now browsing by category
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
Lunch with Herman - A fantastic story of waste creation
Hi guys, this week I got a call from my friend Herman who works as Agile Coach in Super Soft, here you can find a bit more about what he already did. He sounded quite sad and frustrated, though he didn’t want to explain the reasons. So, I invited him for lunch since no one can resist a Schnitzel and Weiss beer.
During the lunch my fears were confirmed - Herman was down and depressed. After my insistence he finally opened up to me. As it turned out, he was extremely frustrated about the latest happenings in Super Soft. This time his responsibilities were beyond Agile Coaching, he was in charge of a project as Project Manager. So he finally had a better overview of the entire release process in the company. Being quite an experienced Agile Coach and a System Thinker, Herman felt extremely frustrated about the way things were managed within the release process.
The way software release is managed in his company is completely against his vision of how the process should be. In his opinion the company should have a complete cross-functional team responsible for software releases. The team would make independent decisions, and if they decide that the product is ready to be shipped - it would be shipped.
At the moment the company is full of small boxes (different departments), and the release of software depends on the decision of each of these departments. Herman has a feeling that most of the people in his company can only see their own small boxes and cannot understand the big picture. What is worse, he fears that people have little understanding of customer value, because instead of reducing the time to market they prefer to spend most of the time on acceptance gates.
Then I asked him, “Why are those acceptance gates there?” The poor guy almost exploded telling me that quite a few times in the past there were situations when something went wrong, but instead of understanding what went wrong, the company created more processes to prevent the same happening in future. He then quoted “Mary and Tom Poppendieck”: “When an organization experiences software development problems, there is a tendency to impose a more disciplined process to the organization usually one with more rigorous sequential processing: Document requirements more completely, obtain written customer approval, control changes more carefully, and trace each requirement to the code”. This is exactly what is happening in Super Soft.
He then gave me his opinion on how things should be managed. In his opinion, his company should try something what Toyota does. They should “stop the line” and understand the problem. They should find the root of the problem, its cause, instead of creating another process just to avoid the issue. Because creating another process will never fix the problem but only waste resources, and, most probably, sooner or later the problem will re-appear elsewhere in the organization.
Herman believes that Super Soft has a difficult culture – it is a culture that does not tolerate mistakes. If people make mistakes - they are punished, and it is easier to put acceptance gates into different phases of the software development process rather than try some other approaches until they find the root causes. In his opinion it will be extremely difficult to change his organization because it is not a learning organization. If an organization is not open to learning, it will be unable to develop.
After that I could not really say much to him, the problem is quite complex and I do not have any ready solutions. The only thing I suggested was that he could try to map all the release processes using a Value Stream Map and with that try to understand how much time his company spends on doing something that brings real value to the customer.
Based on what he told me, though, I believe he would have a difficult time trying to agree with his colleagues on separating the activities that are a waste of time from those that actually bring value to the customer. But that is another story :)
What do you think about it all? Can you help us with your suggestions? What other options do you think Herman has?
To close this post I would like to say this is a fictitious story, any relation with the characters or the company’s name is mere coincidence.
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
NPS a great way to help the PO to structure the product backlog - Part II
Hi guys, in my last post I explained what NPS means. I finished the post explaining the benefits of this concept. In this post I will explain how NPS can be used as a great way to collect user feedback in a structured way identifying priorities that should be taking into account for next interactions/releases. I will explain this by giving an example of a company where I used to work.
Several years ago I worked in a company that used NPS on daily basis. They used NPS everywhere, in my opinion it was used too much but that is how they worked. They used NPS to compare product performance between organizations; they used NPS to measure employees´ performance and at last they used NPS to help product owners to prioritize and build product backlogs - this is what I want to talk about in this post.
All customers that used products could answer the question: “How likely is it that you would recommend our product to a friend or a colleague?”. This question could be found under the “feedback” section inside of the product. When the user answered the question he or she would send the score and respective comments justifying his/her answer to a server where all scores with the respective comments were collected.
To analyse all these comments and scores, a team was created. Their responsibility was mainly to collect, analyse and cluster all different feedback. This feedback was sent once a week to all product owners involved in the product development. This feedback was extremely valuable since it would help the Product Owner to create a better product in future based on real wishes from the customers. The product owner could use this either to review his/her previous assumptions of what could be a good product, or to tackle emergent problems that appeared in each release. For example the sign would be if there were dozens of customers complaining about the same issues.The product owner would need to act. These issues should be tackled in next iteration in order to correct customer unhappiness. Clearly these matters had the highest priority in the product backlog because they had a direct impact on the customer.
All this feedback was critically important during the whole development phase but especially before the official release, when the product was in Beta stage. We used this time to collect extremely valuable feedback from customers in order to improve the product for the official release. At this point the PO was looking at feedback on a daily basis. This would allow the team to be able to change the most critical issues before the product was released resulting in a better product with a better customer satisfaction.
NPS is still part of the company´s product development. Even though I do not work there anymore, I truly believe they still use all customer feedback provided by NPS to improve their products.
To conclude this post, imagine this: You together with several other customers detect and report a problem. Two weeks later in the next iteration release you have the problem solved. The company was able to listen to you and correct your problem. In two weeks time!!! What would you think about the company that can listen and attend your wishes in two weeks time? It would be amazing, right? Do not worry, I believe this is the future :)
This was another topic that I wanted to share with you guys. I truly believe NPS can help companies or Product Owner to improve their own products and understand how well they are doing compared to other companies that use NPS as well. What is your opinion after reading 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
NPS a great way to help the PO to structure the product backlog - Part I
Hi guys, this post will be dedicated to all product managers out there. I will split this post into two parts, the second part will be written very soon .
Lately I had some discussions with some friends about “Customer Loyalty” and I realized most companies out there do not have a proper metric to measure “Customer Loyalty”. Companies do not have a metric in place to inform them about customer happiness in the product.
Most of them told me their products have the possibility for the customer to give feedback, but when I asked them if it is possible to have a metric that reflects customer happiness, the answer was unanimous: NO. At this point there is no possibility for them to measure how the customers are happy, neither to measure whether the product is performing on the market.
Some of them were asking why is it important to have a metric to measure the customer loyalty? In my opinion, the answer can be easy: the best marketing tool is “mouth to mouth marketing” that’s why it is so crucial to know what our customers think about our product. A good reference can bring more customers on-board more likely than a bad reference which can destroy possible ones. Having a metric that is able to measure this is quite essential in order to be able to improve customer satisfaction.
Naturally after explaining the reasoning they were asking me what would be my suggestion. I believe there are several options how to measure customer satisfaction. I explained what one of my clients implemented in most of their products. They did implement NPS – Net Promoter Score.
Implementing NPS was easier for the company to analyze user feedback and product problems; Based on this, the company could decide which action to take in order to improve customer happiness. NPS can also provide a stable measurement of business performance that can be compared across products, business units or even across industries, allowing the company to better understand what kind of portfolio does it have.
But what is “NPS” ? Net Promoter is a customer loyalty metric. The Net Promoter Score is obtained by asking customers a single question: “How likely is it that you would recommend our product to a friend or a colleague?”. The rating scale is 0 to 10 , where 10 is “extremely likely” and 0 is “not likely at all”. Based on the responses, customers are categorized into three groups: Promoters, Passives and Detractors.
A detractor is someone who will give negative references about your product. As an example I can use the situation when I went to a restaurant and spread the bad word about the service to my friends. The passives are people that do not complain neither promote your product. The promoters are the ones that spread a positive references about the product/service. These customers always come back and consume more of your products/services. To obtain a Net Promoter score (NPS) we must subtract the percentage of Detractors from the percentage of Promoters.
Here you can find some companies that are using already NPS:
The most important proposed benefits of this method derive from simplifying and communicating the objective of creating more “Promoters” and fewer “Detractors” — a concept that is claimed to be far simpler to understand and act on. Using this metric a company can know exactly what is the percentage of users that act as Promoters, Passives or Detractors. It is a great way to collect user feedback in a structured way identifying priorities that should be taking into account for the next interactions/releases, however this will be discussed in the second part of this 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
Using Journeys Lines for Retrospective
Hi guys, my next iteration retrospective is coming.
Since I ran out of good ideas for the retrospective I decided to get advice from my “Sensei”, he is a cool guy always ready to help us when we need. Below you can see the conversation between us.
Luis: Good morning Sensei, do you have time?
Sensei: Sure how can I help you?
Luis: You know our next Iteration is almost over and I am thinking about good exercises for our retrospective. I am wondering if you could help me.
Sensei: Sure, but before we start can you please tell me how the iteration went? I would like to understand what did happen during the iteration so that I can give you better ideas.
Luis: Sure. This iteration was a bit complicated, there were a lot of things happening, a lot of different emotions I could almost compare it with a Roller Coaster.
Sensei: Hummmm I see… And what kind of exercise you think would suit to this retrospective?
Luis: Like I said, it was almost comparable to a Roller Coaster, so I believe something that would capture what really happened during the iteration… I don’t know maybe some simple way to visualize the energy during the iteration… I think everyone would benefit if they could see and understand how others felt with all those changes. I think it is good to show our strengths and weaknesses to others, it shows to others that we are normal human beings like them.
Sensei: Good, see it seems you have a lot of info there… What kind of exercises did you think on your own?
Luis: I thought about several ones, but to be honest I think none of them would capture the essence of what I am looking for…
Sensei: I am seeing one that could be quite useful, but I do not want to give you the straight answer… Let´s think a bit together. I do remember about a specific kickoff that you had some months ago. I remember that you did an exercise that fits to all of that didn’t you?
Luis: Hummmmm are you talking about the “Journey Line”? But that exercise is used for kick off not for a retrospective…
Sensei: Well what would be the worse thing that could happen if you try to adapt the exercise for a retrospective?
Luis: Well I think the worse that can happen is to have a poor retrospective, but I can always see it as a positive experience and learn what did it go wrong and change it for the next time… One of the Agile values is courage so I guess trying this would support this value.
Sensei: Good approach. So what will you change in order to be a good exercise for retrospective?
Luis: Well the original exercise is typically used in Kickoff meetings, its a good way to show to others a bit about ourselves. Basically each one of us draw a line since we got born until today, showing the positive and the negative times of our life, like is shown here:
Taken from “Coaching Agile Teams WorkShop by Lyssa Adkins and Michael Spayed
Sensei: Yes, I do agree but what are the changes that you will do in order to be a good exercise for a retrospective?
Luis: Hum I am thinking maybe instead of mapping our life, maybe mapping our emotions/happenings during the iteration. How about?
Sensei: Sounds good, but on the kickoff meeting the exercise was more for an informative purpose, retrospectives should have an outcome. Retrospectives should terminate with a list of improvements. What are you planning to do about it?
Luis: That is a really good point… Humm let me think a bit about this over a coffee. I will come back soon.
(After 10m)
Luis: Ok, I guess I got some ideas.
Sensei: Tell me about them.
Luis: I have a theory that I need to test… But lets start from here, all team members will draw their lines, I am almost sure that some of the lines will “hit” in some common events. It will be easy to see it. After that I can ask the team members to vote the top biggest problem that affected most the iteration. After we identify the problem we can do a normal exercise to find out how can we improve it in the future. What do you think?
Sensei: Well it seems that you found an exercise for your next retrospective :). Let me know how it went. Remember even if the outcome of your experience is not perfect, there is no problem, learn from it and improve it next time. Learning is the key action.
This is how I got some fresh ideas for my next retrospective.
Hope you have enjoyed,
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
Is the organization truly agile?
Hi guys, I spent my last two weeks in Portugal where I had the opportunity to give two workshops. The first one can be found here: “Why to move to Agile” and the second one here: “
Product Owner“. Soon you can find dedicated blogs about these presentations. There were several discussions about how difficult it is to change into an Agile culture.
Sometimes companies are not yet ready to change. In these situations we need to decide if we want to help companies to understand that a change is a must or we will start to look for a new job where companies are eager to implement Agile. During these workshops I had some ideas that I wanted to share with all of you. Imagine that you have an initial conversation with a person in a company where you have just started to work. How can you see if the organization is truly agile? I had some ideas about what you can ask to see if the organization is truly Agile.
You can start to ask about concrete aspects, for example how often is the product released to the customer; If they release the product several times per year it is a good sign. Do they have a ready product that could be ship-able at the end of each iteration? Or is lengthy regression testing phase needed? A truly Agile organization can release a product at the end of each iteration if they want. If regression testing is needed, there is a space for improvement. Who is the ultimate responsible person for the quality? Is it the team or some steering group? In a truly Agile organization the team is the ultimate responsible for the quality. When a product owner accepts the stories as DONE it means that everything was accomplished in order to have the maximum quality in the product. I believe the organization does not need anyone else to put the stamp “Ready to Release”.
To finalize I would end in my opinion with an extremely important topic. Try to understand what is the organization´s view about “Command and Control” approach versus “Empowerment of people”. This is extremely important, true Agile cannot be done if you do not give all the freedom to people. Empowering people is a powerful tool USE IT!
Please note there are no right or wrong answers… These ideas were just to help you to see how the company sees Agile. I hope these ideas were useful for you.
As always, your feedback and ideas are important. Please leave some 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
Why features teams are not enough!
Hi guys, this time I am co-writing this post together with Sven Schnee. Couple of weeks ago we were invited to speak at the local community with the purpose of explaining “Why features teams are not enough!”. This event - Agile Breakfast is organized by Sybit. We were thinking what to share with the community so we decided to talk about this common challenge that many organisations face nowadays.
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
Why is it difficult to have a “Green Build”?
Hi guys, in my last post: Why is it important to have a “Green Build” I did explain how important is to have a Green Build. In this post I will explain several reasons why it is so complicated to keep it green.
Before I start to enumerate several possible reasons I want to highlight the background of our system. We have a long way to go until we are truly agile. We have all the necessary skills within the Feature Squad to release a product but the organization is structured in different departments (System Build, Development, QA, etc.). This set up is responsible for the presence of silos. We are working toward an organization where silos will not exist but this is how organization works. On top of this the developer must wait several hours to get some feedback about what he did. He only knows if he broke something several hours later. Now with this information you will understand better the problems we are facing.
There are four different areas that I want to touch:
- Code changes
- Tests changes
- Build System
- Test System
I don’t have the perfect solution for all these problems, I have my beliefs and my opinions but I don’t know how to solve all issues in a short time. Since I do not want to finish this blog without any ideas I will give an example of another team we have where the results are extremely positive.
This small team has the ownership of everything. They own the build system, testing system, production system and whatever is needed for the work. They practice TDD, and there are no departments saying how they should work. They solve their own problems on daily basis, they do whatever is needed to make it “green”. They commit their code every couple of hours, they don’t go home if the code does not compile and all the test are green. I believe the biggest advantage of this team is the fact they know why a green build is so important. After failing so many times they understood why a green build is mandatory.
All organizations should aim for continuous improvement. However I truly believe the first step is to understand where we are and where we want to go. So if your organization has some problems, bigger or smaller, does not matter. I believe first you should realize which problems you have and define a plan where you want to go. Then just work with the rest of the organization to achieve those goals. Do not forget to empower your teams, they know what to do much better than you.
Please let me know 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
Why is it important to have a “Green Build”
Hi guys, during the last weeks we had internal discussions about the importance of having a “Green Build” and the result will be presented in this post.
I strongly believe that one of the reasons why people don’t give importance to a “Green Build” is the fact that they don’t even understand what is behind it; what does a “Green Build” brings to them and what to the organization.
Having a “Green Build” means that a team has a basic need fulfilled, meaning they don’t need to worry with basic problems like making sure that they have the right kits or the right packages in place. Getting a “Green Build” means that the team can concentrate in improving other parts of the software development, focusing on something more important; quoting Deming “Cease dependence on mass inspection to achieve quality. Improve the process and build quality into the product in the first place.”
A “Green Build” can serve as a safety net; if the code compiles, all different test pass, etc. It means that most probably nothing was broken, in this sense this creates confidence in the team. The changes are not only visible to the other developers in the team, they just “give birth” to a build that could potentially end up in acceptance testing or even a production.
Not having a “Green Build” for a long period indicates that the product is not stable. The lack of a stable product increases the unpredictability for a release. In these situations it is impossible to know when the product will be ready to release without a large (and unpredictable) testing phase at the end. Not having a “Green Build” leads to a sequential project life-cycle, aka waterfall.
These were just small ideas from brainstorming sessions of last weeks that I wanted to share with 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
D5 Creation