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

When teaching in a SCRUM course, there are two major objectives I want to achieve shortly: create trust and collaboration among the attendees and let them to feel as a team.

Both the objectives above reported, are ambitious and challenging: it is such a difficult thing to achieve when individuals know each other very well and for a long time, how is it possible with people that meet each other the first time?
Of course it is difficult, but in my opinion it is necessary (mandatory)  to create such a climate (environment) to facilitate the process of learning of the attendees (process of collaboration between the team members).
So, usually I start my courses with a  collaborative game called “Team Members’s Profile” that is a combination of some agile habits (make avatars representing each team member to use with index cards and task board) and a game (write and share with others something of yourself) and that makes use of a brilliant metaphor to represent the team: the A-TEAM (do you remember the serial TV?).

Source: Wikipedia

Such a team, altought a little rude, is able to reach every target and accomplish to every mission and is a perfect example of a SCRUM team. Its major strength is its cross-abilities. Every team member of the A-Team, brings in his own skills that no one other possesses and is precisely the mix of their skills that allow them to complete succesfully their missions.
Coming back to the example, after the introduction of the A-Team metaphor, I want every team member express his/her own subjectivity, asking them to take a post-it note, draw their avatar on the left top area and write the most important things/words/adjectives of themselves, they want to share with the others attendees.
When finished, and before giving them the possibility to describe the avatar and to explain what they wrote, I ask the attendees to choose the most important thing they wrote and to state it as a phrase/statement, on a new post-it and finally fold it in two parts.
Then, I ask the attendees to pass for three times the post-it to their neighbour, in order to be sure that each one receives a post-it they do not know.
At this point I ask the attendees to form groups of twos (the two members of each group, should not know each other), to read the statement written in the post-it and, in two minutes, to explain to the other person what they read.
What I stress the most, is that they should try to communicate, better as they can, their personal interpretation of the message.
This exercise aims to different results:
  • 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
We have three rounds and, finally, I ask the attendees to explain the first original post-it (that with the avatar), give insights about the statement on the second one and finally stick it at the “A TEAM WALL”.

Connecting school and work worlds, through Project Management

December the 10th and 17th I gave the first two lessons at Badoni High School of Lecco.
This is the third year I had the pleasure to collaborate with it, aiming to create a connection between the school and the world of work using project management as a mean.

This year the collaboration is even more important because we have three classes involved and we are having, in total, four lessons between december and january.

Maintaining high levels of concentration when talking about project management to students that are eighteen years old, is not such a simple task. I struggled a little but it is seems that I achieved it.

I decided not to bore too much those guys with things like project plans, WBS, estimations, risks nor with practices like pair-programming, stand-up daily meetings and so on.
I concentrated my speech the most on things like what is talent and how to feed it, the importance of learning the theory and put it in practice.
I stressed the centrality of communication and collaboration, let the collaborative games help me in this due.
Up to now, it has been an exciting experience.
I sincerely hope that the little seed that was planted, will be watered by the enthusiasm and passion of the boys and girls I had the pleasure to meet.

Video of my talk at PMI-NIC Agile Project Management Event

This is the video of the talk I held December the 2nd in Milan at the Agile Project Management, regarding the product owner and how to adjust a bit his duties and responsibilities in order to create bridges between the traditional and the agile way of conducting projects (PMI-NIC Agile Project Management, Lightning talk at APM: Beyond SW Development (PMI-NIC))

 

PMI-NIC Agile Project Management

During this year I participated in several agile events. Some of them were arranged by agile organizations, some other self-organized by agile communities. December the 2nd I participated to an agile event organized by the PMI (indeed it was the Northern Italy Chapter).

The event was interesting to me because of three major reasons: the international speakers who have been participated, the fact that I had have the opportunity to present my personal experience with agile to an international audience and, finally, the fact that one of the PM communities to which I belong to, the first membership actually, demonstrated interest and proactivity in surfing the agile wave.

One of the speaker was Sanjiv Augustine, the author of the first book I read, several years ago actually, regarding agile topics: “Managing Agile Projects”.

 

I found that book very interesting because it describes with a high degree of detail the way how agile practices could be applied to the software development process, reporting examples from real working life, but also it explains very well more absctract concepts such as complex agile systems, but in a pragmatic and concrete way.

 

Sanjiv is a superb speaker. During his intervention he gave to the audience, a huge quantity of qualitative information providing time to time, also specific cases and examples that helped to fix the knowledge just acquired.
My speach, instead, was about the role of the product owner in SCRUM and how it can be adjusted in order to facilitate the communication, the collaboration and the sinergies with the customer.

 

 

The assumption I did was that even if most of the benefits coming from SCRUM are due to sticking to the rules and observing the whole process, it could happen indeed that the customer doesn’t want to be so much involved in agile or, furthermore, that he is fond of the traditional way of managing projects.
Even in these case we try to adapt out behavior to the situation, trying to:
  • deliver value to the customer in a steady pace
  • involving as much as possible the customer with agile
  • adopting the communication style to and supplying project progress data the customer wants (adopting the “barely sufficient approach” Alistair Cockburn suggests)

 

 

Finally, I was very happy to find many people so much enthusiast in the agile topics and, moreover, the fact that the PMI-NIC has been and will be, one of the change agent of the agile transformation, at least in Italy.

WordPress Themes