Browsing Category


Digital transformation, Entrepeneurship, IT is business, Office, Practical examples

How did Netflix reach the nirvana of ownership?

May 15, 2018

Netflix doesn’t have a CTO (Chief Technical Officer). Having a CTO would be a symptom of centralization of technical decisions. On Netflix they have just a CPO (Chief Product Officer), which is the chief for their products. Products and IT are the same. Netflix also is one of the most innovative teams on technology and value purpose on world. But how did they reach this point? What took them there?


Profiles and responsibilities

They were born this way. It was a mindset simple to keep while they were a startup in 1997. But this thought have been kept during the years even with company’s growth.

With a set of benefits to their employees, which can be translated simply on freedom for them to take the actions they think are needed, Netflix shares their actions on management and responsibility in their speeches. The main concern of a manager is to hire the best people on world. The main concern of all the employees is to take the best possible decisions, having all the company’s context available to rely on. Subscribers numbers, revenues, all the areas budgets are part of the routine information that the managers share with their teams. Managers require their team members to enroll to competitor’s hiring process at least once a year to ensure they are getting the money they deserve. There is no knowledge management also. When an employee leaves the company, their projects die with him. There are no junior, plenum or senior levels.


No rules

Netflix avoids rules and processes because they believe that when you tell people how to act, their creativity is restricted and it makes them to stop thinking on how to add more value to the company. It has a cost. It is common for hiring positions to take more than 6 months to be filled, because they require complex hiring process and high levels of subjectivity.

Having some benefits examples like:

  • Vacation time undefined;
  • Maternity leave time undefined;
  • Technical subjects budget unlimited;
  • Hardware and software budget unlimited;
  • No work plan definition: once you get hired nobody will tell what you have to do. You create your own project, work, finishes, tests, and goes to the next. At this point your manager can help you taking the decision if you want.

This freedom goes through only one restriction: act like Netflix interests.

This way the company, which is proud of saying that hires only the best possible people for their positions, and that has more than 4000 employees, reached a level of ownership hard to compare. Each one is responsible for their projects and has autonomy to define if it is useful to the company or not.


What does it generates?

It generates an incredible freedom environment for people to produce what they consider important. Once all the employees are the best in their areas, it is understood that they will have enough knowledge to take the best decisions. It generates more than 100 projects going on simultaneously from all company’s areas and being tested at every moment. IT projects can’t take more than 2 months to be finished. Each 2h one publication to production environment is made, and nothing is activated before going through A/B testing.

The great objective of ownership also is achieved because all of these conditions also have the intention to delegate power. Every Netflix employee must be capable of taking decisions without depending on endless validation processes or unnecessary opinions. Mixing freedom, responsibility and power is how Netflix reached and keeps his very high level of ownership among their employees and keeps being one of the most innovative companies since the moment it was created.


The model and how to learn with it

Compared to other companies on different acting areas, among the most traditional ones like industries and the most recent startups, Netflix reached his ownership through the joint of some things: almost unrestricted power, almost unrestricted freedom and seniority/maturity as a premisse.

This is a unique model that should not be pursued blindly, but used as inspiration to watch the disruptive way they found to manage their company

Avoiding problems, Customers, Office, Practical examples

How to avoid suicide applications

January 29, 2018

Having the experience of managing many projects in many different methodologies and different mixes of them, recently I could notice some attributes that happen in all of them to make it to be a suicide project to manage. By suicide I mean a project that will face issues and go down until it reach an unacceptable status, leading to a client loss, or something extreme like that.

The items below were identified as something common to all of managing styles, and if any of them is common to you or part of your routine, it’s time to change something. Some of them regard people relationship and some of them technical parts.


No QA environment

A project which has only a formal Production environment. The development is made by coders on their own machines. There is no QA (Quality Assurance) environment.

It looks crazy, right? But it still happens. Usually it happens when who is paying the bill doesn’t understand how catastrophic not having a Quality Assurance / Testing / Homologation can be. When it happens you are dealing with your luck day-by-day like the image above.

The QA environment must be, ideally, an exact copy of the production environment. Routines of copy from PRD (production) to QA must be maintained from time to time. When it happens, whenever a problem on PRD comes, it will be faster to track and simulate on QA. If it’s faster to simulate, it’s faster to find a solution and fix PRD. When production is fixed fast, the client loses less money related to that failure, or its brand is less affected due to that stop.

