Archives

All posts by Luis Goncalves

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

Posted by Luis Goncalves on December 17, 2012
Posted in: Agile, Localization, Product Development, Software Development, Testing. 37 comments

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 by Luis Goncalves on December 10, 2012
Posted in: Agile, Process Improvement, Scrum, Software Development. 7 comments

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 by Luis Goncalves on December 3, 2012
Posted in: Agile, Product Development, Scrum, Software Development. 4 comments

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

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

Posted by Luis Goncalves on November 26, 2012
Posted in: Agile, Product Development, Scrum, Software Development. Leave a Comment

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.

Thank you,
Luis

Using Journeys Lines for Retrospective

Posted by Luis Goncalves on November 19, 2012
Posted in: Agile, Retrospectives, Scrum, Software Development. Tagged: , . 2 comments

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,

Best Regards,

Luis

Is the organization truly agile?

Posted by Luis Goncalves on November 12, 2012
Posted in: Agile, Scrum, Software Development, Uncategorized. 2 comments

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”.

Then you can ask more about teams structure. Is all team collocated? Is the product owner located with the team? How reachable is the product owner? Nowadays it is quite difficult to find a team that is collocated, however if you want to take the maximum advantage of Agile, teams should collocated with the product owner and this should be always available to answer all questions made by the team. Another interesting question that can be asked: “Is the team able to deliver software independently?” Or are the teams separated into several different teams like “development”, “testing”, “automation”, etc. I refer this question here because I saw several examples during my professional life where companies say they do Agile but in reality they just call themselves “Agile”, being all their practices normal waterfall techniques.
You can try to ask some “open questions”, these questions will serve to analyse the company´s vision. You can ask what is the organization´s vision related to Agile; Is Agile just a project management methodology or is it more a management philosophy? Unfortunately many companies see Agile as a project management “thing”, they really do not understand how powerful an Agile and Lean philosophy can be. Another interesting question to be asked is how do they measure the Agility of their organization! And what is the plan to expand it even more. Of course these are open and no right answer type of questions but it would give you an insight how the organization is serious about Agile.

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

Thanks,
Luis

Why features teams are not enough!

Posted by Luis Goncalves on October 29, 2012
Posted in: Agile, Process Improvement, Scrum, Software Development. Leave a Comment

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. This event - Agile Breakfast is organized by Sybit. We were thinking what to share with the community so we decided to talk about a common challenge that many organizations face nowadays. The topic was “Why feature teams are not enough!”.

To be easier for you guys to follow we’ll tell the story of Herman - An Agile Coach.
Herman was hired as an Agile Coach in company Super Soft. He was an experienced Agile professional, in previous companies, where he worked, he was involved in several Agile transitions.
Herman took his first weeks to understand how the teams worked. After attending several demos he noticed a common behavior. The guys who were facilitating the demos always said “We are done, we do our job” but in reality they could not demonstrate anything because nothing worked. It was time for him to start doing some changes. He found several problems within the company. However one of the biggest issues was the strong presence of “Silos”; all the work of a specific component was done in a single department with few or no communication with the other departments. Once the department is done with his own development he hands it over to the next department. This goes on until all involved departments added their part to the product. Then in the end the integration usually happens with testing, bug-fixing and major problems popping up.
Super soft had several independent products that could be build/sold separated, so why not create teams that alone could release these products to the market? This was what Herman with “Feature Teams” created. He did assemble teams that alone could release a product without much help of other parts of the organization. This actually worked quite well for several months leaving Herman happy with his accomplishment.
Few months later the market conditions did change and Super Soft needed to launch a completely new product. Basically a bundle of several other independent products. Soon the initial problem that Herman had with different departments was hitting him again; this time on product level. Even though he had created feature teams that were able to ship a full product, in the scope of the new system, the feature team was not able to deliver anymore; skills like GUI design, CRM development, and some others, needed to build the system, were missing from the traditional feature team. Different product teams were developing their own products but nobody communicated with each other until the last moment when all integration problems popped up.
One evening when watching “Team-A” on TV he had a good idea. The creation of “Feature Squads”. A feature squad could basically consist of any feature teams and additional individuals that are needed to fulfill the mission. The mission in the new market conditions was to deliver full vertical features that included all the parts needed to bring the value to the customer. Despite his brilliant idea Herman still had to face problems. The new feature squads had their own little woes. Herman had to experience the pain of having a daily or planning meetings with more than 10 individuals. These meetings really took too long and the interaction between squad members suffered. He decided to break the teams, as a result he had a bigger number of teams but less individuals per team. The fact that these teams were not always collocated added a bit of complexity to the project, there were issues related to the communication and trust between members. It was a challenging path but at the end the product was released with success.
This was the story of Herman, the Agile Coach who helped Super Soft to become a better organization.
What we want to highlight is the fact that in both situations Herman had problems assembling teams. As result he did create cross functional teams, first breaking silos within departments, later within organizations.
We truly believe that companies should assemble teams in a cross functional way. The team alone is able to release the product without any extra involvement from other teams. Of course in reality there are always more dependencies but in theory this is how it should work.
This presentation can be found on my slideshare. And Sybit post about the presentation can be found here.
As always please give me your feedback,
Chers,
Luis

Why is it difficult to have a “Green Build”?

Posted by Luis Goncalves on October 22, 2012
Posted in: Agile, Scrum, Software Development. 8 comments

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
Based on the previous topics I want to tell you a story of a project where I was involved. It was a complex; the technology was new and difficult and the teams were not all collocated. I mentioned before that the developers had to wait several hours to get the feedback to know if they had broken something. As a consequence the product was constantly broken. In this case the basic unit test coverage was not enough to prevent the developers from breaking functionality. These teams still have a long way to go to become truly Agile. One of the areas where we could see this was by looking at the frequency of their commits, some of the guys did not commit their changes for days in a row. Which resulted in a lot of time lost trying to merge their changes into the trunk. And above all this complexity they also had to deal with a complex version control system, allowing developers to make many mistakes while checking in.
The testing part was still acting like they were before, they were now part of the same team but they acted like they were still in the Silo’s. F.ex. new tests were still only written by the QA people, not by the developers who implemented the code. This meant that sometimes the test were failing for several days because the people writing the tests were not the ones that needed to fix the code. Another problem they faced was that when the functionality changed and the QA people were not notified that the tests would not be adapted and then fail for the wrong reason.
And finally we had some problems that showed up once in a while, but important enough to mention here. The build system did not belong to the development team, instead the build system belonged to a whole separate department. Which meant that when a problem related to the build occurred hey sometimes had to wait for several days before the build was green again.
Having the above mentioned problems meant that finding a root cause was extremely difficult.

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.

Thanks,

Luis

Why is it important to have a “Green Build”

Posted by Luis Goncalves on September 4, 2012
Posted in: Agile, Scrum, Software Development. 3 comments

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.

Give me some feedback ;)

PS. You can follow me on twitter: lgoncalves1979

Thanks,
Luis

Do you have a quick tool to measure team confidence?

Posted by Luis Goncalves on July 25, 2012
Posted in: Agile, Scrum. 12 comments

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 .

Thanks guys,
Luis