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 a we estimating? 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.

Lean Coffee Portugal – Check our new video!

Today I would like to share some thoughts regarding the continuous monthly achievements from Lean Coffee Portugal Community.

It’s impressive to see how much we’ve growth since the first meet up and how every month we have more people attending but most important believing our values and objectives as well as the will to learn more.

Nowadays, we can say that we are only limited by the space provided by our sponsors. I truly believe that if we had more spots more people would join the community.

Nevertheless, some time ago we decided to create a small movie showing the world why we do it, what we achieved and how we do it.

So, today we would like to share with you the final result. Hope you enjoy it as much as we do!

Please feel free to share it!

Most important many thanks everyone for believing and be part of our amazing community!

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)