PMI-NIC Pecha Kucha Event

Thursday June the 28th, the PMI-NIC organized an event in the pecha kucha format, where six talks have been presented, one was mine. The format requires the speaker to present no more and no less than twenty slides, which are temporized: 20 seconds each.

A challenge because you must explain the message in a concise way, getting rid of any superfluous message (entropy) and going straight to the heart of what you want to communicate for each slide.

Here below a short description of such a format of presenting.

PechaKucha Night was devised in Tokyo in February 2003 as an event for young designers to meet, network, and show their work in public. It has turned into a massive celebration, with events happening in hundreds of cities around the world, inspiring creatives worldwide. Drawing its name from the Japanese term for the sound of “chit chat”, it rests on a presentation format that is based on a simple idea: 20 images x 20 seconds. It’s a format that makes presentations concise, and keeps things moving at a rapid pace.

Before we started the presentations, we had an interesting agile game called ‘The Marshmallow Challenge’ an intersting and fun game about evolutionary design that invite the team to collaboration, innovation and creativity.

It was really cool!

Then it was the time of the talks. Mine was about one of my favourite topics: talent!

The title is Talent, passion and excellence in agile teams and it is downloadable from the PMI-NIC website.

It’s 13Mb so be patient

Building an agile organic learning machine

Why is so important for your company to actually let the agile worth spread around it?

It happens that when a company decides to embrace agile, it thinks to help its teams during the transition from a previous software developing model (waterfall or in general any phase or gates development model), to an agile one. These companies often hire a coach in charge to accompain the teams throught this transformation, by delivering training and assisting and facilitating their way of working using the new paradigma.

After a first period, the honey moon period, the teams start to struggle because of difficulties of changing their working behaviors, because of many impediments often coming from external interferences or interconnections with some other external teams (agile or not).

This is the moment in which the coach and the company, start to think about scaling agile in the enterprise, introducing what Schwaber and Sutherland called ‘Scrum of Scrums’ or Shalloway revisited and named ‘PCT – Product Coordination Team’.

No matter what the name and method you and the company choose to adopt, start soon to scale agile, otherwise synch problems become so important and tough, that agile is no more the fantastic new model to adopt for developing software.

What I’ve seen and experienced, is that scaling agile is not enough. There’s at least one another step to nurture the change process that such a company needs to totaly and completely understand and embrace agile.

What is missing, at all, in a scenario like that, is an organic mechanism of knowledge sharing and learning.

Let me explain.

As you probably know, a superb way to share knowledge within a team, is to pair.

XP prescribes (yes, it is prescribed like what the doctor does with medicine) the practice of pair programming, in order to cure these main symptoms:

1. general knowledge leverage for junior, pairing them with senior guys
2. in case of particularly complex or important piece of code to develop: here the reason is that two pair of eyes is better than one
3. in case of high specialization of one team member over a specific professional domain or part of code (do you knowthe bus factor?)
4. help the team members to know better each other

Hence pairing helps a lot within a team; but how it can be used to involve the entire company? It cannot.

We have, instead, some other techniques to spread agile within the company and these are called: communities of practices, open spaces, user groups and conferences.

Communities of practices

This kind of “human aggregation” is what a company, the one that has several teams adopting agile, should initiate in its reality. These groups share common interests. ScrumMasters or ProductOwners communities or, yet, organized by methodology: Scrum, lean, XP or Kanban communities. Within these free association of the employees, the company have a great opportunity to create occasions where the people share ideas, experiences and usually create new standards or best practices to apply.

Open Spaces

Visit this link to gather detailed information about this open spaces.

This kind of meetings can be used to share knowledge, to try to solve problems, to analyze risks or to share any experiences with other colleagues. Take a look here: the Agile Coach Camp 2012 un-conference, is completely arranged following the open space philosofy.

Here are my reflections about the past event in 2011 and, obviously, I’ll be there also this year (within a week……can’t wait).

 User Groups

Even if a company does not have the possibilty to create the knowledge sharing spaces above reported, it must try to invite the team members to join the agile user groups already existing in their city. It’s much more easy, if the company directly contacts the external groups asking for the meeting dates and arranging an evening with them.

Conferences

The last, but not the least, method is to let the guys attend to some conferences. This has the double positive effect to let them learn from professionals and create a team building effect. A moment in which the team members can confront each others.

Agile, as you know, is a matter of practicing, collaboration and confrontation. It’s paramount to create a process that helps to refresh and reinforce constantly the knowledge and the practices.

In my opinion, a company should not be afraid to spend some money to create these “spaces“: these are investments, to be looked as great opportunity to let the entire company grow and becoming an organic learning machine.

Agile Coach’s Responsibilities

On sunday I participated to the last day of an interesting course started in February, regarding the coaching world. I decided to enroll to that course, because I felt that one important piece of the puzzle, to consider myself an agile coach, was still missing.

