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

Agile and Complexity

Complex Systems

• enhance simplicity
• high feedback exposure and exploitation
• continuous process improvement
• communication effectiveness
• fond of talent and technical excellence
• clear roles and responsibilies
• keep networks connected

Enhance Simplicity

High Feedback Exposure and Exploitation

Continuous Process Improvement

Communication effectiveness

Fond of Talent and Technical Excellence

Clear Roles and Responsibilies

Connecting the different Networks

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)

Conducting the user requirements gathering interview

Do you know how to conduct that kind of interviews having success?

The most important rule is: forget about your technocratic vocabulary.
One of the most cited complaints from the users towards the IT staff is:

“I do not understand a word. Too many acronyms and tehcnical words.
When I’ve asked for explanations it seems they were so annoyed!“

With that in mind, prepare yourself to the interview, by studying as much as possible about the business domain the product will be applied.
Analyze the business processess, the input and output data.

Gather information from internet, look for any competitors’ solutions/products already existing. Talk with any experts in your company trying to better understand the logics of that area.
Compile a glossary containing any jargon, abbreviations and acronyms.

Ok, let’s move on the next step.

Arrange the meeting following these rules.

The meeting shouldn’t lasts more than one hour, the attention will drop down inexorably after that time.
Take into account an extra time of fifteen minutes before and after the interview, for collateral activities such as email sending, phone calls, etc.
Keep the last 10 minutes of the interview for a Q&A session.

Create the agenda of the meeting and send to the participant at least the day before.
The meeting shall be take place neither in your office, nor in the one of the interviewee, otherwise too many distractions will occur and, furthermore, the interviewee or you will not be confident to completely openly speak.

Now it’s time to proceed with the interview.
Create a calm environment.

Remember that you must instaurate an environment in which the comunication should freely flow: expose clearly the objectives of the meeting and what are your expectations. Be assertive and remember that your first goal is to listen and not to speak.

In general, try to pose short and simple questions: no hyperbole,
the technicalities are banned!
The questions itself should not influence the answers:

“Isn’t true that the application will be used only by the accountant users?”

but rather

“What kind of users will use the application?”

Remeber, during this phase you must remain concentrated on the problems: do not yet think about the solutions.
The user wants to be heard, s/he wants to be sure that you understood his/her problems.

Start asking general questions: your goal in this initial phase is to obtain as much information as possible,
posing fewer questions.
Avoid any questions to which is possible to answer with a yes or a no.

• What are the main necessities?
• To what problems is necessary to find solutions?
• What happens today that should be changed in your working enviroment?

When the overall scenario is well delineated and understood, pass to the second step by gathering detailed information about the most important points: what is unclear to you, what is more complex, what are the processes and data involved (probe questions).

During this phase try to catch any nuances, redundant concepts, any special emphasis in what the interlocutor is saying, because those things bring quality to the message.
Be aware also of any dissonances you feel, because it is a trigger that something is not clear or that you don’t agree with.

A well-structured process in conducting an interview should be:

• General questions
• Probe questions
• Explore any open points
• Gather data and examples
• Find an agreement by repeating the main points

Finally, during the interview, try using the same words, acronyms or abbreviations the interviewee uses.
Reflect his/her posture, gesture and voice tone, you should be well tuned with him/her.
Rephrase what s/he has said, giving and obtaining feedback.
Some healthy NPL never hurts, isn’t it?!

The SWOT: an innovative tool for agile retrospective

Yes, of course I’m joking, the SWOT analysis isn’t an innovative tool, but have you ever use it for analysing how an iteration has gone?

Hi there, holidays are over and a new working year is ready to start!
During my vacations I read a lot about agile retrospectives and it was an opportunity to compare the techniques and the tools mentioned in those books, with the ones I use in my everyday working life.

What actually I did not found is one of my preferred tool: the SWOT analysis.
That tecnique is so versatile that can be adapted easily. It was born to be used mostly for conducting marketing activities to devise new products.
On the other side, that of the traditional project management approach, it was applied to the projects in order to conduct the risk identification phase.

Actually, I use that technique at least in two other occasions.

Firstly, when I want to stimulate and accompanying the growth process mine and of my colleagues and team members. I help them to identify, related to their job and daily working activities, what are their strenghts and weaknesses in order to understand which opportunities could be developed and to what weaknesses they are exposed to.
Secondly, it is a fantastic tool to conduct a retrospective meeting. How? Let’s go!

As the major part of you already know, an agile retroscpective meeting is a meeting that usually lasts 4 hours, which is held at the end of a sprint (iteration), just immediately after the team has shown what it was developed (demo meeting).