There can be different ways or minimum-requirements to at least have a trustworthy test before sending new code to PRD. The QA data can be different of PRD current. The environments may have different hardware configurations and etc. But the more differences QA and PRD have, the more time will be spent to track down issues.

Talking about a different service, when you don’t have a QA environment, holding proportions, it’s the same thing as a doctor trying a new surgery method without testing it on mice or monkeys before. It can work. But there is a huge chance of going wrong. And when it works, its nothing but luck.


Zero Automation

The more automation you have, the less human errors will happen. People will fail. And it’s normal! Let’s let people to think on what really matters and not on routine tasks. Somehow it will happen in someday:

  • They will commit the last code to the wrong branch. Then production will have a break;
  • They will forget to run a script before deploying a package. Then production will have a break;
  • They will forget to run minimum tests before running a new process or service. Then production will have a break;

A good way to prevent those errors to occur is to automatize as many things as you can.

A good starting point may be automatizing the deployment activity. Many companies I’ve already seen still have issues with deploy. They plan 4 weeks in advance for a deploy. The deploy is done. It crashes. It requires one or two weeks to fix the code and get production running back again. Then it plans with 2 months in advance. It crashes again. If the deploy is a problem, why not turning it into something trivial? Try to make it everyday. A lot of things will be learned.

Automatizing tests is also a great initiative. Automatized tests is one of the best weapons for software stability. The more coverage of tests your app has, the more stable it will be. These two suggestions will require time to be implemented, but their benefits will be felt on software credibility trough the whole company.

Talking about a different service, not having automation is like loading a warehouse box by box, without a fork-lift. A lot of time will be wasted of course. Also some of them will be dropped. Some of them will be shaken too much. It will work, but a lot of risks are added to the project without a need.


Key-user displicence

The one responsible for testing your project is the main actor of your routine. They will be whose opinion will be asked about on going practices. This person must be committed and addicted to your project, helping and pointing fingers to anything that goes wrong. The best projects I’ve ever been enrolled had very picky people testing and giving their OK to delivered features.

If your project lacks this concern, many problems may come up:

  • Lack of perception of value. What you have been practicing/telling is not what the customer likes to hear/watch;
  • Lack of alignment of what is developed versus what really adds value to the business;
  • The worst one: Lack of knowledge about the system. This person should be the one who knows all the system. If they don’t, many problems may come up because of different conceptions of why something was developed in some way;

This example is like a mom who doesn’t care about its baby education. It will grow, of course. But it can turn into a time bomb.


Low judgement at technologies choices

Technology is something serious and can’t be treated as a fashion trend. Fashion trends come and go and are renewed from time to time. A programming language, framework, feature, cloud provider neither anything related to development can be elected because its fancy or is the thing who everybody is talking about right now. All of this decisions must be questioned by the development team and, if possible, count on help from someone outside the project to think together with the team and reach the best choice.

When wrong technology choices are made, it may cause some problems like the following:

  • Difficulties to find people who know that technology to work with you in your project;
  • Problems in the future due to incompatibility of that technology with the project requirements;

Using the parallel to other services, using a new technology which is not proved yet is like buying a hamburguer with vegan-bacon inside it. It can be good, but is not proved yet. It will be your bet.


Deficient communication/status

How is structured your routine of communication with your client? Do you have formal moments to share information? Or do you make it when a trigger come? At this point there is no right answer, like suggested on the article “The magical answer for software development project management“.

But you will have a process to share information and to tell what you are doing to whoever is paying you. It can sound strange, but sharing this information may be a serious problem in many projects. You must ensure the activities you are conducting make sense to the client, and they understand that what you are doing is good to the business. Will you have a weekly meeting? A daily? A status report?

When you don’t have a process to give feedback on what you are doing, is like investing money with an investment company that doesn’t inform you about your gains.


Why to attack all of this?

All of the statements above refer to practices that must be figured in your project. Otherwise they will mean problems on the relationship or on the app data. Whenever any of them happen, they mean losing money or at least weakening the system owner’s brand. It may be natural that the main apps of a bank won’t have large issues. But the user doesn’t like when the registration to that cashback program crashes. It means the bank is not serious about their user and marketing advertising.

Digital transformation, IT is business, Office

A vision about IT evolution

January 7, 2018

