What is the best way to influence, based on my experience

Today I would like to share with you a few thoughts about the best way to influence others, based on my experience.

To give you more context, yesterday I came across an article with a very interesting quote from Albert Einstein saying:

“Leading by example isn’t a way to influence, it’s THE way to influence.”

This quote got me thinking, so I carried out a quick retrospective of all the leaders, managers and peers I came across during my career. The aim was to identify which was the most important characteristic that made them great influencers.

As you know, we live in a world of constant change and it’s vital that we keep inspecting and adapting to succeed from a business, professional and personal perspective. So, why is it that, with all our current resources (e.g. Training about Coaching, Influencing, Mindfulness, etc.) influencing others can still sometimes be so difficult? After all, we are already spending most of the time actively listening and communicating with people to influence them (The Art of Influence: Lesson 2 – Listening & Communication Skills).

What is missing to become a great influencer?

My personal belief is that the best influencers I have worked with (following Albert Einstein’s criteria above) were always the ones that led by example. The ones that didn’t ask or try to influence without doing it themselves. Can you ask a single person or a group of people to change or do something if you don’t do it yourself? Is it realistic to expect any behavioral change if you are not the first one demonstrating and giving the first step? How do you think they would see you, what would they think or how would they react in the long run?

For me, the best way to influence and create a huge impact on my day to day work is to show the strength of my convictions by doing myself what I would like others to do; e.g. Changes/Attitudes I would like to see in others.

One great example of influencing by doing is when working with non-development teams and convincing them to adopt Agile. Why I am saying this? Because non-technical teams’ common reaction will be “We are not developers and this doesn’t work for us!” At that moment, what I do is just showcase how my own team works (since we are not a development team) and help them see how adopting Agile could make their day to day work easier. After a few moments, they are the ones saying “Wow! Can we do the same? Can you help us?”. In the long run, the results are stunning and their feedback is great with the will to improve more.

Another example is how my team works, and our overall level of trust and commitment. It’s normal for a leader to provide feedback and challenge the team as well as team members. In our case, they know they can do the same with me. It took some time to build this level of relationship, but nowadays if we need to put in place any action or deploy any workstream, we challenge each other, and even if the solution is not the one initially proposed by me, I will be the first one doing it. This creates a sense of high engagement because they see me as an example.

So what made you be a successful leader? Why not share your experience on how you made it and why you think it worked? It would be great to hear your thoughts even if you don’t agree with this approach.

#Agile #Lean #Leadership #Influence #Change #ContinuousImprovement

Today’s Thought on Leading Change

While watching a training about Leading Change by Britt Andreatta where she shared an amazing thought that I totally agree with her. This is something that we need to keep always in our mind and that besides applying to driving change teams also applies to any team.

“If you deliver what you promised you build more trust to future change initiatives. If you don’t you have a more challenging run. So, listening to feedback is really important.”

Don’t forget that the real impact is very important to your team reputation.

#Agile #Lean #Change #ContinuousImprovement

What Is Agile? The Four Essential Elements by Steve Denning

Today, I’ve come across with this great article “What is Agile? and The four essential elements by Steve Denning” that I would like to share with you.

As you know Agile is with us since 2001 and the question that is made is:

  • Is the Agile definition the same as in 2001 or did it evolved across time?

Also, more and more we see companies with the will adopt Agile or being Agile, still, there is a question that I believe that is in many people heads that is:

  • Does the company understand and agree on what Agile stand for them?

Maybe by answering this question, we will be able to have the four essential elements that the article is talking about:

  • Delighting customers
  • Descaling work
  • Enterprise-wide Agility
  • Nurturing culture

Having said this, please find here the article link for more details:


The Agile Coaching DNA by Manoel Pimentel

Following my previous article “Agile Coaches Myth or Reality?“, today, I’ve come across with this great article “The Agile Coaching DNA by Manoel Pimentel” that I would like to share you.