The scope of this meeting is to reflect about what was good and what was bad about the last iteration. Considering the necessity to help people to actively participate and freely express opinions, ideas and any doubts, it’s better (read as mandatory) if that meeting is opened only to the the team, the scrum master, and the product owner (but only as a spectator).

Once the environment is ok and the meeting is open, distribute to the participants the SWOT matrix template and ask to each to address their thoughts on the iteration just concluded.
The focus is on the tools and techniques used, the approaches and behaviours kept by the people involved, the things happened during the iteration.
It is mandatory to absolutely avoid any direct reference to collegues, rather indicate the behaviour that should be rewarded or penalized, never cite an individual.
Remember that it is not a matter of finding the guilty, it’s a matter of improve performance and why not, to work better with sustainable paces.

Compile

The first quadrant contains the strenghts: which attitudes, behaviours, approaches were good. What, in the end, shall be reiterated to actually continuing to bring real worth to the project.

The second quadrant is a container of weaknesses (please do not confuse it as a garbage bin, there’s much to learn from our weaknesses): think of what has gone in the wrong way and analyze what is missing and where the problems were.
Think about the bad effect that was caused by the problem and try to conduct an analysis in order to climb to the root reason.

Now it’s time to concentrate on what could be exploited and what should be avoided: respectively the opportunities and threats quadrants.
The opportunities quadrant should comprise a list of “good things/objectives” the team/project/sprint could reach in case of investing in improving the strengths or bridging the weaknesses above reported. If possible connect each opportunities or threats to the relative strenght or weakness.

On the contrary the threats quadrant is reserved to the consequences that could arise in case no improvement is put in place.

Arrange

When every team member has finished to compile the “SWOT”, it’s time for each of them to write on a white-board, flip-charts or sticky notes both the strengths (good things) and weaknesses (bad things) giving insights regarding the opportunities and threats that they can bring aboard.

When finished, the agile retrospective leader (role that should be assigned in rotation to every team member), tries to identify which items are duplicate, eliminate them and  the remaining are grouped, clustering them under a category, a word, a statement that clearly explains them.
Now you have a well arranged situation of what has been the iteration just finished, in terms of good and bad things: solicit the team to devise and propose activities that aim to solve problems and enhance the performance according to what above reported.

Vote

And, finally, it’s time to vote: do you know DotVoting?
Simply assign a predefined number of votes to each team member that he can distribute on the activities.
Everyone can assign one vote for each desired item or assign all the dots/votes to one item, if they feel that is an important one.

Arrange the result as a bar graph (do you remember pareto and the 80/20 rule?) and pick the most voted activities, those must be executed during the course of the next sprint.

Final Considerations

• Do not put into the pipeline too many activities for the next iteration; most of the time it is better to process one at a time.
• Try to focus on the strenghts instead of weaknesses.
  Try to maximize the benefits coming from what the people can do better: their talents and qualities.
  It is more difficult to work on weaknesses.
  Obviously, if the weakness has an heavy and bad impact on the team/project/sprint, do not hesitate to deal with it.
• Everyone during the meeting should actively participate: your responsibility as a Scrum Master is to go along with the retrospective leader and stimulate who is not actively participating or try to contain who tends to speak to much or has a coercitive approach.
• Keep in mind these three words: APDC, CPI, Kaizen. They teach us to continue to improve the process, even a small adjustment can lead to great improvements.

The big elephant in the room

“Elephant in the room” is an English metaphorical idiom for an obvious truth that is being ignored or goes unaddressed. The idiomatic expression also applies to an obvious problem or risk no one wants to discuss. It is based on the idea that an elephant in a room would be impossible to overlook; thus, people in the room who pretend the elephant is not there have chosen to avoid dealing with the looming big issue. (Wikipedia)

During the last weeks I have given some training sessions regarding project management topics (gathering user stories, planning, estimating, communicating, etc.). What I did, and in some cases what was explicitly asked for by the clients, was to speak about those topics from a traditional point of view as well as the agile one (Might I lose the opportunity to talk about agile?!).

Well, the courses were done for big organizations such as banks, assurances and a multinational that produces energy and it happened that when we have finished to analyze the two different approaches, it was clear to all the attendees that in some situations (telling the truth the most of them) the agile approach in planning, estimating, communicating and conducting the project, would be definitively the best one.

Indeed, some of the attendees exasperated by the problems they encountered, said that they already have tried to embrace agility, changing their approach in estimating activities, trying to be more adaptable in managing the changes and fostering the collaboration between all the parties involved in the project, but, systematically, they had to give up, due to problems and frictions with other colleagues.

People, most of the times, don’t want to change.

