Programme and Project Management blog community

This blog is proudly part of the Programme and Project Management blog community.

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

Connecting school and work worlds, through Project Management

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

• 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)

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.

SCRUM Simulation, the Resort Brochure Collaborative Game

On thursday and friday 24th and 25th, I gave a SCRUM training course for the European School of Project Management in Turin.

One of the most important thing, in my opinion, when in a training course you talk about a project team and its ability to collaborate, self-organize, learn from the experience, and communicate effectively (that’s SCRUM actually) is that you should find a way to let the attendees, work as a team, in order to test the knowledge just learnt, simulating one or more iteration sprints.

I know some collaborative games, such as SCRUM lego city game, that can be used to simulate SCRUM and iterations, but I prefer the resort brochure game or product box collaborative games because they are easier.

On friday, during the last hour of the course, we played the resort brochure game.

Let’s see what it is and what are the rules of the game.

Create teams of 5/9 people.

The goal is to create a brochure for a brand new resort. The brochure should contain the right layout, messages, images  in order to promote the activities and the strengths of the resort.

First of all, the team shall create the user stories in terms of how and what the resort should be (e.g. As a manager, I want meeting rooms, completely accessoried, where I can arrange business meetings, so that I can arrange projects’ kick-off or As a husband, or  I would a resort with a spa inside, so that I can celebrate my wedding anniversary).
During this phase, the team should also choose a product owner which is in charge of prioritize the user stories, write them down in index cards and put them into the task board in the TODO or Backlog Items column.

This period should last no more than five minutes.

Then, the team is ready to start.
Arrange 2/3 iterations of 3 days (5 minutes each day, a total of 15 minutes for each iteration).
The team starts the first iteration conducting the sprint planning meeting, during which the members decide about what stories they commit to finish and asking for some more details to the product owner.

Every day starts with the Daily Meeting, the team members say about what they did the day before moving the index cards through the taskboard, what they are going to do during the current day and finally if they have any road-block; immediately after, they begin to use scissors, rulers, glues, markers, paper to create the product: the resort brochure.

When an iteration finishes, the team shows the results to the stakeholders in order to demonstrate how is going and to elicit any feedback in order to adjust the product.

Actually, what the attendees of my course did yesterday, was amazing. They unfortunately hadn’t have three iterations because of time, but only one and what they produced was incredible.

I saw a great collaboration between them, one member of the team was actually a graphic and she facilitated the birth of the concept and the layout definition; the team decided what kind of images to choose and how to arrange them.
Another attendee was in charge to propose some claims and inspiring message to introduce into the brochure. The other ones helped the graphic cutting images from magazines, drawing, writing, glueing, composing the brochure.

I think that this games worked so well because most of the attendees were women. Actually the men helped but actually, they were not so confident with magazines, scissors and rulers.

With courses where the most part of the attendees are men, I use to play the Product Vision Box (Managing Agile Projects, Sanjiv Augustine). The scope of this game is similar to the previous one in terms of materials to use, but the team must create the box of a product. The team shall decide about which product they want to sell and after they decide about the box layout.

Facilitating the process of learning and growth of an agile team

Every time I teach in a course, whatever the content, even if the organizer tried to arrange the classes in a balanced way in terms of experience level of the attendees, it happens that someone knows less than the others regarding the area I’m going to talk about.

In these cases, I try to keep aligned the class starting from the basic concepts, avoiding to be excessively detailed and trying not to annoy the experts. Then, when I switch to the advanced topics, I make a great use of metaphores: it helps to catch the gist using past experience, idioms or whatever could sustain the interest of the whole class.

It happens, though, that the experts patiently wait for some more details and once supplied, the novices start to shake their heads, looking at me somehow “lost in transactions”.

This happens because it is usual that, when we are called to learn something new, we should pass through three different stages:

1. Following
2. Detaching
3. Fluent

Alistair Cockburn explains this theory very well here. That theory, actually, is somehow inherited from the Shu-ha-ri martial art japanese concept, which describes the stages of learning to mastery.

ShuHaRi - Wikipedia

When we are learning something new, something not easy, we are completely dedicated to understand the topic, circumscribe it and finally derive a method that could help us facing that new knowledge.

Any additional information, alternative, tip or trick is not well accepted during this phase, most of the time is discarded as “waste“, because during this step we only want to learn the easiest and most effective approach to “survive”: other data is entropy.

At least for a period of time that can vary from one weak to 6/8 weeks (depending on the complexity, etc.), we are called to practice the new knowledge, inspecting and adapting our approach in order to verify what we learned. It’s during this phase that we feel the  necessity to find other ways to solve the problem, exploring new paths.

Mary Poppendieck - In theory there's no difference between theory and practice, in practice there is.

This is the exact moment when we enter the second stage called detaching (or leaving).

We are no more satisfied of what we have learned so far, probably we found some flaws, we want alternatives, walkarounds, more detail regarding the problem and what causes it. That’s the moment to come back to books or teachers learning something new.

Again it’s a matter of time and dedication. Lot of water has to pass under the bridge, we just need to practice the new knowledge, like when we learn to swim. In that occasion we repeated the same movements many times, again, again and over again, letting that “knowledge” passes from the conscious to the unconscious mind, also called “muscle-memory“, that digests that knowledge and makes it available, automatically.

Papua New Guinea proverb: Knowledge is only a rumor until it’s in the muscle

Finally, the water passed under the bridge and we don’t strive anymore to use the knwoledge: it is part of us. It happens and that’s enough.

As it happens to trainers to have course’s attendees with different level of knowledge, it happens to team leaders or coaches, to have teams that comprise both juniors and seniors members.

In this case the XP practice of pair-programming help-us.

Pairing helps juniors when they are navigators as well as drivers.

As “navigators” they have the possibility to see, ask and verify new approaches, techniques, tools and as “dirvers” they can practice what they just learned, being corrected immediately in case of errors. Both situations take advantage of one of the most important values of agile discipline: the short-feedback-cycle.

And what if we don’t have aboard any senior team member? In this case we as Scrum Master, Agile Coach or technical leaders, are called to get our hands dirty, pairing with the juniors and bringing some new fresh air by teaching new things, concepts, approaches.

This could be the moment when we cross over the Tuckman’s theory.

Tuckman's Theory: Forming, Storming, Norming, Performing

1. Forming
2. Storming
3. Norming
4. Performing

During the first stage (forming), the team listen to what you’re saying trying to accomodate this new knowledge with the one they already have: they don’t want to argue, they only want to learn and understand how to apply new knowledge.

During the storming phase, instead, different ideas and perspectives grow, they don’t want to change or they fear changes: but most of the times it is only a matter of listen to their doubts, assuring about the goodness of the theory and finally practicing, a lot.

This for sure will happen the first time a team embraces SCRUM: the first iterations aren’t so easy and the team will try to force to change the rules of the game, trying to cut some practices or changing some behaviors.

In these case is very usefull to put in practice what Jeff Sutherland called the Shock Therapy that can be summarized as follows:

1. Train the team
2. Set iteration length to 1/2 weeks, in order to have a short feedback between what the team does and what are the results
3. Set Definition of Done
4. Large use of information radiators
5. Respect any SCRUM meeting
6. Do not change anything before three months

Furthermore, he used to say to the team the first time it entered the workplace, that it is like when a karateka enters in a new Dojo. Above the entrance there’s a poster saying

“Forget what you know about karate,
forget your way of doing that,
this is my dojo,
you all are asked to do it my way“