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

Excalibur

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? 😉

References:

[1] Wikipedia | Scrum (Rugby)

 

Lean Coffee Portugal first year Retrospective

Today’s post is related with the Lean Coffee Portugal Community and the first full year retrospective.

Logo Portugal

In order to give you some context, more than one year ago to be more precise December 2014 a group of 4 people started a community (Lean Coffee Porto) with the following mission, objectives and values:

values-color

After few months and with the continuous success was decided to embrace a new challenge and start the Lean Coffee Braga.

During this time something magic happen. We started to have more and more people committed to keep making this a success every month and with the motivation to make this community growth at a fast pace.

So, today at less than one week for the next Lean Coffee Session (28th of Jan at Blip) I’m happy to share some numbers that I believe that shows everyone feedback about the community.

Screen Shot 2016-01-23 at 13.43.53

Screen Shot 2016-01-23 at 13.43.35

At this point I only have one final question. 😉

Are you joining us in the next session in Feb 2016?

If yes, see you there!

SGRIO2016 Brazil :: TALK Why for Some Product Owners and Stakeholders Agile is Like Crossing Over to the Twilight Zone

Today it´s really my day!

Is with great pleasure that I found today that:

“Nós recebemos muito mais submissões do que os 42 slots disponíveis para o evento e o processo de seleção foi extremamente difícil e cuidadoso. Foram 5 submissões para cada vaga.

A equipe de revisão das sessões do SGRIO2016 usou critérios como relevância do tema, experiência do palestrante, conteúdo proposto e alinhamento com as expectativas do evento, entre outros. É sempre importante ter um equilíbrio na quantidade de palestras por trilha e naturalmente algumas trilhas são mais concorridas do que as outras, o que torna o trabalho do time de avaliação ainda maior. Após algumas rodadas de votações, chegamos a uma lista final com as 42 sessões selecionadas.

PARABÉNS, sua sessão (Why for Some Product Owners and Stakeholders Agile is Like Crossing Over to the Twilight Zone) foi selecionada para o Regional Scrum Gathering Rio 2016!”.

Know the sort translation:

“CONGRATULATIONS , your talk (Why for Some Product Owners and Stakeholders Agile is Like Crossing Over to the Twilight Zone) has been selected for the Scrum Gathering Rio 2016!”

I’m extremely happy to be one of the speakers for the SGRIO2016.

Nevertheless, now is time to start working and find sponsors for the trip 😉

Agile Mammoths Games 2016 Cluj-Napoca Romania :: Talk Agile Champions the new Change Agents!

Was with great pleasure that today I was invited to present my talk “Agile Champions the new Change Agents” at Agile Mammoths Games 2016 Cluj-Napoca Romania.

The conference will be on 11th of March 2016 and I’m really happy to be one of the speakers for this conference. Nevertheless, share and learn with everyone!

See you there 😉

Adopting Agile Scrum (With caution) by Bogdan Suteu

Some time ago (November Last Year 2015) I’ve challenged a friend that is a Scrum Master (Bogdan Suteu) to write an article sharing some of his past experiences.

The result from the invitation was that he accepted the challenge and today I’m sharing his article as invited writer from this Blog.

It’s a really interesting article since we have some good points that we should keep in mind when we are helping a team or business during their transition to adopt Agile Scrum.

Having said this, please find the article below:

Nowadays, everyone uses the word “Agile”, “We are Agile”, almost to the exhaustion. But my question is… Do they know and understand what they are saying and what it means?

For that, I must explain you what is in my mind!

What makes any business powerful and competitive is their ability to constantly adapt to market change, while delivering quality products. Agile Software Delivery with its Scrum flavour give us the tools for having high performant teams with the availability to have a fast, high quality and perfomance delivery this way being able to achieve highest customers satisfaction.

Nevertheless, being transparent, adaptive, responsive to change and able to deliver at pace may be everyone’s dream, and yet a lot of teams and business are reluctant in adopting an Agile Scrum approach for Software Delivery.

As a result, I truly believe that ,we shouldn’t use Agile because is the new buzz word in the industry and because everyone is using it. We should use Agile Methodology in order to survive in this industry, but most of all be competitive and be ahead of the competition. Yes, that’s right. To survive in this wild, dynamic and competitive market/world. So, if you really want to succeed, you need to be able to get outside your comfort zone and take actions.

Agile is much more than having iterations, a definition of done, product backlog refinement meetings and so on. Agile means a cultural change at an organisational level, where people start to take ownership of their commitments and actions, and also, start to reflect on the way they think and work.

In the context of Agile Scrum adoption, there is no “smooth sailing” all the time. From my experience by working with scrum teams, I identified some anti-patterns that can make everyone transition/adoption more difficult.

1) One pitfall is to implement Agile for solving problems that don’t require Agile in order to be solved (Depicted below), on top of this, create performance metrics focused on data that is not accurate or reliable. Taking actions based on those metrics, will lead to a failed Agile transition/adoption.

Applying Agile Framworks

2) Trying to change every single issue that you’ve found really quickly, can lead to failure. Agile comes with a lot of benefits but also creates a lot of transparency, awareness and bad pattern revealing. Setting realistic actions and timeframe for implementing them will make people to be open and to get outside their comfort zone easier.

3) Agile Implementation & Support must come from top to bottom in an organisation. People need to be encouraged to share their lesson learned, and to feel that every mistake has the benefit of generating feedback &more powerful teams. Removing the “pointing finger/blaming culture” and trying to promote team spirit together with a culture of winning together / loosing together must first come from the top management. Do not be afraid of failing, but learn from your experience and each time, take actions.

4) Micromanagement days should be over! We should have small, but solid steps in creating self-organizing teams that can deliver valuable software each iteration. The management should create the safe environment and act as an enabler for those teams.

5) The term of a Cross functional team can be really misunderstood. Try to encourage “T shaped people” to step in. For example, one backend team member can change a label on a contact form. Encourage those types of inter-technology mix. Do not abuse of that from the very beginning, but make sure that you have willingness needed in the team.

6) First and foremost always try to keep delivering High Quality. Try to reach a sustainable pace while delivering high quality products. What’s not done, almost done or done but with “minor” defects (according to team’s definition of done) should be moved back into the project backlog. Try not to split established units of work or to create defects just to cover for “almost done” work. This is just enormous source of debate and politics. And it’s misleading for everybody.

7) Even if we implement everything with caution, with small solid steps, eventually Agile is not for everyone and we can expect that some people will not be on board. It demands an extra effort to leave comfort zone and maybe leaving your ego at the door.

8) Be flexible and patient. 😉 That’s so easy to say, but if you want to have most of the crew on board, you need from time to time to adjust and refine your agile processes. Change the retrospective format, cancel a product refinement meeting in a busy day, bring chocolate to the retrospectives, and be sincere and empathic.

So, is your organisation up to the challenge?

My feedback is that is really an interesting article showing his past experience and point of view. I hope that you enjoy reading it like I did.