When the IT and the modernization it brought first started arriving the industries, there on the 1960’s, it was faced as something not wanted, but needed. The IT had its own language and terms, like the other areas, but for some reason it was not serious as the other areas. The IT people used to be treated as the people who could make magic and make people’s work easier. But what we have seen lately is a huge evolution and change on how IT is faced.


First scenarios

I heard during my graduation, from a professor, the conclusion that IT is a support area only. And I agree it used to be treated like that. The IT team were the strange guys, their workplaces were the worst, even not having windows to look outside. And it can be the reality until today for some companies. But it’s changing fast.

Old IT department

As a software service company employee, for years I used to be called to talk to our clients about new projects. The final conclusion is that all of those meetings were the same. I was called to create something new that could make activities easier and faster to be done by someone. And after that a waterfall move used to happen: less time was needed, then less people were needed, then less money were spent to keep that process/department.

As an instance, for those projects the procedure inside the demanding companies were the same:

  • Identify the need: we are slow at creating contracts for our clients;
  • Start the strategy move to change: let’s automatize the contract parts, that can be automatized, and add collaboration so our writers can work faster and together;
  • Call the IT department: hey, we want a tool!
  • Reach the ROI: we will save US$ 50.000,00 a year having less people writing, and reaching less our law guys;
  • Then the IT department calls the consultancy company (me): please build this tool.

After the tool was delivered, the contracts area got faster, the company saved money, and the whole IT talking was finished. Talking business, our clients were demanding about improving and automatizing parts of processes. The IT used to be faced as the support area which could solve problems or improve processes of the products areas.


Then the digital transformation


The customer experience focus, is pushing one of the most mature steps of digital transformation we have this far. The IT becoming the companies’ core. This move has been happening based on a world connected to the internet. Since everybody has a smartphone, and everybody want to solve things faster, leaving behind unnecessary stuff (like lines, support waiting times, etc), the IT is the way to reach those people. The customer needs are changing faster and the time spent on that formal process can’t be handled anymore. It must be possible to make changes and adapt at the same speed of the market. Because of that, the IT must be available 100% of the time.

Using the same instance, but now changing to mature business, the new procedure to improve something would be:

  • Identify the need: we must create a new feature to our final customer;
  • Start the strategy move to change: let’s include the feature inside the app;
  • Reach the ROI: we will make US$ 50.000,00 a year with that new feature;
  • Then let’s do it; No more boring meetings are needed;

With this core move, the IT is getting more importance on the business scenario. It’s not the ugly son anymore. The financial industry in Brazil is one of the most mature industries in world, and is pushing the others. I have already seen arguments between the final product areas, which used to rule the scenario, and the IT. It doesn’t make sense anymore to keep these two areas separated.


The next industries

This move seen in the financial area, which goes through every single company, isn’t common to all industries yet. For the next industries affected, its easy to understand the more B2C the company is, the faster will be its rush to adapt. Retail is a good candidate to be the next one. But what about the rest? When the factories will get to it?

Avoiding problems, Customers, Office

The magical answer for software development project management

December 3, 2017

Lately I’ve been negotiating with a lot of different clients about many different projects. Having a quick look at the projects, it’s incredible how people wrongly seek for one single project management methodology to rule them all. Beside that, when clients look for “agile methodologies”, what the biggest part of them want to say is: “let’s use Scrum for everything”. Then after my opinion was asked by a friend who was meant to establish a PMO, I had the ideia of this article.


Different clients have different needs

In my scenario, as a consulting company, it’s very clear to notice that different clients will have different needs. It’s common to be asked about software development methodologies. The main thing is that, even inside the same company, which is not a consulting as instance, there will be different ways to manage projects. There is not a single pattern. It depends on people. It depends straight on the teams maturity to act, and I will show few examples based on the infographic “Software development maturity evolution brief story“.

The traditional / waterfall / CMMI approach:

Yet the most common on big organizations. It gives executive information to managers and a lot of very concrete information about the project. It focuses a lot on process and files to keep track of everything that is happening on the project. Dependency mapping, communication mapping, scope controlling, and many others will be done by the manager. This will cost a lot of money.

The Scrum approach:

More flexibility, less process, but still some issues. Scrum will allow the project to be more dynamic due to less focus on processes and files. What Scrum says is “keep sending work and we will keep delivering it”. It has many good things: less time spent on bureaucracy, “customer first” mindset, etc. But it shows few problems: it’s hard to work with deadlines and dependencies, and dailies can easily lose the value.

The XP practices:

