Browsing Category


Customers, Digital transformation

If you are not investing on design, you’re being left behind

January 9, 2019

In 2015, the DMI released research saying that companies having a design-centric mindset on their strategies grew 211% more than the average of the rest of S&P 500 during the past 10 years (find details here).

In 2018 Gartner, the biggest consultancy company in the world for IT decision makers added Customer Experience as one of the main subjects for its main world-class event (find details here).

Recently, a McKinsey research revealed that companies which invest in design grow, on average, 2 times more than the leading companies of its respective industry (find details here).


Design is already proved

Design, UX, CX, etc already proven itself as something highly valuable. Few years past, it was hard to find examples, but nowadays it’s getting easier and easier to find uncountable examples:

  • Netflix didn’t break Blockbuster. It was the need to return the tapes;
  • It was not Uber who broke taxis. It was the bad service and high prices;
  • Digital banks are not “stealing” large slices of the market share of the big banks. It’s big banks’ lack of transparency and bureaucracy loosing market space for competitors;

People want to interact and will pay more for that, with transparent services. Companies who used to make things confusing so their clients don’t understand are being pushed to change. The UX is the professional who points these issues and transforms the transparency and no-bureaucracy mindset into visible things. Companies are realizing that, and UX is the fifth most demanded profession of 2019 according to LinkedIn.

Why is it still hard for decision-makers to find value on design and afford it?

The same McKinsey report stated that 40% of companies still don’t listen the user’s opinions on their products. It’s like selling a cookie and not asking who’s eating if it tastes good. Isn’t the 211% (by DMI) or 2x (by McKinsey) convincing?

From what I heard this far, I mention these 3 points below as the main for companies to still decide to keep design outside their projects.


Lack of knowledge

Lack of vision of what design can aggregate and lack of eager to know is the main reason. There are plenty of people on IT and business departments still thinking that the old meaning for “web-designer” is the CX professional. Their skills are very different.

DeveloperOld “web designer”CX professional
Does codeDevelops code. Backend and frontend and layoutsDoes not code
Turns layouts into softwareCreates better screens than developersExecutes a long process of research before deciding something will be solved with layouts. Creates layouts that make sense
Commonly thinks about one single application at a timeThinks about one single application at a timeIs always aware of all the interactions the user will have with the product’s brand
Turns layouts into softwareCreates beautiful applicationsCreates applications that make sense to their users and are beautiful if needed

Closely attached to the previous item, if people don’t understand what the UX professional will do, they won’t give value to its deliveries. Then they tend to consider the UX are just more cost on the project to develop and activity that someone else could do.

Fear of innovation

Every leader likes to say they are innovating. But it may occur they start to fear when someone else close to them is innovating more. Since the design mindset naturally brings parts of innovation just because of its existence, I’ve already seen people sabotaging user-centric initiatives.

Customers, Practical examples

A good customer experience performance for sales at financial area

May 7, 2018

This article was written by me, Eduardo Diederichsen and Felipe Lindenmeyer. Me and Eduardo are managers of ilegra’s Software Development area, and Felipe is a senior account manager. We all are connected daily to clients demands.


Daily we do negotiate with a lot of clients. The hardest part is not giving them a price or conducting a good presentation with beautiful slides speaking buzz words. The hardest part is to identify if the potencial clients have a challenge for real and how its challenge can be approached by our company’s potential, language, market vision, and etc. When we find that out, that client will deserve our deep focus to make a good understanding and offer something that fits perfectly to its needs, even if he doesn’t understands it, but then try helping him understand it.


The experience

But what makes a experience as perfect as it must be so a client with sign the new contract? Impossible to tell because who buy from anyone is people. People lay on different things to evaluate their experiences everywhere, giving more weight to different points based on their personality and the influences they had during their whole life.


The scenario

This recent new client had a complete journey from the very beginning contact to signing a contract held by themselves in many companies. At the end he decided to buy from us.

The client scenario

It is a client from financial area, so he knows the financial area customers in Brazil are very demanding regarding the whole UX and the products flexibility. Brazil is the country with most developed User eXperience demand in entire world, so the competition and investments here are huge.

First contacts

