Certified or not certified, that is the question.

Are years of experience more important? Or proven experience?

On my Facebook travels between agile groups, I have found an interesting discussion that got me thinking.

What are your thoughts about certification vs experience?

comment on Facebook

This is a super interesting question. My first reaction was experience, but then certification. After another minute of thinking, experience. In the end, I entered a rabbit hole, so I thought. It’s best to put this in writing and gather my thoughts.

Years of Experience

I have been a Scrum Master/Coach for a couple of years, does that mean I have experience?

In the military, service time equates to experience. In a leadership role, I am not that sure.

Part of being a Scrum Master/Coach in a growing company is that you end up doing SM interviews. You get presented to all sorts of CV’s, ranging from people that did Scrum even before Jeff Sutherland and Ken Swabber, to others with just a couple of years. So the question is always, does 18yrs as an SM equate to being an awesome SM?

Well, yeah. No. I don’t believe that. It doesn’t mean anything at all. You could have been doing waterfall project management since the ’70s, that doesn’t make you a good project manager.

Proven Experience

Person Curving Wood
Photo by Lum3n.com from Pexels

Although years of experience mean nothing. Proven experience means everything. Let me explain.

You have someone in your interview process and you are talking about estimation. One SM has 10 years of experience, the other has 2. This is the question.

How do you estimate the work you have to do and communicate deadlines?

We do Story Points. The teams use the Fibonacci sequence and we have standardized across all teams that 8 SP’s is the max for a developer per sprint. Then we sum up the epic, divide by 8 and that gives us the amount of sprints.

10 years Scrum Master

We use Story Points. The PO explains the item and if it is clear the team votes on the effort using the Fibonacci sequence, we have some reference stories from prev. sprints that we use as a guideline. After all, that is estimated we use yesterday’s weather to try and predict how many sprints it will take. We keep on and adapting our estimation depending on the new sprint velocity and if there are any required changes. As a team, we always give a confidence level to our “amount of sprints” estimation.

2 years Scrum Master

Certification

Person Holding Diploma
Photo by Ekrulila from Pexels

Is certification important? I have to say yes, but not for the reasons that you may think. I consider certification important for you and me, not for our CV.

For me, certification is a standard. It allows me to understand if the knowledge I acquired is correct or not against what the community thinks. It makes it more objective instead of subjective, meaning, if I get a PSM II, I am confident that according to the scrum.org standards, my knowledge is at that level. If I fail the PSM II, like I did my first time around, I know that my knowledge was not enough. And that was correct. I made a goal to study more and learn more about agile leadership and being an SM.

In the end, the certification helped me understand where my limitations were. Saying this, certification is not everything. Like Jeff Sutherland said to a couple of colleagues of mine during their SM training.

Being certified is like taking your license. It means you can drive, doesn’t mean you are good at it.

3 top traits to be the best servant leader

Scrum Masters are thought to be servant leaders. But what does that mean exactly?

Scrum Masters are thought to be servant leaders. But what does that mean exactly?

Servant leadership is, as the name implies, the act of serving in a position of leadership. Cool, post written. See you tomorrow…
OK, Ok, let us dig in a bit more. What are the top 3 traits that make a good servant leader?

#1 – Collaborative

Grayscale Photo of Firemen
Photo by Pixabay from Pexels

A servant leader brings everyone into the discussion table to share their opinion. Decisions are made by the whole team and weighted for pros and cons.

This does not mean that a servant leader does not make any decision. In the case that there is no consensus in the team, the leader should help make the decision and guarantee the team is not stuck.

#2 – Result Oriented

Grayscale Photography of a Fireman Holding a Hose
Photo by Denniz Futalan from Pexels

A servant leader and a good leader by any means is oriented to results. The team’s performance should be measured by their outcome, not their output. Metrics like how many hours you worked or how many tickets you closed are irrelevant for the big picture.

Working software is the only measure of progress

agilemanifesto.org

#3 – Coach

Fireman Holding Fire Hose
Photo by Tim Eiden from Pexels

The servant leader is a coach.
His/hers main role should be to coach the team into not needing him anymore. If that is your focus, you will give your team the tools to succeed even in your absence.