A strong preparation in agile project management, studying, attaining the CSM and PMI-ACP certifications, working actively in the agile world, participating to related events and keeping in touch with the several communities, were for me all important and mandatory steps to walk, but the journey was not yet finished.

Being an agile coach, means to actually work according with two different, but strictly inter-connected plans.

The first regards the core agile values, principles, techniques and rules, helping and facilitating people to get there, understand and master it as a whole.

The second one, on the other hand, mainly regards the perceptions and feelings people have about this novelty, that at least for the next few months, will change their habits. It’s more a matter of how they cope with agile, how they react to it in terms of applying the new knowledge, considering the huge impact in the way they communicate and collaborate each other, and finally, they peform.

This last area is much more unpredictable and complex to manage for a coach, because it has a lot to do with human beings and their perceptions, fears, willingness to change. A paramount reason that pushed me to enroll to a coaching course (even better if it is an course endorsed by an Internation Coach Federation), had to do with such an intangible, subject and sensitive world: World that obliged me to be more prepared and conscious about it.

Be an effective and memorable agile coach means to master the theory, be a good communicator and a great mentor, facilitating people to build new working habits and substituting the old ones.

Helping them to leave behind any fear about the change, sticking to the rules and finally letting them to freely and quickly reach a fluent way of performing (shu-ha-ri).

Here are some previous related posts:

• SCRUM training done: what’s now
• The magic wand coaching technique
• Facilitating the process of learning and growth of an agile team
• The Agile Team: a tribe or a theatral troupe?
• Team Members’ Profile Game

Scrum training done. What’s now?

The SCRUM training is already finished and now it’s time to start using it. But, how to start? Simple, start now, from where you are. 

Your company sent you and your team to attend to a fantastic two days scrum course. Your company knows how important the training is, especially when it’s a matter of change the way you worked since now. Your company also knows that at least for a while, an agile coach should collaborate with your team in order to facilitate the transition, helping you to go through it.

The company, hence, chose a smarter and clever coach

But, now? You could ask….now? It’s your time!

It’s time to start, really, sticking to the rules, participating proactively to the various meetings, using TDD in the right way. It’s time for you and your team to do, for example, more and better pair programming, to work actively with the customer and to reflect on team’s errors, trying to correct them, improving the process. It’s time to effectively communicate, collaborate, demonstrate honestly and frequently your progress.

In one sentence: it’s time to change the way, you all, worked since now…and often (always) that’s the real problem.

I noticed that every scrum class I had, agile and scrum are always well understood and the attendees completely agreed with what was explained. Furthermore, when the training is finished, they are thrilled, really motivated to start adopting it, as soon as possible. Obviously this is always a good news: a first important step toward the right direction.

But it’s not enough.

Infact, typically during the second or third iteration (depending on the duration of each sprint), the team enters in the storming phase (see Tuckman’s stages of group development) and they start to realize that adopting agile is not so simple, because it asks and requests a change, a strong change in their working habits.

Anyone is scared when facing changes: we are called to leave our habits, our certainties in doing things, by moving forward toward a place we don’t know. What the possessed trainer said about scrum, it’s now a foggy memory and the team, unfortunately, starts to think that such a methodology is not so amazing as s/he described.

This is the time when the team starts to use the new knowledge and often these new practices conflict with the old ones.

Some team members remain in any case aligned to what the agile discipline says because they are sure about it (they are the ‘allied‘: take care of them).

Some others complain but continue to stick to it: let the ‘allied’ convice them.

Some others don’t apply the new knowledge: you are directly called to coach these skeptics.

As Tuckman said during the storming phase, the team needs answers to their questions, to be reassured about the results they were promised.

This is a paramount passage and the coach should:

• check and verify how the whole process is applied
• reassure team members about their doubts
• understand what the main problems are
• coach the team, trying to help it to find the right answers
• coach any member who needs dedicated time, helping it to perform better
• proactively assist the team during the retrospective meetings
• reinforce important topics through dedicated training
• be sure that the scrum masters are perfectly aligned with the scrum foundamentals
• identify most motivated members, letting them to spread the knowledge, behaving as change agents

Finally, the coach must take in high consideration the relations with the other external stakeholders.

This means that she must engage them frequently, at least initially, communicating about progress and insisting on having them attending to the demo meetings: witnessing interest, curiosity and commitment.

Driving team talent, through passion, achieving excellence

The magic wand coaching technique

That’s enough for this post.
I’m going to talk shortly about the other coaching techniques in some future posts.
Have fun!

Force Field Analysis: an Agile Version

Everytime we learn something new, a practice, a tool or a technique related to our working activity, we naturally try to understand how that knowledge can be ported into our environment. It happens, indeed, that the most challenging things, even if fascinating and powerful, are often discarded with a superficial statement “it will never work with us”.

Everyone of us do not want to change their habits, do not want to leave their “lovely” comfort-zone, we are accustomed to it, it is familiar.
Even if we know that the old way of doing things doesn’t work anymore and we must change it, we want to approach to it smoothly, gradually, it would be better, indeed, if someone else will do it for us.