They do not want to change approaches, mental schemas, “habits”, because this implies:

• an effort that they don’t want to pay
• they do not want to leave their “lovely” comfort zone
• they have fear to loose power or control

Surprisingly, this happens even if it is clear to all that they have big problems in managing projects, even if they know they cannot face to projects’ changes smoothly, even if they know they cannot be more productive, faster and cannot improve the overall quality of their products, without a change.

They pretend not to see, the big elephant they have in front of them, which is staring at them, a bit embarrassed, trying not to move too much.

That problem is even more bigger, if the people who deny the existence of such an elephant, are the managers, the bosses, the decision makers.
The employees, after some trials in convincing them, could give up, surrendering to such a strong resistance.

This situation is a catastrophe for each of the parties.
The employees stop working assertively.
The boss looses the esteem of his/her colleagues and a great opportunity to improve the overall performances.
And, finally, the whole company, soon or later, will lose the most talented people, because for sure, they will not accept for a long time, such a frustrating situation: instead of being considered worthwhile “change agents”, the company treats them as annoying people.

PNL e Project Management 2^ Puntata

Sono diverse le occasioni in cui, come project manager, potremmo essere chiamati a parlare in pubblico.

Indipendentemente dal numero di persone che ci troveremo di fronte, dovremo essere preparati, efficaci nel modo di comunicare. Perché non farci aiutare da qualche tecnica? Il sistema 4MAT per esempio!

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.

PNL e Project Management

Siete buoni comunicatori?  Comunicate in maniera efficace?
Come ve la cavate quando dovete negoziare risorse, budget o tempi di progetto?
E quando dovete presentare trend e risultati al management?

Le capacità di un buon comunicatore sono spesso innate: hanno molto a che fare con la sensibilità personale e la percezione di noi stessi e del contesto in cui ci muoviamo.

Fortunatamente la programmazione neuro linguistica ci aiuta ad allenarle: ne gioverà sicuramente il nostro progetto ma trarremo vantaggi anche nella vita di tutti i giorni.

Per essere buoni comunicatori bisogna innanzitutto sentirsi a proprio agio nel contesto in cui ci troviamo, essere ben predisposti e utilizzare un linguaggio e un approccio positivo.

Dobbiamo in ogni momento essere consapevoli del fatto che ognuno di noi ha un proprio modello del mondo derivato dalle sue esperienze, pensieri e propensioni.

Tenerlo in considerazione e adattare il nostro modello di comunicazione è un vantaggio: l’interlocutore sarà automaticamente (inconsciamente) ben disposto ad ascoltarvi dato che parlate la sua “stessa lingua”.

Il modello che ognuno di noi si è creato è possibile riconscerlo da tre fattori: linguaggio, uso della voce, fisiologia.

A tal proposito la PNL descrive quattro principali sistemi rappresentazionali:

• Auditivo
• Visivo
• Cinestetico
• Auditivo Digitale

Sistema Auditivo

La persona che ha questo come modello di riferimento, dà molta importanza ai suoni: li apprezza, li sa riconoscere, spesso le senzazioni e i ricordi sono legati a suoni specifici, riconoscono facilmente i diversi dialetti.

Rimangono ammaliati dal suono delle cose: a loro piace ascoltare musica, parole, racconti; danno molta importanza al suono della voce, al timbro, al volume, al ritmo, alla velocità con cui si susseguono le parole.

Se il nostro interlocutore predilige questo sistema, dobbiamo dare enfasi nei nostri discorsi a parole che richiamino suoni, utilizzare in maniera particolareggiata la voce, accentuare le pause, utilizzare correttamente il timbro della voce per effettuare sottolineature.

Sistema Visivo

Queste persone ragionano per immagini, spesso i loro movimenti mentre parlano sono veloci, repentini, quasi a scatti.

Se fate loro delle domande che implicano un ragionamento spesso li vedrete guardare leggermente in alto, comunicheranno molto velocemente perché le immagini nella loro mente scorrono e loro le devono rincorrere per potervele raccontare.

Quando parliamo con essi dobbiamo prestare attenzione all’utilizzo di parole che evochino immagini, le possiamo descrivere con minuzia e la nostra comunicazione dovrebbe essere incalzante, con un buon ritmo, un tono di voce piuttosto alto, dobbiamo produrre nella loro mente una sequenza di fotogrammi che facilmente interpreteranno e memorizzeranno.

Sistema Cinestetico

Queste persone danno molta importanza alle sensazioni, hanno un rapporto molto intimo con esse e riescono a descriverle in maniera particolareggiata.  A loro piace molto toccare le cose, annusare gli odori, osservare.

