Is Scrum Master (or team coach) a full time job?

That is a dilemma which pops up frequently and I'm pretty sure you got asked or asked yourself at least once.

Is this a real job or just a bit of meeting facilitation one can do in the spare time (maybe doing it for 2 or 3 teams at the same time)?

Someone told me few days ago: “You know: we have 7 development teams, 5 Product Owners, 3 Technical Coordinators and 4 Project Managers: we cannot afford to have full time Scrum Masters.”

!!!???@#**&%*!?: I thought.

A manager also asked me some months ago: “We decided to have one Scrum Master every 5 teams. Is this ok, according to Scrum?”

Well! The point is not if it is Scrum or not. The point is: what is the probability to have successful teams!

All in all, it's really interesting to see how much this role is challenged everyday, like maybe no other role in any company anytime before. And I also wonder why.

• Is it because we didn't manage to explain it in the Scrum courses?
• Is it just counterintuitive in our western culture?
• Is it simply because we do not have enough great Scrum Masters or team coaches to play as role models and the average players do not think they can (or are not allowed to) provide value besides pulling some coding or testing tasks?

However, this hot subject got up during a retrospective of one of the local communities I’m part of in Italy. While discussing the fears which are preventing Scrum Masters doing their job well, the most voted post-it recited more or less the following:

"I'm always puzzled whether I'm doing the right thing and sometimes I'm really scared because I do not know what to do".

So, what are the typical tasks a Scrum Master is supposed to do concretely to perform his job well?

And how much time you'd better spend on each task as a minimum to make it effective in an average 2-weeks Sprint?

We held a 1.5 hrs workshop and here below a present for you: a nice picture summarizing the results of our discussion.

Awesome, isn't it?

Evidence of few numbers is most times much more powerful than many words.

Getting back to my original question: is Scrum Master a full time job?

What would be your answer now?

Agile development will not solve any of your problems.

It will just make them so painfully visible that ignoring them is harder. - Ken Schwaber

Measures which matter

About one month ago I was following a couple of colleagues discussing on Twitter about measures and specifically about measuring productivity. It was a nice exchange of views on whether development of a new product is production or creativity and what to measure in either case.

I personally think that SW development is most about learning: make an assumption, do the cheapest experiment to validate that assumption and evaluate the results by means of customer feedback. That’s why Agile makes sense.

Now I do not want to come into specifics (I do not know the background of the discussion), but I was thinking: I cannot give THE right answer to the question, but I would put on the table some basic principles about how a good metric should look like.

1. Measure one level up – Whatever you want to measure you might better look at the next level: look at teams if you want to measure individuals, look at the development organization if you want to measure teams, look at the e2e flow if you want to measure the development organization
2. Few, Simple and Visible – Full transparency makes the chosen metric powerful. Don’t over measure.
3. Drive right behaviors – Don’t measure outcomes, but put functional behaviors in place and the outcomes will take care of themselves. You get what you measure.

Some time ago we had an issue about high pressure on teams to deliver (actually from both inside and outside), so that many people (and many influencers in the organization) did not consider important improving as individuals and teams. So management decided to measure teams’ improvement ability.

I’m scared already only by thinking at possible solutions a traditional and bureaucratic organization could have thought about in the attempt of achieving this goal.

We simply tried to apply the 3 principles above and setup a metric called:

Organizational improvement factor = % Total Time dedicated to Improvement actions vs. Total available time. Here is the rationale behind:

1. Measure one level up – We wanted to measure teams, so we decided to measure the development organization: it is not finger pointing to any individual or team, is collaborative and everybody feels accountable for the overall value.
2. Few, Simple and Visible – A unique metric which is simple, updated at each sprint and fully visible on a white board in a common space.
3. Drive right behaviors – Behaviors are a function of people and their environment: this metric resulted to be a good way of influencing the environment and then the teams’ behavior. Everybody feels now that improvements have a recognized dignity.

The same applies when talking about measuring stuff like development productivity or efficiency.

1. What is the next level up which makes sense to measure?
2. How can we make it simple and transparent?
3. What good behaviors should we look for?

In that case I would rather measure organizational effectiveness:

Are we doing the right things and only what is strictly needed? 

How is our Return on Investment?

You will realize that you need to consider delivered value (not only costs) and discover that effectiveness eats efficiency at breakfast every morning: if you drop 50% of the scope because it is not needed,  manage to deliver faster and get money earlier, there will be no cost efficiency program or productivity improvement whatsoever that will give you comparable results.

However, being a team or an organization a complex system of human beings, I would like to leave you with a quote from master W.E. Deming:

97% of what matters in an organization can’t be measured. Only maybe 3% can be measured. But when you go into most organizations and look at what people are doing, they’re spending all their time focusing on what they can measure and none of their time on what really matters – what they can’t measure. Why would we do this? We’re spending all our time measuring what doesn’t matter.

Peter Pan

This week was the time for Scrum Gathering Barcelona 2012, the Global Scrum Alliance event in Europe.

Unfortunately I could not attend this year, like instead I did last year when I went to Scrum Gathering London 2011 (by the way I was one of just 3 Italians attending out of more than 300 people and was actually the only one working in Italy: don’t know exactly what it means, but it doesn’t smell very good anyhow).