Like a good coach, the servant leader should be aware of the team’s limitations and how to compensate them. This could be by bringing other knowledgeable people into the team or organizing workshops, knowledge sessions, and training.


What do you think?

Are there any other top traits you think make a good leader? Let me know in the comments or via any of the social platforms.

Cheers,



Join this newsletter to get exclusive content.

5 things that will make you a better leader

There are 5 things that if you start doing today your path to leadership will be much better.

Leadership is not bossing someone around, it is deeper than that. Leaders go first and eat last. Leaders open the path ahead instead of pushing them towards the unknown. Leaders are leaders because their peers follow them, not because someone put them there.

Leadership is the art of getting someone else to do something you want done because he wants to do it.

Dwight D. Eisenhower
Orange and and Brown Chess Pieces

Ordering someone to do something is easy. Leading them to the right path is hard. But don’t worry. There are 5 things that if you start doing today your path to leadership will be much better.


Value other opinions

A leader knows he/she cannot do it all alone and he/she does not have the answer to every question. A good leader regularly seeks guidance from the team, because he/she knows that they are the experts.

Being a leader is not about pushing your ideas. You should be open to being wrong, and to be honest, you should crave to be wrong. Otherwise, how would you learn new things?

It doesn’t make sense to hire smart people and tell them what to do…

Steve Jobs

Develop leadership in others

Man Kneeling on Baseball Field Beside Man
Photo by Pixabay from Pexels

A good leader makes his/hers job not needed. At least, I like to think like that. My goal as a coach is to make my team not need me anymore and train others to take my place. If I can do that, I consider it successful.

As leaders, we need to provide to others the opportunities to grow. Coach them. Give them the tools. And after some time, let them lead the way.

Focus on WE instead of I

There is no I in team, right?

That is an old saying and very true. Good leaders are part of the team, not above, below or to the side of it.

Every decision you make as a leader should focus on the growth of the team, not advancing your own agenda.

Act with humility

Leadership is not a title. A good leader doesn’t think he/she is better than everyone else, instead, he/she is a team player. A good leader doesn’t show he/she is in charge of the team decision, instead, he/she coaches the team into making those decisions.

Be a servant to the team

Selective Focus Photography of Four Pawn Chess Pieces
Photo by Pixabay from Pexels

A good leader is a servant leader.

The focus is on the team becoming better, not by bossing them around, but by coaching them. You can catch more flies with honey than vinegar.


Lead by example, not by force.

Cheers,



Join this newsletter to get exclusive content.

Why you need to stop obsessing about working hours

It feels a bit strange that in 2019 we are still talking about working hours and how different they are from hours worked

It feels a bit strange that in 2019 we are still talking about working hours and how different they are from hours worked. How many hours someone spends in the office. How many coffee or cigarettes breaks they take (Don’t do cigarettes. It’s bad for your health). Or worse, how much time they spend chatting next to the water cooler, or coffee machine.

Working SMART instead of working HARD

During the height of the industrial revolution, having a factory job was the thing. We would probably be working as part of an assembly line. Each one of us would be specialized in doing the same repetitive task over and over. The longer we were there, the more we would produce.

Photo by ELEVATE from Pexels

A long time ago we tried to do something similar in I.T. We estimated our projects in man/hours. We used to estimate the output in lines of code. Heck, we even created the role of Line Manager to help all of this go smoothly. Does this role sound familiar? That is because the Line Manager comes from Assembly Line Manager. We were always bad at coming up with names.

I.T. work is a creative one. Algorithms are not created by spending hours in front of the computer, they are created in your head. Problems are not solved by injecting new lines of code, they are solved by thinking, and sometimes, to properly think, you need to move away from your desk. Move to a new place to stimulate the brain, and then work on the problem.

Photo by Pixabay from Pexels

Luckily, for some of us at least, over time, we came to realize that outcome is different from output. We understand now that having fewer lines of code is better than more. Why? because it is easier to maintain, review and test.