Hanno un ritmo della parlata più lento, con un timbro di voce spesso basso e profondo, si sà, le emozioni vengono dalla “pancia” ed è da lì che le devono andare a riprenderle.

Con queste persone comunichiamo con sensazioni, emozioni, metafore particolarmente evocative.

Non occore parlare velocemente e dobbiamo farlo con un ritmo sicuro, ma con voce calma e che contempli pause per dare loro il tempo di “digerire” il messaggio che stiamo comunicando.

Sistema Auditivo Digitale

Queste persone sono molto pratiche.

Ragionano per dati, logica, numeri, processi. Analizzano, comparano e trovano soluzioni.

Vogliono dati oggettivi su cui impiantare ragionamenti per deduzione (proprietà transitiva) che cercano poi di smontare attraverso negazioni o eccezioni.

Valutano razionalmente implicazioni e sono in grado di correlare facilmente le informazioni.

La nostra comunicazione dovrà essere orientata alla concretezza e praticità. Le nostre presentazioni dovranno prediligere grafici, tabelle, comparazioni. Dovremo fornire le motivazioni, dimostrarle attraverso dati e numeri, fornire subito eventuali eccezioni e spiegare come saremo in grado di gestirle.

Li riconoscerete dal fatto che vi staranno ascoltando guardando inensamente voi e i dati che avete sottoposto, tenendo le braccia conserte, oppure con una mano sotto il gomito e l’altra a reggersi il mento, valutando ogni singola parola, ritti sulla spina dorsale.

Ma cosa fare se stiamo parlando a più persone?

Come faccio a capire a quale sistema appartengono?

E anche se riuscissi a riconoscerlo, come potrei parlare loro contemporaneamente in tutti gli stili sopra descritti?

Beh, sicuramente non è semplice.

Certo conoscere la platea a cui ci stiamo rivolgendo è importante. Potremmo per esempio scegliere quali sono gli stakeholder più importanti per la nostra presentazione e utilizzare soprattuto il loro sistema rappresentazionale.

Ma spesso ci troviamo di fronte a persone che non conosciamo cosi a fondo e allora potremmo usare lo schema:

K -> A -> V

Questo schema ci suggerisce di iniziare la nostra presentazione utilizzando il sistema cinestetico, passare all’auditivo e finalmente terminare con il visivo.

Perché?

La prima regola è di non commettere l’errore di partire con il visivo, saremmo troppo veloci, incalzanti, in qualche modo dissonanti per gli altri sistemi, soprattuto il cinestetico.

Partire con quest’ultimo infatti permette di conquistare sin da subito quello più “lento” e in qualche modo più complesso in quanto bisognoso dei propri tempi di reazione.

Una volta conquistata la fiducia di queste persone, saranno quindi ben disposte a seguirci quando cambieremo lo stile in auditivo.

Questo stile fa un uso molto incisivo del senso dell’udito e anche i cinestetici lo apprezzeranno perché spesso le sensazioni sono facilmente associabili ai suoni.

E i visivi?