It’s really interesting since provide a well-detailed explanation and context about Agile Coach role and the day to day basis work.

Having said this, please find here the article link:

View at Medium.com


Was with great pleasure that I found out last week 18th of April 2017 that:

“On behalf of the Agile Portugal 2017 organisation, we are glad to inform you that your submission, titled

Startup vs Enterprise Estimations – Two warriors with swords!

was considered relevant and interesting, and based on its reviews (quality, relevance) it was ranked high enough to gain one of the slots for this year’s conference. Congratulations!!!”

We (Cornelius Engelbrecht and me) are really happy for being two of the speakers at this conference.

Also, learn with everyone!

See you there 😉

Startup vs Enterprise Estimations – Two warriors with swords!

It’s interesting how we can learn and evolve by having great conversations. Conversations where we can share same or different opinions.
This was one of those cases…
Some weeks ago, during a coffee break I was talking with my great friend and work colleague Cornelius Engelbrecht. We started to share some past coaching experiences from previous companies, teams and the controversial topic of estimation.
This was the moment that we both agreed that we should share our thoughts and write about Startup vs Enterprise Estimations and why this can be “Two warriors with swords”.


“Our faces (Eduardo Ribeiro and Cornelius Engelbrecht) as soon we agreed to share our thoughts and write about this topic since is very controversial.”

As starting point, we would like to give some context and have everyone in the same page.

Nowadays there are two popular communities regarding estimation whom are perceived to have opposing views (The Swords):

View A
On the one hand you have where its believed that estimation (guessing the size of a piece of work) can be useful and helpful with the following:

  • A trigger for valuable conversations which help create a shared understanding within the team.
  • To help the team to understand if the work needs to be broken down into smaller pieces to help reduce risk and complexity.
  • If a team is using Scrum, then it can be a guide to taking on too much work in a sprint.
  • To help us (Team and Business) in predicting/forecast when something will be done. Still, this topic is dangerous if not understood by everyone that an estimate is a guess/prediction and you cannot commit to a guess.
  • It can help with prioritisation of work (e.g. deciding between something that should return high value and take little effort to do, and something that should return less value and will take more effort – its an obvious example, we’re sure you get the point).

View B
On the other hand you have a more recent approach where people believe that we don’t need to estimate any work items, since the team has enough maturity to break down these items to a level where all of them are the same/small enough size (usually can be done within a week). Then you simply count the number of work items and then work on the most important items first. Using this approach you should be able to solve the same problems as in “View A”.

You might be asking… “What option works better and why?” or “Are they not trying to do very much the same thing?”
Well… when the #NoEstimation community started, their objective was to not use any estimation. For several years they shared their belief, and with time passing we started so see a change of opinion from no estimation to high level estimation using T-Shirt sizing on pieces of work that have not yet been sliced down to the smallest size.
What happened to have this approach change? Its unclear without more data or input from the community. By using high level T-Shirt sizing, are you still in the #NoEstimation camp, or are we are estimating? What do you think? ….. Or do you have a different experience with #NoEstimation? -We’d love to hear your experience.

Consider this: Since the beginning of ages we’ve used estimation to help make decisions and predictions. This is not an argument for estimating being right or wrong, we’re merely pointing out that its part of our nature.

For example: If you had an important meeting in another country and didn’t guess (estimate) how long it would take to get to the meeting (how long it would take to get to the airport, fly to the other country, then get from the airport to where the meeting is held).


How would you decide when you should leave, which flight you should take, what method of transport you would use to and from the airport, so you would arrive on time to the meeting?

We’re trying to point out (pun intended) estimation can be helpful and might make sense in some situations, even at work. Don’t you think?

Now it’s time to return to our main topic “Startup vs Enterprise Estimations” and why we think that are “Two warriors with swords!”.


Picture graciously provided by João Vale.