Flexible, focus on finding value fast, feedback at every corner. XP focuses on finding value as fast as possible with the MVP (Minimum Viable Product) mindset. It also helps to improve the team practices constantly due to it’s cycles of constant feedback. XP needs a very disciplined team to run with, otherwise they can easily loose the focus due to the lack of practices to controlling.

The DevOps approach:

Self-service, no bottlenecks and automation. DevOps has been the most-said IT word for the last year at least, but very few people can actually practice it. It focuses on bringing everybody that matters to the project to work together, and that includes business people, UX people, DEV and OPS people, and everything else that matters. They must have autonomy to take decisions. Nobody can be a bottleneck. The developers must have the self-service mindset, otherwise they will depend on others to finish their jobs. DevOps also bring some challenges, as the DEVs not enjoying to do OPS tasks, and OPS guys not enjoying to code.


Different mindsets for project management

All of the models above were explored with the benefits and the problems they bring. Each of them can be useful if applied in the right context. So, no one of them is the magical answer to whatever are the problems you may be facing in your project(s). The perfect scenario is to mix things up, EXPERIMENT, until you find the best model for you and your team. But how to do that? If your moment is not allowing you to find that now, you probably are overwhelmed by the operation and are forgetting to think on your real goals. Try to look things from above. Your main goals, on software development, are shown above, and there’s where your effort must be focused:

  • Deliver value constantly – changing the application background color from blue to red may be nice. But does it really adds value to the business? Will it make the difference to the project or to the final user? Focus on what really matters and not only on creating more code.
  • Customer first – the reason for every software project to exist is the end user. Always aim to please that team. If their opinion is not green about what you are delivering, they won’t use it. And your project will be useless. Is your end-user happy? Do they feel like the software has good user experience? Do they find value on using your tool?
  • Experimentation – the fastest way to improve things, even when you don’t know what to improve. Experimenting after a good retrospective is something to do very often.
  • Focus on people – the key to reach all the dots above. If people are happy and find value on your organization, trust you and like their environment and routines, they will be very likely to do and test everything the team may bring up.


Then manage your own way

So the answer for you to apply the best development practices to your projects is your mindset. Once your mindset is aligned with the goals you must reach, forgetting all process addictions, then your right process will be created naturally by the team.

Avoiding problems, Customers, Office

Communication – how

November 16, 2017

Lately I’ve seen many people getting stuck with problems to pass away the message they want to. It’s always been a truth. But since there’s too many examples that I could see lately, I decided to give priority to this article idea.

The main problem of the biggest part of people I know have, is the lack of context and how they structure an idea. It doesn’t matter whether they are giving a speech, talking to someone, or writing an email the problem is the same. We all know that communication has been the main cause for projects failure. This is SO REAL that it’s very easy to find good quality content being published frequently. One good example is this article from CIO which published an article giving some advice about common mistakes. Number 1 and 5 regard communication.


Richness of each interaction

From best to worst:

  • Face-to-face conversation: you can say your stuff and check if the other side got it, and get a feedback on real time.
  • Video conference: same as above, but with less clarity on the other side perceptions and reactions.
  • Telephone: same as above, but you can’t see people’s body and face reactions.
  • Email: you can write, but you won’t get a feedback (at least not real time).
  • Broadcast communication (videos, folders, etc): it will be very hard for you to get a feedback.


When you are talking to someone

First of all, the what is important, but it’s all about how it’s done.

Whenever you want to talk to someone, what your mouth says is less than 10% of your message. 38% is said by your face, and 55% by your body.

So if you are talking to someone and that is important, of course you must prepare your speech. Do you need to convince a customer that your decision is better than theirs? Let’s try to organize it according to the three steps above shown:

Your actual speech

Prepare A LOT. The more you get prepared, the easier will be to accomplish the next two things. Let’s say you are having a technical discussion: try to look by everyone else’s optics to be sure that all opinions were considered. Try to be the devil part and imagine the questions that may appear from the pickiest person you know. Do you have a colleague or a boss that always question everybody about everything? Maybe this guys can be useful. So, the most important part is to prepare yourself as much as you can, because if you know everything about that scenario you will be very comfortable to argue about the subject.

Your face

Now that you know everything that must be said, it’s time to be confident. People are more likely to believe in a message from someone they judge trustworthy. You don’t like to be approached by a beggar, right? Your appearance count many points here. Also, if you are showing happiness in your face, you will get people’s empathy easier. But take care and don’t laugh for everything, people can think you are making jokes on work time.