On my way to England, I happened to read a nice article on the British Airways magazine describing Peter Pan as an ideal business man. 

Yes, you got it right: a business man! 

This made me think a bit.

Then I realized: Awesome! Peter Pan is also a prototype of a great Scrum Master or Agile coach.

He persuades and stimulates others, leads by example and isn't afraid to get hands dirty when needed.

As a mentor, he can take any young person and mould them into a fearless and vital member of the team.

Socially aware, Peter gives his team a strong sense of community and a reason to get up in the morning. The work is dangerous, however: battling pirates and crocodiles is not usually a career path open to the under-16s, but Peter helps his team overcome all impediments, show courage and face challenges looking impossible at a first glance.

Since he loves to fly and isn't afraid of confrontation, he is a perfect leader and by using unconventional tools out of normal practice (like brandishing a small sword in the boardroom), he gets great results.

His tendency to remain eternally youthful can be grating though: sometimes he can't understand why adults forgot their childhood and refuse to join him to fly. 

Thus, deep down he's lonely, with his only constant companion Trilly who sometimes he's not even very nice to. But as a good servant leader, he inspires trust and makes his team of young people able to do anything and get what they dream.

Well, I must admit I feel like Peter Pan sometimes (and be sure not because I suffer any syndrome).

And you?

Who (or What) is the Hook to defeat in your organization? 

Duties and Responsibilities of a 21st century employee

Since I started working as Agile coach, I’ve been seeing the same pattern many times and on different levels:

• Individuals committing themselves to learn, by reading books or blogs for instance, even with a defined plan, and constantly postponing this plan
• Teams committing to dedicate time to self-learning, study groups or coding dojos and cancel these appointments many times (even cancel retrospectives) due to real or artificial urgencies and for the sake of firefighting
• Organizations not taking explicit time to reflect and learn from past experiences (btw the only procedures an Agile organization should have are the ones to allow a systematic continuous improvement)

Many times I challenged developers, ScMs, POs, teams or managers and asked what was impeding them to fulfill their commitment to study or learn and the answer I got most times was:

“You know, we have other priorities this week. We’re responsible to ensure this and this and we cannot spend time on lower importance stuff”.

Priorities, Responsibilities..., but what should we really be responsible for in an Agile organization striving in an age of dramatic changes within a tremendously dynamic environment?

Last week I got inspired by a post I read on Crisp’s blog, called Responsibility the Agile Way.

The main point of the post is that people cannot be responsible for end results, because results depend from many, sometimes not controllable, variables. But people are responsible and must be held accountable for good behaviors, because good behaviors and focus on improvement lead to good results. Here is one sentence that hit me and summarizes my thinking as well:

We are all responsible for contributing with our intelligence and senses for the best of the product and the process.

So, if we’re responsible to improve our product and process, why do people not consider that spending time on learning (retrospective, feedback, self-study, etc.) has at least the same dignity as spending time for coding, testing, reviewing documents or any damned operative meeting?

I think the answer relies partly in the modern western culture approach, but mostly in what are the expectations on employees in the 21^st century.

If a bureaucratic organization demands human resources to strictly follow rules, processes and detailed plans to work, a Lean-Agile organization should demand people to continuously improve themselves, their skills, their team and their process as their main duty.

Paraphrasing Steve Denning, I would call it: Radical Responsibility.

And managers’ duty should be not only to state this very clearly, but hold themselves and people accountable for spending time to reflect on how things are going on and coming up with and implement concrete actions to make things better.

Yesterday I was joking (not too much indeed) with a colleague by saying: let’s put Learning in everyone’s Role description.

Why?

Eric Ries gives an answer: “The only way to win is to learn faster than anyone else.”

I also read an article reporting an executive saying recently "If the rate of learning outside our organization is faster than the rate of learning inside our organization, then we will prepare to die."

Are you preparing to die? Hopefully not.

I wish your people and your organization another kind of disease instead: a tremendous allergy to whatever does not work and a victimizing obsession to learn and make things better :o)

The hard job of growing great Scrum Masters - 2

As you might guess, I'm really interested in this subject for taking the time to write a second post about it.

Few weeks ago I was talking with one of the Product Owners in my team (I am currently coaching the PO team). I had asked him to give me feedback on my work and we happened to talk about what I think is one of the missions of an Agile coach: to recognize Agile talents.

Surprisingly enough for me, he could recognize this as a very valuable point, but the rationale behind his belief challenged my current thinking quite a bit.

We came to discuss about what he considered as key characteristics for a potential Scum Master.

"There are some key qualities" - he said - "that a person who wants to be a Scrum Master must have and cannot be learned, regardless how many books you read or how good your coach is!”.

I must say this was a bit hurting my self-esteem: I thought I could teach or help any apprentice Scrum Master to learn practically any skill necessary for the job.
At least until then, when I realized he had a valid point.

But then I asked myself: what are these skills or qualities which are essential to hire a new apprentice Scrum master?

