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.

Do we need managers in Agile?

I think we do!

And I found very interesting what Portia Tung and Pascal Van Cauwenberghe wrote at the end of their session at Agile 2010 Conference:

In an Agile organization, where the managers are freed from the day-to-day project tasks and decisions, we need them more than ever as leaders doing strategic work, removing organizational obstacles, building trusting relationships with technical staff, coaching, providing feedback, assisting with career development and building the capacity of the organization.

Tough job, eh? Especially if you come from years where you were taught doing a totally different way.

In one of her blog post from last year, Esther Derby had an inspiring say about something to remember about managers (especially those in middle management roles), instead of being just easily critical of them.

I cannot agree more.

In the last 2 years, I had the chance to talk to a lot of managers and most time I could feel and sometimes concretely hear a sense of frustration for the many "don't's" they said they were subscribed and by the too few "do's" they were suggested so that they could perform their "new" job great.
BTW, Scrum is agnostic about managers (as it is about technology)!

"Don't tell the team how to do something!"
"Don't take decisions the team can take by their own!"
"Don't speak at Daily Standup!"
"Don't ..."

"What shall I do then?"

I think they got a great point: it looks like asking a person, who was used to nail, to tighten a screw instead by using his/her old hammer.

Agile and Lean transformation is probably the most challenging and difficult change for a company, no matter if big or small, because it affects both business and people – developers and managers…everybody! And just like before, managers must understand the business they’re dealing with very well.

But business is changed and new challenges are out there asking for being adaptable, innovative and engaging for people: therefore, in order to be successful in the new environment, a manager needs to learn a lot, as well as unlearn. So it is crucial to help these people having such a role in the organization find the proper behaviors, skills and tools to nurture successful teams and to help them improve.

On the other hand, the Annual State of Agile Survey 2011 by VersionOne, shows that 52% of respondents see the Inability to change organizational culture and 34% see Management support as top barriers to further Agile adoption, while 32% see Management opposition as greatest concern about adopting Agile.
It doesn’t look like a pointless concern, does it?

Last week I and a colleague of mine delivered 2-days Lean Management training with the goal to kick-off a group of 16 leaders' journey towards becoming effective Lean managers.
Moving from the reasons why a new type of management is needed and the principles of Lean Management, we explored some concrete tools and practices out of the 7 Lean Disciplines. But the basic message of the training was: if you're serious about changing your organization, you must be even more serious about changing yourself.

The problem is that we all know that most times telling and doing are well far away from each other; my philosophy professor used to repeat a quote from Saint Bernard of Clairvaux: “The road to Hell is paved with good intentions”.
The only feasible path I see to improve is to honestly assess where we are, get feedbacks, realize our flaws and take responsibility for concrete actions (baby steps) to move forward.

Wisdom is knowing what to do next; virtue is doing it. - David Starr Jordan

Scrum teaches us having meetings with concrete outcomes and that's what we aimed for during this training as well: each manager left the class with a personal improvement plan of 3 SMART actions to start right the day after. Awesome, isn't it?

And it was even greater to see motivated faces leaving the room, with a sense of urgency for sharing with other colleagues the insights they got during the 2 days!

Improvement takes time

And commitment indeed!
You might ask: "Commitment to whom?". My experience says: "Commitment to yourself!".

I've seen several times many teams striving with practically implementing the agile key concept of Continuous Improvement. That’s why I decided to talk about this subject in my first post: no (r)evolution exists without improving and adapting.

The fact is that Continuous Improvement, as many things, does not happen naturally, but requires some steps.

“Change is inevitable. Growth is optional.” -  John C. Maxwell

The first step is to "stop the line" and take the time to reflect on hot things are going and find ways to improve.
A Scrum team could say: "Great! We have this. We do Sprint Retrospectives!"

The second step is to have effective retrospectives. It means finding SMART actions the team can concretely try and measure results.
A good Scrum Team can reply: "Our Scrum Master is good. We always manage to find SMART actions to implement".

That's still not enough. You need to plan for them to make that happen. And Scrum helps us again here: thumb rule should be that a team plans at least 10% of the Sprint time to dedicate to improvement actions, so that it has the necessary fuel to boost innovation.

The bad news is that this is still not enough. A lot of teams plan time to implement their retrospective actions (even though a lot do not indeed) and still strive to innovate. That's where commitment to yourselves comes into play. If you want to improve, you should take it very seriously and be disciplined in making it happen. Nothing normally happens in agile without discipline.

But discipline could be funny as well. Below is a picture which shows the agreement found by one of the teams I coached: every day one person must work on an improvement action. He/she takes the role of "Innovator of the Day" and deserves a prize: the jacket you see in the picture around his/her chair.

Do you think it is enough now? No, it's not.

Have you ever heard about Active Learning Cycle? The point is that applying an empirical process to improvement as well. It's not sufficient to try things, you have to evaluate the effectiveness of the actions you tried and consciously decide whether to keep or drop them.

Looks difficult? Might be. I'm not saying it is easy, but it is not impossible.