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.