This question reminded me a blog post from Esther Derby I had read some days before, called Scrum Masters and Agile Coaches: More than a Title.

With the usual inspiring style, she talks about what are the Essential Qualities for a Scrum Master (Initiative, flexibility, optimism, determination, resilience, working in a team environment, supportive, not cowed by authority) and what are the Desirable Qualities (Detachment, discernment, Able to navigate conflicts).

However what hits me most is what she calls The Elimination Factors, patterns of thought and behavior that would eliminate a candidate from consideration. 

Here they are: Preference for directing others, defensiveness, judgmental attitude, low threshold for frustration.

The most interesting and surprising coincidence for me was that 2 of these relate exactly to the key qualities my colleague Product Owner mentioned and was able to see given his experience in Scrum: impressive, isn't it?

But what is your view about this issue?

3 things we can learn from TPS

Last week I mentioned my participation to a seminar organized by the Industrial Association of Salerno on Lean Management and Continuous Improvement.

This week I would like to share more about that event, by highlighting what I think we could learn from experiences of organizational transformation and Lean management in other industries together with some (hopefully) powerful questions to facilitate further reflections.

1) Visible problems do not exist: they have been solved already!

One more interesting insight I got from Minoru Tanaka, CEO of JMAC Europe, in his speech about Toyota Production System (TPS) was his classification of problems into 3 categories: potential, invisible and visible. It’s important that potential problems to the desired target are identified as well as invisible problems are made visible and improved immediately. Instead, visible problems do not exist actually, because they have been solved already. 

• How many clearly visible problems are you still stuck with in your organization?

2) Most efficient way becomes standard: standard must be improved every month!

Then Mr. Tanaka discussed about Continuous Improvement, describing that, once a process has been improved in one department, than the most efficient way becomes a “standard”.

When hearing this word, I got disappointed wondering how hell the definition of a standard process could fit into a Continuous Improvement approach.

But then he added: the “standard” must be reviewed every month!

And more: the “standard” is visualized and each manager is accountable to improve the “standard” every month! 

• How much are you still striving to find one-size-fits-all "best practices” to make you move quickly to the next rigid and comfortable status quo?
• What are your managers accountable for? 
• How much are they encouraging the “stop the line” principle?

3) Measure organizational capacity of solving impediments to generate trust

Last enlightening reflection to me was from the local director of a cans manufacturer with around 1500 employees.

You might wonder how cans may be relevant for high-tech industries, but let me continue.

Well, he was describing their transformation journey to Lean and talked about the importance of impediment handling in his organization to be trustable. They have a graph, clearly visible to everybody, with 2 curves: the accumulated number of raised impediments per month and the accumulated number of fixed impediments per month.

The 2 curves must always be parallel, because he said: “If the curve of fixed impediments goes flattish, all my employees will understand I do not believe in what we’re doing and I’m just cheating them”. 

• How is your organization serious with fixing impediments from teams?
• How much are you living the values you’re preaching?

Why Agile?

At the end of May I participated to a seminar organized by the Industrial Association of Salerno on Lean Management and Continuous Improvement (btw a surprisingly crowded event with more than 500 participants from more than 200 companies).

One of the most interesting takeaways for me was from Minoru Tanaka, expert of Industrial Engineering and CEO of JMAC Europe. In his speech on Toyota Production System he stressed the vital importance of understanding “Why” you are doing a Lean transformation and even every single improvement or change, to get a real commitment to succeed.

That’s why I decided to include during my agile trainings a short module called “Why Agile?”

The purpose of this very interactive module is to engage the class in a discussion to share and agree about why they are attending the training, what is the purpose of the Agile journey they want to (or are told to) start and, finally, what are the intended issues they think an Agile SW development can address.

I ran this module 3 times already and I can tell you that the variety of answers is sometimes impressive, showing 2 things at least in my view: how many myths Agile development is surrounded from and how many, sometimes false, expectations come from discussions about agility.

I do not want to list all the answers here and many are right indeed. It’s just that sometimes, even right answers are not pointing to the ultimate goal of agility, but rather to (what I call) sub-products coming from all goods inherent for instance to Focus, Collaboration or Cross-functionality.

The core of the question comes actually from the nature itself of SW development, especially in the 21^st century: SW development is a dynamic complex system, where change is king.

Nothing endures but change!

That’s what Heraclitus of Ephesus said in the 6^th century B.C.

But we all know that changes are going faster and faster in the world around us: current change rate is unprecedented, even change has changed.

There’s only one thing you can be sure of when you start a project: almost everything will change! Requirements will change, environment will change, solution will change, because you will most probably discover things you were not even aware of 2 weeks before.

So you have a choice: you can pretend change does not exist and that your plan will stick or accept the reality and find a way to live with change.

It’s like the law of gravity: you can take it into account or not, but you’d better do it, if you decide to jump off a 30-floor skyscraper ;o)

To describe the core of Agile, I like very much the great summary I heard from Craig Larman at a Conference in Shanghai last June: Agile is mainly intended for a 2-fold purpose:

1. Make changes easy
2. Make changes cheap

That’s what Agile is meant for: it is a framework for applying common sense to SW development in a systematic way.