Warrior 1 – The Startup
Let’s look to a standard Startup where they have maybe a couple of teams and they own their product.
When we have this kind of start up at the beginning that have only one idea and they start developing their MVP.
So, they start from scratch (Idea) and they start developing where every iteration they deploy small value to their customers, gain feedback and incorporate the feedback in the next increment. Their objective is to evolve their product MVP to what their customers need (based on their feedback) and release as quickly and frequently as possible.

  • When would a Startup find estimation valuable, why would they estimate:

When a Startup is not only driven by getting their idea out to their customers as soon as possible, they also are driven by need to know if its achievable before a date outside their control (e.g real world events such as SuperBowl or any other event or investors conditions). Therefore these Startups have to be more frugal on how and where they spend their money. To ensure they get the most value & return on what they spend and therefore can grow, estimating their work and including the value the work will return, will help them to frequently re-prioritise what to work on next – effectively shaping/changing their roadmap based on their customers needs. Think of it as a small boat that can quickly change their course/direction with minimal impact and reach their destination at the right time.

***As an example Tesla needed to get their first car (Roadster) out by a certain date, otherwise they lose their investors funding by losing confidence & trust in Tesla´s ability to deliver.

  • When would a Startup find no estimates valuable, why would they use no estimates:

When a Startup main drive is to get their idea built and into their customer´s hands as soon as possible, it does not depend on a specific date… just as quickly as possible, then using the #NoEstimates way will make sense. This is where you slice the work into the smallest possible pieces (fitting into a week or less), incrementally and iteratively working on the most important & valuable piece, and just count the pieces of work to get an idea of where you’re going. This is still the small boat that reaches that can quickly change their course/direction with minimal impact and reach their destination as quickly as possible.

***As an example when Elon Musk created SpaceX, his vision was Mars colonisation. Of course he would want this as soon as possible – and if it could be by tomorrow then it would be great, however it is not need to be by a certain date, just as soon as technically possible.

Warrior 2 – The Enterprise
Now it’s time to look to a bigger “Beast” aka the typical Enterprise where we have many teams, departments, locations, cultures and have several products being developed simultaneously whilst keeping investors trust in confidence in our ability to deliver.

  • When would a Enterprise find estimation valuable, why would they estimate:

Most Enterprises have the added complexity of co-ordinating multiple teams delivering multiple products across multiple locations and multiple platforms (… you get the idea) whilst being subject to Marketing campaigns that are prepared for release on specific dates that can be Online, Newspaper, TV, Radio, etc… and which are connected to real world events such as a Superbowl (once more… you get the idea of complexity).

Estimation help create a shared understanding in the teams regarding the work, promotes conversations which leads to the discovery, and help make decisions on what to do due to the cost/value and return.

Estimation can also be helpful for Enterprises to forecast when something can be done, in guiding decisions when co-ordinating teams/deliveries/products and their inherent dependencies whilst adhering to governance and regulations. They would still break down work into smaller pieces, and prioritised the most important/valuable work first,however this priority/order is influenced by synchronisation of many parts of the system(teams/products/needs). By estimating and knowing the effort involved you can take smart decisions and plan your roadmap and the co-ordination required by the many different parts of the system to deliver by a forecasted date.

This is not a small boat that can quickly change their course/direction to reach their destination (think oil tanker…).

  • When would a Enterprise find #NoEstimates valuable, why would they use no estimates:

In theory when an Enterprise could use the #NoEstimates way when they have completely independent products with cross functional teams/departments working on goals that are independent and not driven by external markets and/or events. Unfortunately we don´t have much data or any examples of where this works on Enterprise organisations – If you know of any please feel free to share this with us/everyone, we’d love to learn from you!

For our final thoughts:

If you pay attention you will notice there is a small battle happening between #NoEstimates and Estimates, and these are the two swords each warrior has, and the Startups and Enterprises are the warriors.

We hope you realise these are two different realities and we shouldn’t blindly support the one camp or the other and apply the same approach to a Startup and to a Enterprise.

Keep in mind that this can create a higher risk and create bigger issues rather than fixing it. These approaches are not Silver Bullet´s to solve all the issues you are experiencing.