Hours spent on site are not a synonym for good work. Most of the time the relationship is the complete opposite. If you have a colleague always sitting at their desk without a break, there may be 2 underlying problems and you should try and help him/her.

  • He/she is not good enough (yet) to perform the task in that time-frame. This means you should seek to train or mentor their technical skills.
  • He/she has really bad time-management. This one is harder but it can also be trained.

High performers will be able to work without looking at a computer. Their mind is always debugging and creating new algorithms. They try and find inspiration outside of their own box. Talking with a colleague over coffee. Going outside to look at the street. The most important part of the work happens in the head, not on the keyboard.


It is not rocket science to be a good manager. The job is not to control what your team does. How many breaks they will take. Or at what time they arrive at the office (especially if you don’t know what time they will leave).
Instead maybe bring coffee to the team. Create a good working environment, not a hostile one, and you will see how much more your team will produce.

Lead the way and bring them with you on this journey. Pull them in, don’t push them out.

Photo by Miguel Á. Padriñán from Pexels

You can disagree with me, and that is fair. You can do the complete opposite. But remember, in the end, they are the ones creating the value, not you. If they are not happy, they will find another place. And in today’s market, that’s not a hard task.

Cheers,



Join this newsletter to get exclusive content.

Why you need to eliminate hand-offs to be more effective

I need you to create a functional document, then I will read it, create my technical document and give it to someone else. Sounds familiar?

👇 (This is the same intro for all the lean waste posts. If you have read it already, scroll down for 4 paragraphs) 👇

We waste time all the time. Small unimportant tasks. Procrastination. Looking at nothing (this one is not really a time waster if it clears your head). The world is filled with traps that make us waste our time, and some of them we already know how to detect and adapt to them.

Photo by Stas Knop from Pexels

Lean Manufacturing talks about the 7 lean wastes, these wastes can also be mapped to software development.
During these next 7 days, I will pick up one of the wastes and investigate the following questions

  • Why does it impact our work?
  • What could be the causes of this?
  • How can we measure it?
  • How can we avoid it?

For today, the focus is Hand-offs. These can come in the form of documentation, extra training or meetings.

I need you to create a functional document, then I will read it, create my technical document and give it to someone else. Sounds familiar?
When we are all done, we will create user manuals and run-books for the team that will maintain our project. To make it easier for them, we will have several meetings where we explain what we did and how it runs.

Sounds like a lot of work? That is not even the worst part. This whole process follows the assumption that nothing, absolutely nothing, will be lost in translation.

Code is like a good joke, if you have to explain it, you are doing it wrong.

Add this to a developer working on more than one project, and you have the trifecta.

Photo by George Becker from Pexels

Hand-offs that need to happen when we switch from project to project, to keep the team informed. Task-switching by moving from one task to the other, in some cases, several times a day. Partially Done work, because you never finish what you start. Keep jumping from one task to the other.


Why does it impact our work?

Photo by Pixabay from Pexels
  • Information may be lost on the hand-off chain
  • This requires extra effort in the form of meetings, more documentation, and possible training
  • If we use documentation as the only source of hand-off, there is a limit of what can be represented in text and diagrams. Try teaching someone to ride a bike by reading a bike riding book.

What could be the causes of this?

Photo by Pixabay from Pexels
  • Teams don’t own what they do
  • Too many gates to your process. For example, if you are using the waterfall way of working.
  • The hidden hand-off is when a developer passes the code to a tester to test.

How can we measure it?

Photo by Lukas from Pexels
  • # of sign-offs in your process
  • # of extensive documents that your team needs to produce for other teams.
  • QA specific tasks. UAT team.
  • Time spent on the steps of your process that are not done by your development team.

How can we avoid it?

Photo by Linda Eller-Shein from Pexels

Cheers,



Join this newsletter to get exclusive content.

All you need to know about this week’s posts.

This week’s focus was on time wasters. Things that we do everyday without even noticing that take our time away from other more important tasks.
Here is a quick summary of what happened.

Welcome to the end of 2019 week 44. This week’s focus was on time wasters. Things that we do everyday without even noticing that take our time away from other more important tasks.
Here is a quick summary of what happened.

📅 Monday: An inexpensive way to gain more time.

LEAN WASTE #1 : Task-switching and context-switching are costing us time.