What happened: the first contact happened in a casual party, not related to work. The subject on the crowd turned to work. We explored very briefly few examples of how we are helping some important companies in Brazil to be in front of their competitors. What really happened: The attention was caught and visit cards were given. Few days later they asked a meeting to talk about our portfolio and get to know their requirements and concerns.

The meeting

What happened: it happened at customer’s facilities. The goal was, as they asked, to talk about few scenarios we’ve been working and the opportunities we identify and foresee as experts at the market. What really happened: they understood we had the knowledge to be their partners and if they count on us they would have oppinions of a specialist in their market. So the next step will be send a proposal and everybody celebrates? Yes, but not so fast.

The challenges
  • FIRST! What happened: they are a very conservative Brazilian firm which still isn’t enrolled to digital transformation practices and doesn’t even want to get to. We are very used to work based on agile methodologies, Lean approaches, testing and discarding losses very quickly. They wanted everything predictable with very clear goals and steps. What really happened: they understood that their competitors don’t work in that way anymore and that working that way they would still be left behind in the competition scenario. Then we reached a mix of practices that would give them part of the control they were asking but giving the project part of the freedom that kind of work needs.
  • SECOND! What happened: they told us they wanted to be in front of their competitors knowing how much it would cost and how many time would take. Well, if I knew that, I would be one of the competitors. And that’s where the Lean and experimenting mindset gets the attention. The startsups bothering giant industries don’t have this kind of answers. They won’t have it too. What really happened: we decided to go for a first deliverable (We can call it an MVP) and a further evaluation after that to redesign the plans.
  • When things got warm: What happened: we had the steps above but it was taking too long for a decision and things got warm (bad news). Our decision was to invite them to come to our company’s headquarters to see with their own eyes everything we were discussing. They really got impressed with our office because it’s designed to give freedom to people think and innovate. This was a key step because they spoke to people who would actually work with their project. What really happened: the deal got hot again.


What is faced differently by everyone

There are a lot of subjective things in the explanation of the sentences above. I’m not exploring their body language, neither ours. I’m not exploring the sentences we told each other and how did we look during the meetings. So, I’m not telling how we created empathy here. Let’s get to things close to that.

The client scenario

Some companies can be afraid of innovate. It’s a whole new scenario. People fear the unknown. They don’t know what is coming and then they get afraid and just stop. For other companies, the unknown is exciting and they know from there the innovation will come. They will seek for it as a routine.

First contacts

Since it happened in a social event, the thing was easier. The focus was not evaluation. The empathy came easily because we spoke about our cases in a brief (not moving the whole night focus to work only) and humble way. If we were too thirsty about their needs it could turn into something boring and we could lose that guy’s attention.

The meeting

The meeting was all about showing our capabilities. With that being flexible to understand their concerns about models and what we were proposing. At that time we invested some time explaining and desmistifiyng software development practices like Dojos, Meetups, team management models, our concerns about quality (A/B Testing, Chaos testing, etc). And at that time a big thing happened: the empathy with one of the guys was so huge, he found so many value, that he started defending some of the approaches to the sponsors in a very enthusiastic way.

The problems

We had to use a lot of knowledge to tell them the differences between the way they were approaching the problem and where we see the market moving to. It was hard work to understand how they treat projects and mix it to a reality we could work being sure we would reach the results both of us were hoping regarding the new partnership. But the biggest step taken was the use of the experimentation mindset to go for the first phase. They wanted to give a shot at our suggested model. That’s the chance we had to keep things going well so we would build more trust.

When things got warm

It was the dangerous part. Calling and bothering client’s patience wouldn’t have been the efficient approach. Bringing them to a controlled environment was a good move. Sometimes people don’t get everything you say when you are presenting something. You will have to repeat it in order to get the perfect moment where your explanation will make sense to them and then their attention and interest will be caught.


Being more generalist here with a few more examples

One customer may like to hear to most recent buzz words all pronounced in english. Another client, coming from countryside may not like it because he thinks it’s something for bigger companies. The proposal: one customer may prefer a document with a set of beautiful images in a more abstract way. Another customer may prefer to receive a one page document getting straight to the point using just text. It’s unpredictable.


Good! How can I learn with this scenario?

The CX (Customer eXperience) gets more challenging to achieve when we are talking about B2B or B2B2C offers. When you have a B2C scenario you probably will have one person at the edge who you have to please with your offer and your advantages. It’s easier to ask him: “hey, did you like this new feature?”. Getting back to B2B or B2B2C the variables are countless, since you will have to deal with many people from the very beginning of the negotiation until reaching the final contract signed.


