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.

The hard job of growing great Scrum Masters

Back to trenches after restful summer vacations, I was reflecting about what could be my focus areas for the last part of 2012 as an Agile coach.

Feeling me committed as Certified Scrum Professional to the Scrum Alliance motto "Transforming the world of work", I was wondering what could provide me the highest Return On Investment, given the always scarce resource of my available time and the goal to be a change catalyst for my organization.

Then, as a careful Product Owner, I made some calculations: if I coach a team of 7 people, I will get 7 agilists in the best possible case, but if I coached 7 Scrum masters, I could theoretically get 7 team of agilists.

So: what would you do?

Yes, one of my focus areas should be coaching Scrum Masters to get great Scrum Masters and eventually good Agile coaches to coach even other Scrum masters in a domino effect leading to the transformation of the world around me.

Great plan, you would say, but...

I don't like "Yes, but...", but there's a "Yes, but..." this time. 

If you are satisfied in growing average or inadequate Scrum Masters, well it is not a big deal, BUT most of the troubles we have also in our private life are due to the fact that there are too many inadequate or average people around. 

Instead the biggest concern of an Agile enterprise should be to build self-developing high-level professionals in all roles, including world class developers and high professionals as Agile leaders, either Scrum Masters, Product Owners or Managers: all require high skills, correct behaviors and discipline.

Focusing on Scrum Masters, if you want to get an idea about what a great Scrum Masters should do and how he should behave, you might want to have a look at the Scrum Master's checklist website.

Said that and given the incredible amount of skills a good Scrum Master is supposed to have, growing a great Scrum Master becomes really a hard job, which implies using a lot of different tools and approaches to get the learning through.

I consider 3 pillars as fundamental:

·        Training

·        Mentoring

·        Self-Learning

In particular here is what I found in my experience relevant to be addressed with an apprentice Scrum Master, meaning a person having worked for a while in a Scrum team, willing to become a Scrum Master and, most important, passionate to learn:

·        Dedicated training for a diversified skill set, ranging from Agile leadership, Coaching techniques, to “How to write a good Product backlog”, to SW craftsmanship

·        2/3-months mentoring from an experienced Agile coach, co-preparation of Ceremonies, co-coaching and, what everybody always finds very valuable, concrete feedback by real observation in the daily work

·        Since agility, as we said, asks for self-driven competence management, where people actively educate and improve themselves, self-learning is an essential part, including participations to CoPs, reading blogs and books, watching webcasts or listening to podcasts.

Whether you find this interesting for you or not, enjoy your own journey in transforming the world of work, whatever it is.

Creating a culture of effective SW development

Last month @maubagnato and I completed our first experience of holding a dedicated class about Agile SW development in the Computer Science degree course at University of Salerno.

What a great time interacting with clever guys eager to learn and experiment new things!

It was long ago we started discussing the opportunity of sharing some of our learning and experience with our local university where we hire most of our people from, since we found essential to instill a culture of agility into the new generation of students, who, after more than 10 years from signing the Agile Manifesto, are still taught mostly traditional SW development techniques and lack an accurate introduction into state-of-the-art methods and practices.

Consider that almost no student we met knew even the name “Scrum” before we taught them.

So last year we managed to convince an interested professor to give us 10% of his 60-hours SW engineering class to talk about Scrum and SW craftsmanship.

The response from the students was so enthusiastic, that rumors flew very fast around and another illuminated professor came with the idea of organizing a 20-hours class about Agile, containing all subjects we considered important.

It was the chance we were waiting for.

So we designed our class, which we named “Agile methods and practices”.

Yes, because that’s what we think an Agile team needs to be successful: using an effective method like Scrum to organize the work, but at the same time master effective practices to get the job done.

That’s why we decided to present Scrum in the first half of the course (where we could leverage on our 400+ class hours experience in teaching Scrum to Teams and Product Owners) as a simple, effective and educational framework to help a group of people become a high-performing agile team.

However, being very conscious that Scrum is not enough to sustain an effective agile SW development, we wanted to spend at least the same amount of time to explore together “The Land that Scrum forgot”.
But how to do that?

While teaching and coaching our Scrum teams on SW craftsmanship, we realized how difficult is for people used to develop SW with a traditional approach even imagine how it can be possible to have an emerging architecture, or doing the analysis by writing Acceptance Tests or writing iteratively Unit Tests before even thinking at the code and continuously re-factor the code.