I visivi saranno abbastanza annoiati. (

Si chiederanno perché siete così lenti ad arrivare alle conclusioni, perché il vostro tono della voce è cosi basso.

E perché mai fate tutte quelle pause?

Ma proprio quando si staranno chiedendo se hanno fatto bene a presenziare al meeting in corso, ecco che voi cambierete ancora registro e comincerete ad incalzare il pubblico.

Il vostro racconto si animerà e comincerete a legare necessità, obiettivi, trend e risultati del progetto, a immagini vivide, capaci di conquistare anche loro, e anche in poco tempo. Ricordate? Loro sono persone veloci!

Ah, un ultima cosa: nel vostro viaggio attraverso i tre sistemi, non dimenticate di fornire anche qualche dato, numero, grafico, descrivete con precisione i processi coinvolti nelle decisioni.

In caso contrario rieschiereste di perdervi per strada gli auditivo-digitali!

Alla prossima e…non cambiate canale, sono in arrivo nuove puntate sull’argomento!

Be good!

Planning a kick-off meeting

Un buon kick-off è garanzia di successo del progetto?

Un paio di giorni fà, ho condotto presso un cliente il kick-off di un nuovo progetto.

Progetto non particolarmente complesso nei suoi requisiti, che però nasconde diverse insidie in quanto obbliga un’interazione e integrazione molto forti con i sistemi del cliente, vede coinvolti diversi stakeholder, alcuni dei quali fuori dall’Italia e che, infine,  impone un adattamento a standard procedurali e di documentazione in uso presso il cliente.

La fase analitica inziale che ha dato vita alle stime e all’offerta, non è stata particolarmente dettagliata; diversi erano quindi i punti aperti e i dubbi circa alcune implementazioni.

Il kick-off sarebbe stato quindi momento fondamentale per cercare di chiarire al meglio quanto era ancora sfumato, privo di contorni nitidi.

Ho voluto affrontare il tema facendo uso di una mappa mentale in cui potessi raccogliere tutte, e dico proprio tutte, le tematiche che sarei andato a discutere nel meeting.

La prima cosa che ho fatto, è stata quella di fare una review completa di tutta la documentazione a mia disposizione suddividendo le tematiche nelle seguenti categorie:

• Open Points, in cui ho raccolto tutte le questioni non ancora chiare alle quali si sarebbe dovuto dare risposta nel kick-off
• Functionalities, categoria nella quale ho raccolto tutte le funzionalità del prodotto, implementando rami gerarchici a raggruppare funzionalità dello stesso tipo, in stile WBS
• References, tutti i documenti di riferimento (allegati alla mappa) che hanno dato luogo alla formalizzazione del plan di progetto
• Systems Involved, i diversi sistemi (hardware e software) esterni coinvolti, con i quali l’applicazione dovrà dialogare
• Application Roles, i diversi ruoli applicativi con relativi permessi
• Stakeholders, le persone coinvolte direttamente o indirettamente dal progetto
• Risks, la categoria che raccoglieva una prima analisi dei rischi

Grazie a questa prima iterazione, la mappa ha cominciato a prendere corpo.

Con l’aiuto di un membro del team che si occuperà dello sviluppo, si è proceduto alla scomposizione delle funzionalità in attività; questo ha permesso di delineare la WBS (allegata in formato excel alla mappa) e sulla quale è stato possibile procedere con stime di dettaglio (primo riscontro della mia stima draft fatta in fase di offerta).

Al kick-off ci siamo voluti presentare subito con i layout di esempio delle pagine dell’applicazione, per permettere a tutti di discuterle e di trovare da  subito condivisione sulle interfacce e sulla loro navigabilità.

Anche questa presentazione è stata allegata alla mappa.

Un altro passo è stato organizzare le funzionalità in deliverable del prodotto.

Questo punto è stato ispirato dalla metodologia agile:

• rilasci frequenti e temporalmente vicini
• inclusione già primi rilasci delle funzionalità più importanti (customer business value)

Sono state quindi identificate 4 deliverable, a rilasci distanziati di circa due settimane lavorative l’una dall’altra, includendo le funzionalità più importanti nelle prime due.

Quest’ultimo punto permetterà di:

• innalzare subito l’attenzione del cliente perché in grado di verificare subito le funzionalità più importanti
• garantirci una maggiore “probabilità” di feedback sulle deliverable
• fugare sin da subito dubbi o malintesi sulle funzionalità più importanti invece di scoprirlo alla fine con conseguenze dannosissime

Ho,infine, aggiunto:

• una categoria “Legenda” che riportava le descrizioni delle diverse icone o simboli grafici presenti
• una categoria “Agenda” che riassumeva i macro-punti che sarebbero stati discussi nel meeting
• Una categoria “Attendees” che elencava i partecipanti al kick-off

Il kick-off è andato benone.
Ho potuto mostrare la nostra idea di implementazione del progetto e raccogliere diversi suggerimenti, correzioni, aggiustamenti da parte del cliente.

I punti nella categoria “Open Point” sono stati tutti completamente evasi ed hanno ricevuto le risposte attese.

Gli stessi, a fronte delle risposte, sono stati inclusi nella categoria “Decisions”.

E’ stata prevista un’ulteriore categoria “Action Points” in cui sono state aggiunte le azioni immediate che si sarebbero dovute svolgere e a carico di chi.

Infine sono state aggiunte alcune segnalazioni nella categoria “Risks”.

La mia mappa alla fine conta le seguenti categorie:

• Legenda
• Agenda
• Attendees
• References
• Functionalities
• Stakeholders
• Systems Involved
• Applications Roles
• WBS
• Draft Layouts
• Deliverables
• Decisions (prima chiamata Open Points)
• Action Points
• Risks

Ora non mi rimane che utilizzare una delle funzionalità di cui sono più innamorato di MindJet MindManager: l’esportazione in word. Questo permetterà la redazione della meeting minutes in pochi minuti, la spedizione agli altri partecipante del kick-off e finalmente….possiamo cominciare a lavorare.

Un buon kick-off non garantisce certo la riuscita del progetto, ma sicuramente siamo riusciti a creare commitment, responsabilità e chiarezza su cosa e come dovrà essere fatto il lavoro e chi e quando dovrà essere svolto.