So, before taking any decisions is important to understand both sides and not just join this battle with your decision made.
One needs to have a good understanding on #NoEstimates and Estimates in different business realities and what benefits or impacts they can bring.

Ask yourself why we estimate? What problems are we trying to solve with the estimates? Are we trying to solve the right problems?…..

Katherine Kirk : Navigating Politics in Agile/Lean Teams

One of my work streams from my day to day work is catching up with stakeholders to get their view/feedback on what could we improve to become leaner.

After doing my diary catch ups I’ve realised that one of the topics is always present is politics and the issues that politics can bring.

So, as a result I checked my memories and I would like to share with you one of the best talks that I attended two years ago in the Lean Agile Scotland by Katherine Kirk.

It’s very interesting to see her thoughts and how she approaches this subject.

I hope that you enjoy watching this talk like I did.

Time! Why everyone is so afraid of time?

To give you some context on the 11th of March I’ve attended the Conference Agile Mammoths Games in Cluj-Napoca (Romania) where I had the pleasure to reencounter Katherine Kirk.

During one of the many interesting subjects that we discussed one that stood out was time and why people are so afraid of time.

In the end of our discussions was really great to be challenged by her to write my thoughts about this subject. So, here it is!

Its really interesting the connection/dependency that we have as humans with time even when we try not to think about it, our subconscious take us there.

As you might know and since the beginning of times we try to mesure everything using time and it works when we are talking about production lines where we always do the same thing and we know exactly how much time takes for each piece of work or any other type of work that we can say that is recurrent. But when it comes for people and intellect unfortunately this doesn’t apply.

So, I would like to start with a quick question where you ask  yourself:

“Why do you think that everyone is so afraid of time?”

Screen Shot 2016-03-23 at 11.19.34

Let’s start with some of the scenarios that I’ve encountered during my carrear.

Nowadays most of the people/companies see Lean Agile as a Silver bullet that will sort all their problems. Worst than that is when they still don’t know that problem that want to solve. So, in order to improve they expect to change in a pre-establish period of time that don’t work quite well. You might be asking why? The answer from my perspective is simple.

Mentalities and culture!

Changing a individual person, team, business mentality is not the same as changing a process. This means that takes time. How much? We can’t know in advance.

So, why many people say that they can change a team in two weeks or a business way or working to be more Agile in 6 months?

First of all we need to understand the backround, mentalities and culture that we are dealing. Don’t forget that most of the time the people that are resistant to change that have a reason/concern behind.

We need to keep in mind that change takes time and that each case is a different case. There is no magic formula meaning that what works with one person, team or business maybe will not work with the next. What we can do as Change Agents is help them to understand this concept, be at their side all the time. Don’t forget that change is a continuous and never ending work since we have always space to improve.

Screen Shot 2016-03-23 at 11.58.29

The other topic is delivery. Again we have time involved. We need what we are building (specific feature) in a specific date. What is most interesting is normally we need the full feature.

Again, I understand that we need a forecast since some of the times we need to coordinate with marketing (Possible TV campaigns). So, how do you think that we could short this out and free people from being afraid or time?

I believe that you already know the answer. MVP! Why should we be afraid of time if we have the chance to deliver MVP. By using MVP aren’t we able to deliver what the costumer/user really want in the pre-establish period of time? Better, aren’t we able to adapt to achieve this forecasted date or negotiate with the customer?

Screen Shot 2016-03-23 at 11.59.16

In the end I’ll keep doing this question to my self “Why everyone is so afraid of time?”

Now its my time to raise a challenge to you. Would be great to hear your thoughts and pass experiences about this subject. 😉

Agile Coaches Myth or Reality?

This article is really interesting since the subject to write about this was born during one of the Lean Coffee Portugal sessions when someone raised the subject/question “What is a difference between a Scrum Master and an Agile Coach?”.