How to attack that efficiently?

Short answer: be interested. Long answer: keep the knowledge with people involved, get experience, and be interested about evolving in the process and the learned lessons. Try to understand things about body language and psychology, do know the one who is buying from you. Does that guy writes publicly? Does he give speeches? What is he speaking/writing/reading/hearing/studying that you can take in count to set up a moment for a fast approach?

Customers, Digital transformation, IT is business, Practical examples

Software buying process on IT evolution

February 14, 2018

The more different views you have about the same subject, the more information you will have to take your conclusions and make decisions if needed. This first article about IT evolution had a sight from developers and a very superficial business view. This new article aims to look from the perspective of clients buying software and how they are different even inside the same industries.


How software used to be bought

In past years, companies used to buy software like any other commodity: I want 5 cars with 4 wheels each, manual transmission and white painted. They didn’t mind on how their software is produced, or any kind of good practices to apply on the process. Yes, inside the software requirement documents were sections regarding security, protocols and things like that, but at the end of everything, the lowest price would win.


Old (not too much) decision matrix

The decision matrix (example below using a car buying process) were very simple when selecting the criteria. They were also superficial. The high level criteria were easily like: security levels, performance, proposed schedule, price, scope coverage, success cases, knowledge on selected technology, etc. With this decision matrix, the weights are given according to each project. But the price and schedule, after all the criteria evaluation would still determine who wins.

On the example above: what exactly is comfort and styling for this buyer? Safety can be evaluated using governamental public data. This is a parallel to show how none of the criteria is detailed.

Anyone saying that could cover the entire scope, under the asked schedule having a fixed amount of money could win the fight for the projects. If they didn’t have knowledge enough, it wouldn’t make huge difference. After everything, software was treated like any other product. It doesn’t matter how it’s made. It just matter that it works.


Recent decision matrix

Leaving behind government industry, and few others not affected even a bit by digital transformation, the reality has been changing.

What I’ve seen lately is an increasing spend of time on detailing the criteria. For each of the criteria, the buyers want to know what the supplier have already done, how they plan to conduct the solution and also want to evaluate alternatives for everything.

  • Security: ensure the information exchange will occur under a controlled environment? Tactics for code obfuscation. Platform natural security concerns. Cloud provider certifications, etc;
  • Schedule: from “a detailed schedule” (which is never achieved) to “a macro view of time and a mix of agile methodologies to be followed”;
  • Success cases: show where/when similar solutions were already created;
  • UX:  from “the system has to have good usability” (completely subjective) to “it must follow UX guidelines from Google and be conducted by a specific professional, not by developers”;
  • Performance: from “the system has to load under 10 seconds” to “each endpoint must answer under 2 seconds”;
  • Scope: from “do everything desired” to “let’s do the most we can inside the schedule”;

The companies want to know how their project will be conducted in details, and they also want to put their opinion on it. Since the digital transformation is making companies to turn their core into IT, the IT is not a support anymore. So now they are able to suggest things and to talk at the same level of the consultancies.

With this comparision and evolution scene, the MVP mindset is very clear. Also the goals to achieve faster time-to-market and faster revenues.


Different requests inside the same industry

The report above is true for 100% of companies on the most mature industries in Brazil. But for the rest of industries, using retail as an example, it’s not:

There are stores who are already evolving their ecommerces for security, performance, scalability, stability and the most important: user experience. But there’s also those who treat their online stores as something needed. Is common to copy layout practices from concurrents. Also, security is expensive. Then some companies have a budget to lose due to hacker invasions, instead of investing to security.

The good news is that the market is evolving faster and faster. Soon no industry will be behind.

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.

Customers, Practical examples

Status report – A practical model and example

January 1, 2018

Status report is a very powerful tool used for many different subjects and intentions. This practical example brings a real scenario created by me few weeks ago and shows an approach to pass the message to people that matter.

The model is presented below, and all the sections are also described after it, showing what is the intention and why it makes sense to this scenario. It’s AVAILABLE HERE (english and portuguese) and is free to be used in your projects.


The model


Identification, project manager, objective and date

