Archive for December, 2012

Agile Localization - Outplay the competition, enter new markets and grow Internationally

Posted: December 17, 2012 in Agile, Localization, Product Development, Software Development, Testing
55

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 ;)

Thanks,
Luis

Lunch with Herman - A fantastic story of waste creation

Posted: December 10, 2012 in Agile, Process Improvement, Scrum, Software Development
9

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.

Looking forward to your suggestions,
Luis

NPS a great way to help the PO to structure the product backlog - Part II

Posted: December 3, 2012 in Agile, Product Development, Scrum, Software Development
4

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?
Please let me know,
Luis