Meanwhile, seeing as this can potentially be a long and interesting debated subject after chatting with my colleague Cornelius Engelbrecht  I decided talk with him if he would like to accept the challenge. That he did 😉

So, we would like to start with a quick question where you ask  yourself:

“What is an Agile Coach? Are they a myth or reality?”


The reason why we are asking this is because we can say that Agile Coach is a recent role and when we say this we are talking a few years and not like Developer or Project Manager that are with us for a long period of time.

Also, we think that we have people that are confused regarding the role definition and what are the best characteristics for a good Agile Coach.

To start we want to give you some context behind our opinions. We are not sure if you realised that nowadays everyone have on their LinkedIn, CV or role Agile Coach. But do they know what is the real Agile Coach role?

Well… We can say that we became curious, so we started to dig and get more information around the label Agile Coach. Our first approach was discuss this topic with a lot of people around the world and by coincidence or not, we had the need to also hire Agile Coach’s for my team.

What we discovered was kind of funny. Well… Not funny but curious.

  • People that updated their role after reading Agile books.
  • People that use the label on their current role even what they do is not related.
  • People that use the table Agile Coach since they don’t like the name Scrum Master.
  • People using the table Agile Coach since in Kanban there is no Scrum Master.
  • Role updated just to apply to a job without any experience.
  • People who collect certifications to prove they are a Coach.
  • The main reason we see is people that updated their role because everyone is doing it (Buzz word from the moment).

So, we would like to return to the question made during the Lean Coffee Portugal session by providing the definition of what is a Scrum Master and as you can see we don’t need to invent the well since is already well defined as we can see by the Scrum Guide definition (image below).

SM Scrum Guide


Now let’s have a look at the Agile Coach role from our perspective:

An Agile Coach helps individuals/teams/departments/organisations so they can become better and be proud of what they do.  One does this through being a guide & change agent who applies Lean/Agile/Continuous Improvement practices which are relevant to people’s journey.

Attributes of an Agile Coach:

  • Great listener
  • Patient
  • Impartial
  • Humble & always learning
  • Respectful
  • Not so much directing, more guiding (i.e. helping people find ways/answers not giving answers)
  • Non-judgemental
  • Fearless (i.e. able to communicate  with confidence at all levels in the organisation be it CEO, management and team members)
  • Flexible (“being able to think outside the box”)

Quick re-cap:

Scrum Master is mainly focused on guiding one/two teams (including Product Owner)  in using Scrum.  Agile Coach is a very different role whereby he/she has a wider organisational view when coaching individuals/teams/organisations on improving (becoming better at what they are doing) whilst using Lean/Agile/Continuous Improvement practices.

Why did we want to become an Agile Coach?

Funny enough we did not know we wanted to become coaches, what we wanted  is to improve our ability to help people in achieving more.  We started to look into why people understand, react, how they learn, absorb and believe in what they do and how to embrace change  – this is where it began for us…


Could a Rugby player be a good Scrum Master? Let’s see what happens…

Today’s post is related with Scrum Masters. Well, in this case with a specific type of Scrum Master.

You might be asking why I’m writing about them, since I never wrote anything related with Scrum Masters. Well… Today I have a funny reason.

Today, I had a friend from work (Melvyn Bulkes | Agile Coach) that during our coffee break he said that he would like to share with me a really funny video about a crazy Scrum Master that he found on Youtube. At the beginning I didn’t believed him until I saw the video that he was talking about. The video was so great and funny that I decided to share with you too.

So, to start I think that we need to know the origin of the word Scrum.

“A Scrum (short for Scrummage) is a method of restarting play in rugby that involves players packing closely together with their heads down and attempting to gain possession of the ball.” [1]

And since we are talking about Scrum and Rugby, what do you think that could happen if we had a Rugby player as Scrum Master?

Let’s see what happens…

Did you enjoy the video? Now I have a quick challenge to you that comes down to one question only:

  • What do you think about this Scrum Master? 😉


[1] Wikipedia | Scrum (Rugby)