Agile Localization - Outplay the competition, enter new markets and grow Internationally
Hi guys! This will be my last post this year due to Christmas season. I would like to take this opportunity to present my new personal project. Together with my two colleagues, Vasco and Wim, we are going to write a book about Agile and localization. The general overview of the book can be found here.
The people who know me understand that I am very passionate about Agile. So, we would like to take an Agile approach in writing our book. It will remain to see if this experiment would be successful, but since I have this idea, I would like to try it out. Put simply, writing a book is a creative process much like developing software - at the end of the process there are potential customers that would buy the final product. Therefore, why shouldn’t we write a book applying the methodology we use to develop a software product?
Our idea is simple. Like in Agile software development, we are planning to write the book in iterations, which means that we would not follow the traditional pattern: first write the whole book, then publish it and only then get the feedback. Instead, by the end of each such writing iteration we want to release the increment of the book we wrote and get the feedback from the public. Like in Agile software development, the feedback will be integrated into the book to improve it. Every time before starting a new chapter, we will communicate its topic to our audience and invite our followers to a discussion about what they think is important to include in the book. Naturally, the book will have the main story, but the idea is to adapt the book to our “readers´ needs”.
The localization of the book will also be part of this incremental process. To have the book localized for a particular market, we would not need to wait for weeks until the product would be released in English first. Instead, as soon as the iteration is finished, the released increment of the book will see the light in English and in some other languages, too. If we really believe in this concept, there isn’t a better way to prove it than to apply it in our own book.
We are starting this project in January, and we would highly appreciate all the feedback from you, guys. If you are interested in our project, let us know! Let’s use this blog for communicating and collecting your thoughts about the book. Another thing, we would highly appreciate if you could tell us how much you are prepared to pay for the final product – the finished book. This would give us an idea about the price range for price-tagging the book, please, leave your comments here. Another way to leave your comments will be using our NPS system. Some weeks ago I wrote about NPS, you can find the post here. Before we start releasing the first chapters we will have in place a system where you can leave your NPS score.
There are a number of other issues that we still have to solve, but being truly Agile means that we will be adapting along the way and tackling issues as they arise.
Now, the only thing missing is your initial feedback. What do you think about all this, guys? Do you think this could be a cool project to be part of? Would you like to take part of this project?
Look forward to 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
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
Do you have a quick tool to measure team confidence?
Hi guys, this post will be about a quick exercise that I did during last retrospective and I would like to get your input.
Like always I started the retrospective with a small exercise to “set the stage”, something to make the people relaxed but at the same time helping them to get the focus.
I did the brand car exercise, this exercise is quite basic; we just ask to each different team member how they would describe the previous iteration using a brand car.
I had the brand of the car in my mind, I chose a Ferrari. The iteration went very well; the team delivered all promised stories, and they won a private bet against the PO. He did bet with the team that they would not be able to deliver all promised stories :). Naturally I thought about Ferrari and I expected to hear the same from others.
I started to ask one by one which brand they wanted to better describe during iteration. Surprisingly, all the mentioned brands were modest, such as Opel, Skoda, Ford, etc. The only luxurious brand car was chosen by PO. At that moment I didn’t play so much attention, I thought that these guys are humble :).
Later on during the conversation with an Agile Coach, colleague Mark, he mentioned to me “Did you see how their confidence is so low?” The iteration went so well and according to type of the cars they chose, their confidence of achieving something great was quite low.
This conversation with Mark was the main reason why I am writing this blog! I truly believe this can be used as a quick and simple tool to evaluate team´s confidence. What do you think? Do you think this is a useful tool to verify team’s confidence?
Please comment this post and leave me your opinions :).
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