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.