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)

Risks?!? TimeBox them!

Do you know why one of the pillar of  SCRUM is the time-boxing technique? Do you know the parkinson’s law or the student syndrome?

---

As you probably know, SCRUM uses the timeboxing technique to limit the time necessary for “everything”.

The meetings for example:

• Planning (aka kick-off): 8 hrs
• Daily (aka review): 15 mins
• Demo (aka phase gate): 4 hrs
• Retrospective (aka CPI – continuous process improvement meeting) : 3 hrs

The most important thing that SCRUM timeboxes, however, is the Sprint.

A predefined time (usually 2/4 weeks) used by the team, to implement the system/product/service, achieving part of the project objectives (those with the highest priority in that moment).

Within the sprint, indeed, all the meetings above reported are instantiated as already described here.

Why SCRUM locks in such a strong way the project timings?

Oh, maybe because the founders (Jeff Sutherland and Ken Schwaber) and the communities that developed the framework, known very well the parkinson’s law and the student syndrome!

The law of Parkinson cites “Work expands so as to fill the time available for its completion“. How many times do you verify that even if a project is ahead of schedule, the earned value remained 99% till the end planned?

What Parkinson wrote, is, again, totally confirmed by the student syndrome. It, infact, refers to the phenomenon that many people will start to fully apply themselves to a task just at the last possible moment before a deadline.

This is what the most part of students tend to do, me included, studying for an exam just few days before attending to it. Even if this will restrict them to study also every nights till the exam itself.

When instead the time is limited and the things to do are defined and well understood (even if avoiding an excessive grade of details), the people involved feel that like a challenge, a moment to test themselves, their expertise, the way how they collaborate and solve emerging problems.  A big chance for personal and professional growth.

The high grade of commitment aforementioned and the prioritizing approach in selecting the things to do, aim to two main advanteges:

• Realising faster the most valuable functionalities that the customer needs for its business
• Drastically lowering of the risks

Regarding this last point, having a short feedback cycle between the team and the customer thanks to limited duration of the sprint, helps the stakeholders involved to understand if any type of  adjustment is necessary. This, furthermore, arise  early during the project life cycle.

Finally, the risk is lowered also because the product owner should prioritize the product backlog, keeping as the most important features, those who have the major risk rate.

Stay tuned!

Risks Identification

Quanto ci possono aiutare sessioni mirate di brainstorming per l’identificazione e esplorazione dei rischi?
Come utilizzare le tecnica Six Thinking Hats di De Bono allo scopo?

---

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

Risk Management Checklist

Riprendiamo un argomento fondamentale per favorire il successo del progetto: la gestione dei rischi. In un precedente post ho descritto un possibile approccio alla definzione dei rischi, in questo post cercherò di evidenziare aclune aree da indagare per abbatterli.

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.
Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.
This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

Risks Analysis

Questo post apre un argomento piuttosto interessante: il risk management.
Tratteremo qui alcuni principi base per poi, in futuri interventi, dettagliarne tecniche, modalità e approcci.

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.
Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.
This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.