Your body

As above, the main thing is that people believe in what they can see. So you are your image, not your thoughts. Your body must be confident at the same time your message is clear and your face is calm. Worst time for leg shaking, to nail, to keep look at everyone’s face to check if they are approving or not. How to be that confident? Preparing yourself A LOT. Since you already are well contextualized with the subject, and your face is calm, focus on being clear and be confident.


Writing communications

Ok, you couldn’t find the person you wanted to ask or say something and will have to use an asynchronous communication way. Let’s make it VERY clear. You just CAN NOT send an important message by email and assume the other side got it and read it exactly the same way you wrote it. It’s never gonna happen.

But let’s say you want to send a report which is really bad for your customer. It must be formal (using email), but it also must be said very clearly. The perfect way to do is: write the email, check it a bunch of times, then find a way to call the person on the other side. Then TELL him the whole email, check for his feedback, change anything that he may disagree (according to the reality of course), and then you send it.

But how to write that email?
  • What’s the purpose? What do you want to happen after when the other side read this email?
  • Who will receive it? Think of you, being they, and reading it. What they will think of each sentence?
  • Use short sentences. People are lazy. Don’t write big paragraphs. They will stop thinking at the middle of the big one, and won’t get the rest of the message.
  • Hard words: avoid them. People know you are smart. People are lazy.
  • Don’t assume people know everything: it’s you who have all the context for that email. Everybody must be on the same page. If you are in doubt, explain.
  • Be clear: split your thoughts like below.
    • Introduction: I’m here to talk about challenge X.
    • Justification: we should talk about challenge X because of Y.
    • Argumentation: show your point.
    • Conclusion: what to do next?

Remember: you are not writing a book. Each one of the points above can be done in one sentence, as instance, except the argumentation.

Avoiding problems, Office, Practical examples

A wrong example to customer first

October 29, 2017

I’ve already wrote briefly about how Brazil are still not used to think on customer first, and how different maturity-level companies face digital transformation. Now, one step beyond the theory, I’m sharing one WRONG example of customer first thinking.


Why we reached the problem

This specific and short example is a very technical one, since it’s an IT issue. But the software development team maturity is affecting directly the problems they are facing right now.

Just to start, I want to rewind a bit and present an infographic about software development maturity evolution. From “traditional” methods down to modern agile, where the customer first mindset is very strong. I can say the guys from this example are leaving waterfall and are reaching the SCRUM by the book as suggested on the infographic “Software development maturity evolution brief story“.


The problem
  1. It’s a company of investments advices. This is the most important system for the company. It gathers all the data to be processed sometime in the future. If this system stops working, the predictions stop being calculated and we have nothing to advice (information to sell).
  2. Right now there’s a huge load capacity issue, that makes it stop working from time to time and the company stops predicting. It makes them lose a lot of money almost weekly.
  3. It’s currently impossible to optimize databases and machine hardware for now. There’s a need for an architectural deep change.
  4. So, there’s not a short-term solution to the problem.

Then we have a crisis established. The company loses a lot of money weekly because it’s receiving more data that it can support. It’s a very clear IT planning problem. Nothing short-term can be done to solve it, and all the solutions are long-term. The first things to solve the problem needs 4~6 weeks to be done.


Why it happened and why the company is not thinking customer first

But why did it reach this point? It’s related to the development team maturity. They lack of practices of architecture, scalability, stability, resilience, failure prevention, failure tracking, log tracking, etc.

All of those listed above are just consequences. The real motivation is the lack of investment on the software production process. Like the example on the articles listed above, the mindset is defined to think about the product, which are the investments advices. The majority of the investments of the company go straight to people who look at the market, compare the data this system generates, and make the advices better and better. Cool uh?

But the real product here is the information this system processes and the insights it generates itself. There must be a half term of the company investment planning between the advices itself (business area) and the IT modernization (IT area). The bigger is the investment on the IT, in this case, the lower will be the need for investment on the business area, since the system already predicts that data the analysts are checking. If the development team maturity were located at the Lean/DevOps step, or at least XP, probably this problem wouldn’t have reachd this point.


What to do now

Of course, an express contract with a company to help them to make the architecture changes as fast as possible is the first thing to seek. But the long term solution is to fix the investment target. The money must have a better destination. The company board must stop seeing the IT area as a support and make it the area that holds the whole company.

Avoiding problems, Customers, Office