We humans believe that we are great at multitasking, even though it has been proven time and time again that we are really really bad.
Intrinsically we know this. We even get angry when someone interrupts us …

CLICK HERE FOR FULL …

📅 Tuesday: Want to get more time? Do that hard task now.

Procrastination towards hard tasks keeps us hooked on task-switching between what we like and what we dislike.

Unlike some productivity gurus, I am a firm believer that we should do what we don’t like before. Get it out of the way, and then we can properly focus and enjoy the things we like to do.

CLICK HERE FOR FULL …

📅 Wednesday: How to unlock the value of a definition of ready.

Not using it as a gate, but as a communication tool towards your product team.

This is an on-going battle for the agile community. Should we have or not a definition of ready?

CLICK HERE FOR FULL …

📅 Thursday: Parallelization is a hoax, do one thing at a time.

LEAN WASTE #2 : We need to finish what we start before picking up something new. Partially done work provides zero value and keeps us task-switching.

Partially Done work. Some say this is self-explanatory, but I believe it is a bit more complex.

CLICK HERE FOR FULL …

📅 Friday: How to do less work and skyrocket your productivity?

LEAN WASTE #3 : Spend time figuring out what matters instead of doing more stuff.

This is a clear case of effectiveness vs efficiency. We have the best code ever. 100% test coverage. A dream pipeline that delivers everything to production without a single bug. If no one is going to use it after, we just wasted our time.

CLICK HERE FOR FULL …

💡 Saturday: This is what I’ve learned this week.

A retrospective of the week that passed and what I’ve learned from it.

Hello everyone, one more week gone and another about to start.
So far a good start of the weekend. I am writing this post with a sunny day, something that is not very common in the Netherlands at this time of the year.

CLICK HERE FOR FULL …

Cheers,



Join this newsletter to get exclusive content.

How to do less work and skyrocket your productivity

This is a clear case of effectiveness vs efficiency. We have the best code ever. 100% test coverage. A dream pipeline that delivers everything to production without a single bug. If no one is going to use it after, we just wasted our time.

👇 (this is the same intro as yesterday’s post if you have read it already, scroll down 4 paragraphs) 👇

We waste time all the time. Small unimportant tasks. Procrastination. Looking at nothing (this one is not really a time waster if it clears your head).
The world is filled with traps that make us waste our time, and some of them we already know how to detect and adapt to them.

Lean Manufacturing talks about the 7 lean wastes, these wastes can also be mapped to software development.
During these next 7 days, I will pick up one of the wastes and investigate the following questions

  • Why does it impact our work?
  • What could be the causes of this?
  • How can we measure it?
  • How can we avoid it?

For today the focus is Extra Work. Extra work means everything that we did that didn’t need to be done.

80% of the value comes from 20% of the features

This is a clear case of effectiveness vs efficiency. We have the best code ever. 100% test coverage. A dream pipeline that delivers everything to production without a single bug. If no one is going to use it after, we just wasted our time.

It may look counter-intuitive to consider a waste if you are producing more, but the output is not the same as the outcome. Producing more of something that will not be used has 0 value. Heck, in this case, it even has a negative value because you could be spending your time with something else.

Imagine you have the best hot dog stand in the world, but you are parked in an area of vegetarian and vegan customers. It doesn’t matter how good your hot dogs are, no one will buy them.

Why does it impact our work?

  • If it’s not going to be used, why do it?
  • We will need to maintain them.
  • If they break, they may break something else that is being used.
  • Our team spent time testing, reviewing and deploying it for nothing.
  • Increase our code complexity.

What could be the causes of this?

  • We don’t know our customers and his/her needs.
  • We don’t validate value propositions.
  • We don’t have customer metrics that allow us to understand what is being used or not.

How can we measure it?

  • #features in production that are used by the customer
  • #items delivered that are focused on the MVP

How can we avoid it?

  • Break features as small as possible and review them with your stakeholders.
  • Release to production often and gather usage metrics.
  • Proper prioritization of the backlog and focus on MVP by using the Eisenhower matrix.

Cheers,



Join this newsletter to get exclusive content.