These four sections are very important to ensure everybody who opens your file know exactly about what project you are talking about.

  • Client X – What is the company paying and interested in your project? It’s important to you and any other people inside your company to understand;
  • Project Y – What’s the project name? It’s the identification to whoever may receive this file to understand its purpose;
  • Project Manager – Who is responsible for this project? On all sides that matter to you. In this case just my company and client’s were important. You may add other suppliers as an instance;
  • Objective – Your main goal. It’s important to keep focused. Since it’s a file accessible to everybody on the project, everybody must understand to what they are contributing and feel part of that;
  • Date – it shows the period the file regards. Keep track of your status reports! This will allow you to know your progress and things you have already tried to do, and how they are going;


Status, logos and deadlines
  • The overall status is an executive information and to where everyone will take a look. It’s a simple message showing how your project is going on. It’s not what you think is happening. You have to have numbers to set it. In this document we used 3 KPIs (explored below) and the rules are: if all of them are green, the overall is green. If at least one is yellow, the project is yellow. If anyone is red, the project is red;
  • The logos (yours and your client’s) have an important message about the partnership responsible to conduct this project. It passes a subjective message showing to the whole team how the two companies are engaged to reach the same objective;
  • The original deadline is the first planned date to finish the project according to the schedule;
  • The replanned deadline is filled only if you had to replan your deadline for some reason. The reasons must be shown on the updates (explored below) when a replanning happens;


Risks, changes and dependencies

Whatever happen to risks and changes must be checked by you, as the project manager in charge, to understand if it will require any kind of replanning. It can affect your schedule, your costs, people involved, external resources, suppliers, etc;

  • Risks is where you list everything that may affect your project and make something planned to change. It’s common to be something out of your control, so have a plan to each of them to deal with problems when something go wrong;
  • Changes must be filled when something relevant arranged was changed for some reason. A decision was rethought? Make it loud;
  • Dependencies section is used when you have tasks depending on someone else’s effort. It’s very important because if they are delayed, you will have to deal with the impact;

The example has a dependency with a strikethrough deadline. It’s meant to show that a planned deliver was not finished and was replanned.

There is also a dependency with a deadline painted red. It regards a task that must be performed by someone outside the original project’s team. It must have a person responsible and also the date when the deliverable will be available. If that task is delayed, the whole project can be delayed.



This section is the one which will have a high rate of information change from week to week. All of its content can be changed from one week to another. Here is where you list everything that happened, new people added, results of tests, deliveries from another suppliers, and etc. I also like to keep two sub sections: what was finished during the last week, and what will be done in the next.



The schedule makes sense when you are dealing with a project with fixed scope, and also when not. You can use it to make things visible about the next important deliver, when talking about agile. You can show macro deliveries or show 100% of your whole planning process (as the example shows).

It lists macro tasks, and gives them colors:

  • When green, it’s ready to be developed;
  • If its orange, it depends on something external and can’t be started now;
  • For red, it means it’s delayed for any reason;

It also shows the tasks planned to be delivered during the current week (orange painted on the first line of the table). It’s represented by the X on the respective cell. And at last has the percentage of each one of the tasks;



The things you decide to measure during the project. For this one, people, scope and dates were the main things. The table shows the metric and the status for each of them. Whenever you have something different than green, you have to write a reason telling why it’s not going well. Do not forget to add the costs to this KPI section;

Avoiding problems, Career, Customers, Practical examples

Communication issues? Maybe it’s engagement issues

December 24, 2017

I started thinking on this article as my self year’s end retrospective. And I realized the biggest thing I learned during this year regards engagement.

I’ve been hearing, for years, that “80% of the projects that fail, fail because of poor communication”. That’s a sad true, but this year I realized this is an easy but messy abstraction. When you say that communication is the problem, you are hiding many serious problems, not only in your project, but also in your organization. And after that eureka moment, a new one came: people do “communicate the proper way” if they are engaged and have support to develop themselves.