This happens every time to people that come from a traditional project management environment who are called to face the new agile discipline: most of the time they know very well the benefits of it, what kind of improvement it can bring and furthermore they know that agile is, above all, about changing their mindsets, their habits.

Initially, they make the error of thinking that agile is primarily a matter of using the right techniques and tools; they start to ask about which tool is better to manage the product backlog, which other tool can be used to write and decompose the user stories or, yet, what tool can be used to manage the task board in an electronic way.

Even in these cases, don’t give up!

Continue to explain the value of managing the user stories with index cards (face-to-face communication, direct negotiation, establishing a sense of trust with the customer), furthermore, that attaching and moving the tasks directly on the taskboard, during the daily meeting, is a ceremony, a moment where the team continue to learn about the project, the product, the other team members.
And, again, go on stressing the fact that the product backlog grooming activity is an important one, which must be done together with the product owner: directly, face-to-face.
What is paramount, in my opinion, is that the team and the other stakeholders, should really and honestly understand that agile is mainly a matter of collaboration and short-feedback and that is better to avoid the use of any remote and asynchronous communication tool, except for particular situations (distributed teams, maybe?).

When they realize that doing agile means, primarily, to change theirselves and how they did things so far, lot of doubts raise and even the better, the more detailed and the more honest explanation, is not able to convice them 100%,

That could be the time to use the Force Field Analysis tool, with some little adjustments to make it funnier.

First of all I ask a representative of the team, better if s/he is the most skeptical, to come at the whiteboard.
Then I ask the whole team to think at the agile transition as a journey, navigating the sea by boat (representing SCRUM) where the team is represented by the sail.
Actually what I ask to the member, is to draw the sea, the boat, the sail and to write on the hull of the boat the name of the agile discipline and on the sail the the name of the team.

Now it’s time for the team to elicit what advantages, benefits, strengths, agile embodies, which they can bring to their workplace, identifying them as the airstreams blowing into the sail, able to push the boat from the start to the finish-line.
These air flows shall be written and drawn on the top left area of the whiteboard (sky).

Then, I ask them to list the drawbacks and the weaknesses of implementing agile in their organization.
These are the contrary forces that work under the hull of the boat as marine drifts; those must be reported on the right bottom area of the whiteboard (sea).

Having this information written on the whiteboard, in front of them, help primarily to find any new advantage or drawback not already written but, more important, allow the team to compare the two groups and really understand how to cope with them.

The final part of the “game” is, to think how to exploit any single strength (opportunity) and for each drawback how to smooth, adjust, avoid or even accept it (risk), in order to let the boat reach the new land of agile where better results are awaiting for them.

Someone could ask: why cannot continue the old way of representing the force field analysis? The one that uses the tabular representation of it?
An explanation is that using metaphores (the journey, the sea, the boat, etc.) help people to better explain their feelings, abstracting from the reality and finally helps the brain in the process of memorization of concepts, emotions and ideas.

Be the the new year, an inspiring one! (AJRX49CFX279)

Team Members’ Profile Game

Source: Wikipedia

• Let everyone facing uncertainty
• Putting each one in someone other’s shoes.
  Actually, you are called to understand, feel, make it yours and finally explain, something that someone else thinks and feels.
• Communicate face-to-face with another attendee (team member)
• Practice the art of listening

The Agile Team: a tribe or a theatral troupe?

http://broadwayhour.blogspot.com

Belonging to a theatral troupe, actors work for a long period each one near the other, they are invited, sometimes obliged by the situations, to find the most effective working behaviors, sinergies and approaches in order to let the show hits the ground.
Any actor should have a talent, have studied and practiced a lot, know very well her part in the show. But this is not enough because she is called to adapt, adjust and tailor his artistic behaviour to the existing boundaries: the other actors with their parts, behaviors, skills and approaches.
Furthermore, the actors must limit theirselves and their behaviors within spaces (the stage, the scenes), timings (acts, show).
Finally, they use as well iterations when make the rehearsals.

http://humansarefree.com/2011/06/ten-commandments-of-native-american.html

Members that belong to a tribe, accept to share not only the usual activities such as hunting, providing for the maintenance of the tribe or, furthermore, fighting. They want to share also personal experiences, spaces, feelings, emotions, accepting rules and participating in rituals and ceremonies.

 

Hence, an agile team member, like an actor, should know the “theory” and should have practiced a lot. Every activity he does is limited in terms of time (iterations), space (the workplace). He should be able to communicate well enough to collaborate with the teammates and be effective working in a group. He will take advantage of the feedback coming from the iterations and discovering and learning form the experience.

An agile team member, like a member of a tribe, should accept and follows some rules, to find the right balance between his expectations and the ones of the group. He should trust the other members at least until his trust is betrayed and in my experience this does not happen too frequently in an agile team.

Actually the parallelism with rugby is somehow perfect. Scrum in rugby, is the way the members as a team operate to conquer the ball against the counterparts.