Retrospective. Just do it!

August 27, 2017
Retrospectives in software engineering

In software engineering, retrospectives are always linked do Scrum alliance’s practices, since they have summarized the main goals very well. Rishi Devendra states the main steps of the retrospective as:

  • What went well during the sprint cycle?
  • What went wrong during the sprint cycle?
  • What could we do differently to improve?

Following the steps above you will easily have an output with next steps, things to improve and great successful things. That should even be shared with the rest of your team or company, so everyone can learn from that moments.

Retrospective output Example of output after a retrospective in a common perspective.


A fast guide

I’ve learned and got a lot of experience during many years of project retrospectives. It can easily follow this simple and objective recipe:

      1. First of all, the environment
        1. Try to make it happen outside your regular formal environment. It will make people more likely to speak what they really think, and be less resistant to any different opinion that may come around;
        2. Mix it with a meal. Starting at lunch time or finishing with a dinner will help on team’s personal connection;
        3. Why not allow people to have a beer meanwhile? It depends on how your company deals with that. But it’s not a bad idea;
      2. Ice breaker
        1. It’s very important if you have a team that never participated of a retrospective (some nice ice-breaker examples here);
        2. Try some activity that make people laugh and talk about each other at the same time;
        3. The intention here is to make people feel comfortable talking about work outside office and understand the objective of the activity;
        4. Make the main goal of the activity very clear to everyone. Why we are here? What’s the objective? What will we take from this moment?
      3. Now it begins
        1. At this time everybody must speak their mind;
        2. Set up a time limite, like 10 minutes;
        3. Give post-its and pens to everybody;
        4. Write everything that have been happening, both on good and bad ways;
        5. Write about your project, your tasks, your mates, your coampany’s environment;
      4. Let’s discuss!
        The main goal here is to split the good and bad opinions into two different visual areas and, during that, discuss about everything. The whole team must discuss about the topics and it’s everyone’s responsibility to understand the message.

        It’s very common to use some analogies. As an instance, a balloon (where the bad things are the sand bags, that pushes the balloon down, and the good things are the air, which pushes the balloon up). It can also be a rocket (in the same way of the balloon), or even a boat: the good things are the wind that gives speed to the boat, and the bad things are the anchor.

        Activities analogy with a boat
        1. Starting by a volunteer, everybody must speak the post-its that have written and the whole group must discuss about it.
          1. If it’s positive, it’s placed over the wind (on the image above);
          2. If it’s negative, it’s placed over the anchor;
        2. During this activity, when someone is speaking about their post-it, everyone that may have a similar opinion about that subject can interrupt and contribute to the subject and place their post-it also;
        3. The team should discuss about all the topics and understand how does that affect them;
        4. This activity will probably take the majority of your time, and will depend on the number of people who’s involved;
      5. The most important part: action plans!
        1. Now that everybody knows about everything that the team have been facing, it’s time to create the next steps;
        2. For the good things, the compliments FOR THE TEAM are free. It’s not time for feedback sessions;
        3. Regarding the bad things, the team must bring up the most important topics, and create an action plan for each of them. It must contain:
          1. What’s the problem? Eg: The bugs report have been hard to understand and track;
          2. What will be done to solve? Eg: We will set up a new storytelling way to describe the bugs in a way that everybody understands and group it all using a new open source tool;
          3. Who will be responsible? Eg: The main QA professional;
          4. What’s the deadline? Eg: One week starting from next monday, September 1st;
        4. It’s important that everybody leave the retrospective having a mission to accomplish. It will improve the sense of ownership inside the project;
      6. Feedbacks among the team

        The retrospective can get deeper depending on the team’s maturity to discuss about the project and about themselves. If you have an under-construction team, that doesn’t has a strong relationship yet, don’t worry about including this practice. It can be added while your team develops itself.

        But if you already have a mature team, that knows each other and are feeling free to give each other straight feedbacks, it will be very important! A well given feedback among the team will increase the confidence within it, and will make people to work better on that group. Be careful not creating a conflict here. You, as the retrospective leader, must know the limits.


You’re done

After your retrospective you probably will have an action plan for every point of problem. It was you goal, right? It’s very important for your organization and for your way to get the work done for that specific customer.

But the team also gets very important benefits from that. With this practice you will ensure that your team is under a continuous improvement process, and their trustship, ownership sense, and team work are growing.


You can find more useful content about retrospectives, from