Some examples
  1. We have a contract to watch an online app. It’s not very critical, but we still have SLAs to accomplish when it’s down. Then one issue comes and the person from OPS forgets to tell the customer, during the first 15 minutes, that he’s looking for a solution. Beyond that, he takes one more hour to solve the problem, than the 4h regularly expected. It will cause an argument during a meeting between the managers and everybody will finish the subject saying that they had a communication issue;
  2. We evolve a very critical solution, that deals with money, to a customer. Then the developer didn’t create the automatized test and the app breaks when goes to production. It will cause an argument during a meeting between the managers, and everybody will agree that the QA guy didn’t communicate properly to the DEV guy about the missing test.
  3. The project manager tells the project is delayed, but doesn’t tell how much it is. When something goes bad and someone ask for it, he defends himself saying he told about the delay, and had an interpretation issue because those who read didn’t understand the message he wanted to say. Then after that meeting, everybody will agree that he haven’t communicated the right way;


Why these things happen

What I learned during this year, regarding engagement, was to identify why these examples happened:

  1. The person from OPS team didn’t tell the customer he was working at the first 15 minutes, and forgot to tell he would take one more hour to solve the ticket, because he was not well empowered of its position. He doesn’t understands his position. If he forgets to tell the customer about the down time, the customer won’t be able tell the users. The users will start calling the call center, and it will generate an overhead on the call center team. So at least 10 people will have more work to do, forcing the company to pay for that extra hours, because of one missing news. The person from OPS wouldn’t have forgot to tell anyone needed if he truly understood the scenario.
  2. The second example has nothing to the QA. The responsibility affects the developer. He hadn’t created the test because he doesn’t know that every one hour of that system stopped, makes the customer to loose US$ 10.000,00. Nobody, when old, will want to tell stories to their children like “hey, once I stopped the production environment, and screwed many people’s life”. So the developer was negligent about the test because he is not well empowered of its responsibilities and capabilities.
  3. The project manager will is not to hide information. He gets paid, essentially, to keep people informed. When he waits one or two months to say the project is delayed for 2 months, he doesn’t think the people from project will be needed in a next one, and it will cause a loss on the company. Since people won’t be available, the original project’s budget won’t be enough, and the whole company will spend more money to hire new people to the next one.

So if you are inside any of these examples, think on the other side as your true friend. Would you let, any of these examples to happen, if you knew how deep it would affect them?


Solving the wrong way

It’s easy to put all these problems inside one basket and label them as communication issues. Then, our technical minds will think about processes to guarantee that:

  1. The tickets system automatically send and email telling the customer we’re working to solve the issue;
  2. We will create an integration between the task acceptance tool and the code repository to check if all the tasks have at least one test designed;
  3. The project manager will always present the status report having the customer on it’s side, so no information will be missed again;

The suggestions above are not wrong and shouldn’t be faced as something to be avoided. But they must be the last alternative. They are all mending to lack of people engagement.


Solving the right way: build together

People tend to be good. When you share the right way their responsibilities and how their activities affect each other, they will feel inside the group and will always try to help everybody. So why not asking each one of the actors of these examples how they would solve the problem? Present the problem, tell everything that happened because of their behavior. How to solve? This is the most difficult part. Probably the first thing coming from them won’t be the perfect solution or the solution you thought. Then it’s time for to show a better solution and check if it makes sense to those who will put it in practice. A mix of the ideias can be a good start.

And now we talk about people’s maturity to solve problems:

  • If they are junior people with good potential, just letting them to know their responsibilities can solve the problem. They have good intentions! They won’t forget to tell anybody the next time about what’s happening;
  • If they are overwhelmed, you will advice about looking for self management tools. And also will help them to focus on what is important and not getting overwhelmed again;
  • If you realize its needed, why not using one of the process solutions described above as the wrong way? Take care because if must make sense to everybody affected. It depends on people maturity to not feel pushed;


The main goal is to look for a mindset of empowering and networks, as described on the image below:


Always have next steps

Once I was invited to join a retrospective. The goal was to help a team with an external vision so they could improve their processes. The first thing I asked was where the “next steps” of the previous retrospective were. For my surprise they weren’t.

Always keep track of goals and results. It gives you sense of improvement, and if it doesn’t it will be clear to find where new mistakes were made. Have a periodic checkpoint with each one of the scenarios above until it fits a track where the problems don’t happen again.

After that, when you have the whole solution, you will be able to share your good practice to other teams around you:

  • What happened; Why happened; When happened;
  • What did you do to solve it, what were the first trials, and what actually solved it?
  • What did you learn from it? Next steps;
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.