Therefore we needed to create a consistent story!

Our approach was then to zoom inside a Sprint and practically show how a selection of agile methods and practices could be used effectively to transform a User Story in a potentially shippable product increment.

Yes, because this is the real challenge for a Scrum team: get a bunch of User Stories done without doing a mini-waterfall inside the Sprint.

The framework we proposed during the lectures was the following:

• Use Behaviour Driven Development to collaboratively write Acceptance Test scenarios out of a User Story
• Use Test Driven Development and Pair Programming to write the minimum amount of code to make a single Acceptance Test passed
• Use Continuous Integration to make sure you always have a potentially shippable product increment
• Repeat the approach iteratively until all Acceptance Tests are passed and then all User Stories are done

We did this by assigning them a real SW project to develop in teams, partly during the lectures and partly as homework.

Obviously our ambition could not be to make them learn these practices in few hours, but mainly to create awareness and stimulate curiosity about alternative ways of thinking about SW development than what they are taught everyday. However what some of them achieved, regardless the small amount of time available was really incredible, as one can smell from this link.

Given the feedback we got from the students, the class was appreciated, also because of the interactive teaching techniques we used to get the content through.

Thanks also to @desimone71 and @Dario_DeVito for their useful help.

It looks we raised the bar of what these students will require to a teacher from now on :o)

Living in a river of conversations

Last night I came back from my first round of vacation, which I spent leading our summer Scout Camp.

Great time, btw, as usual and refreshing feedback from our guys revealing how many things they learned.

While on the train on my way back, I had the chance to read again chapter 11 of the book "The Leader's Guide to Radical Management” where the author Steve Denning tells the story about how he started to change the way of managing at World Bank: what he calls his initiation into Radical Change Management.

Surprisingly enough, reading this story back looked like somehow reading a lot about the story of our own Agile transformation in retrospective.

Moving from one page to another, I got more and more impressed from how many parallelisms I could draw between Denning’s experience and many things we have been doing similarly, mainly intuitively, which turned out to be success factors for us.

First of all the starting point: a passionate belief in the idea from a small team to inspire and lead the transformation, an energized group of people, who trusted one another, with no role description, but willing to do whatever it took beyond any border of responsibility.

The most effective tool, though expensive, for this team was having a lot of conversations with colleagues, peers or managers, all over the place, to share experiences, enthusiasm, beliefs, understanding and concerns about the deep transformation at hand.

At the beginning, people couldn’t sometimes understand what they were talking about, but finding good stories to tell in corridors, coffee break areas, meeting rooms or even in the canteen, helped some other people understand the idea and build upon it by themselves.

Nothing happened through a traditional change management approach, delivering change upon a certain program and time plan: how could we plan something we didn’t know and never made before?

Instead it grew more organically, based on a shared vision and a holistic approach, but applying baby steps and an empirical process control.

And talking!

Support from senior management was essential especially at a certain point in time, where some people, afraid of losing their position, started to be alarmed by the serious challenge of the status quo and did their best to slow down the change.

Meanwhile the team of passionate believers grew and started acting more openly to each other: they could recognize the different qualities and strengths of each person, while appreciating how much everybody was doing despite what it took.

We had (and still have) a lot of fights sometimes, but we have so much trust and respect in one another, that disagreements make the team stronger and each person better.

And we have a lot of fun, despite the hurdles, the hard work and the frustration sometimes for not harvesting the fruits we thought we should have.

Keep talking is increasing the group of enthusiasts, who believe in the cause and start doing whatever it takes to advance the change.

We are really living “in a river of conversations”: no precooked message to be rolled out top down, but an evolving idea crafted by means a continuous dialogue and resulting actions.

And we learned to put the principles ahead of mechanics: when we run into a new problem we refer back to principles to guide us and adjust what clashes with them.

Reading Denning’s book helped me see also what is probably our main pitfall: not enough courage or ability to make the change quicker which generated, as Denning says, a massive quantity of antibodies and thus an even harder transformation.

Yes, because what we’re talking about, exactly like Scrum, looks easy in principle, but it turns out to be very difficult in implementing.

Nevertheless it is an exciting and rewarding journey.