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.

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.

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“

L’importanza del team

Se vuoi arrivare primo, corri da solo.
Se vuoi andare lontano, cammina insieme agli altri.
(proverbio del Kenya)

L’importanza del gruppo è risaputa e assodata.
E’ vero, il singolo è agile e risponde velocemente ai cambi di scenario, ma la fragilità dovuta a risorse limitate gli precludono molte delle strade percorribili.

La forza del gruppo deriva dal fatto che questo, nel suo complesso, ha risorse e conoscenze maggiori e, in teoria, nessun obiettivo gli è precluso.

La minore agilità potrebbe però pesare in situazioni che richiedono forte dinamicità.

Il team agile

La teoria agile ci insegna che se un team, comunque contenuto nei numeri, ha le caratteristiche che seguono, riesce ugualmente a fare fronte a situazioni di forti cambiamenti e flessibilità.

Caratteristiche principali di un team agile:

• Orientamento verso l’effettivo valore di business del cliente
• Competenze tecniche professionali elevate dei singoli
• Dimensione ridotta del team
• Auto-disciplina nella risoluzioni di conflitti
• Personalità dei membri orientata alla collaborazione
• Buone capacità di adattamento
• Disponibilità e apertura dei singoli, all’apprendimento

Un buon leader, quindi, deve essere in grado di scegliere le persone giuste e, dal mio punto di vista,  iniziarle alla disciplina agile, creando continui stimoli volti alla comunicazione e condivisione degli obiettivi.

In questo modo sarà per lui possibile puntare a mete difficilmente raggiungibili come singolo, ma più facilmente avvicinabili come gruppo.

Comunicare le responsabilità dei singoli

Altro fattore fondamentale nella gestione del team è la comunicazione.

Questa deve essere immediata, diretta (face-to-face), chiara, semplice (vedi post precedente ‘Comunicazione Agile’).

E’ necessario che ogni membro del team conosca in ogni istante le attività a lui assegnate e le relative responsabilità.

Per ottenere risultati certi è bene fare uso di strumenti di assegnazione delle responsabilità come i seguenti.

Diagrammi gerarchici:

• WBS: identificando il responsabile di ogni WorkPackage della WBS
• OBS: struttura gerarchica organizzata per funzioni, dipartimenti e persone che saranno coinvolte nel progetto
• RBS: struttura gerarchica organizzata per tipologia di risorsa, utile anche per tracciare i costi.

Diagrammi a matrice:

• RAM : usata per illustrare le connessioni tra il lavoro necessario e i membri del Team. Può essere vista come incrocio della WBS e della OBS.
• RACI (vedi post ‘Commitment e responsabilità’): particolare formato di RAM (Responsible, Accountable, Consult and Inform) che mostra anche il grado di  coinvolgimento ai vari livelli.

La delega

Il project manager ha un importante altro strumento per ottenere responsabilità e commitment dai membri del team e che, contemporaneamente, gli permette di “guadagnare” tempo sul progetto: la delega.

La delega è definita come il decentramento temporale di responsabilità senza modificare il ruolo del collaboratore perché è limitata nei contenuti e nel tempo.

Delegare significa quindi assegnare compiti e relative responsabilità ad altre persone, attribuendo loro gli strumenti di cui hanno bisogno per eseguirli, esigendo che rispondano dei risultati conseguiti.

Il processo di delega dovrebbe quindi tenere conto di:

• chi assegna la delega e chi la riceve
• a cosa è circoscritta la delega (contesto)
• quale responsabilità comprende la delega (raggiungimento obiettivi)
• quali gli strumenti forniti al delegato
• come misurare il risultato della delega

Crescita del team

Una volta responsabilizzato e allineato il team, è necessario poi procedere a svilupparne le competenze, sia in termini di technicalities sia di soft skills.

Questo è possibile dedicando l’opportuna attenzione alle seguenti tematiche:

• Fomazione: tutte le attività volte a migliorare le competenze del team.
• Team building: attività volte a migliorare la coesione tra i membri del team.
• Ground rules: stabiliscono regole chiare (ricordate la KISS rule?) per quanto riguarda l’approccio lavorativo dei  membri. Riducono conflitti e incomprensioni.
• Co-location: collocazione fisica dei membri del team nello stesso luogo per migliorare il lavoro di gruppo e favorire la comunicazione e la libera circolazione dell’informazione.
• Riconoscimenti: favorire i premi di tipo win-win (vince il gruppo) rispetto ai win-lose (vince uno e perdono gli altri). Devono essere chiari, espliciti e raggiungibili.

Mettendo in atto quanto sopra, si otterranno principalmente tre grossi vantaggi: miglioramento delle competenze dei singoli, aumento dell’efficacia complessiva del gruppo e sensibile diminuzione del turn-around tra i membri.

E secondo voi? Quanto è importante un team in un progetto?

Improve the team

Oggi, con questo intervento, voglio consolidare quanto detto in alcuni post passati, a proposito del team e degli approcci per incrementarne competenze e performance (Creatività e talento, Develop the team, management’s challanges).

Propongo idee, metodi e tecniche che vanno in quella direzione.

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.

Management’s challenges

Ehi tu manager, accetti la sfida?

Nel corso che ho tenuto qualche settimana fà è nato un interessante scambio di opinioni relativamente alla crescita dei collaboratori.
Quella discussione, affrontata quando abbiamo parlato del processo “Develop Project Team” del gruppo “Project Human Resource Management”, ci ha poi portato a traslare il concetto di crescita anche su noi stessi (crescita personale) e, ancora più in là sull’azienda.

Siamo partiti affermando quanto fosse importante permettere e agevolare la crescita dei membri del team, cosa possibile attraverso diversi mezzi che ho in parte già affrontato nel precedente post Develop the Team.

Essere in grado di fornire sfide e stimoli continui in azienda, è una delle chiavi che permettono alla stessa di tenere ben ancorate le persone che hanno vero talento. Queste infatti aspettano, pretendono e accettano la sfida.

Dall’altra parte aiuta anche l’azienda a “scremare” in maniera piuttosto naturale, perdendole, quelle che invece non sono in grado di tenere il passo.

Quindi, credo si possa affermare che la crescita continua dei collaboratori è possibile solo se questa passa attraverso una continua crescita personale (noi stessi) e/o dell’azienda.

Nel lungo termine, infatti, non sarò in grado di fornire stimoli durevoli di crescita, se io o l’azienda nella quale opero, non stabiliranno anch’essi questo trend evolutivo.

Questa affermazione investe qualsiasi manager, di una responsabilità importantissima.

Siamo infatti noi i primi a dover accettare la sfida come vera “filosofia di vita lavorativa”, mettendoci in gioco giornalmente e ampliando con persistenza e perseveranza i nostri orizzonti di conoscenza: imparare dall’esperienza (aspetto pratico) e studiando sui libri (aspetto teorico), coscienti del fatto che l’uno non può esistere senza l’altro.

Accettando la sfida lascio aperta la porta della novità, della non-conoscenza, del cambiamento, tutti aspetti onnipresenti in ogni progetto che per semplicità ci hanno insegnato a chiamare “change request“.

Questa caratteristica, ahimé, ci espone sempre al vento e ci vede sempre impegnati a scalare l’ennesima rampa di qualche learning curve…e questo è il lato “negativo”, che però con un pò di talento, passione e “allenamento” possiamo affrontare serenamente.

Non essendo tra la’ltro questa, una peculiarità comune a tutte le persone, ci pone in una condizione di netto vantaggio rispetto agli altri: che siano essi collaboratori, colleghi o competitor.

Questo ci permette infatti di fornire nuovi stimoli, confronti, “competizioni” su cui tutti, noi per primi, possiamo misurarci e crescere.

Cosa fare però, se dall’altra parte, azienda, collaboratori, colleghi o competitor non ci seguono lungo questa rampa?

Per i competitor è meglio, non ci raggiungeranno mai.

Per gli altri è innanzitutto necessario chiedersi se quanto stiamo chiedendo/proponendo in termini di impegno è  veramente troppo sfidante/impegantivo.
E qualora così non fosse?

La vita è un viaggio e durante il viaggio troveremo altri compagni disposti a fare un pezzo di strada insieme a noi.

L’importante è non trovarsi, ad un certo punto del viaggio, completamente da soli.

Develop the team

Tra le diverse attività di project management ne troviamo alcune molto interessanti nel campo delle risorse umane, legate allo sviluppo delle competenze del team. Un bravo project manager deve saper identificare le caratteristiche dei membri del team e procedere nel rinforzarle e svilupparle, sostenendo, motivando e guidando le singole persone.

In materia di risorse umane il PMBOK espone e indirizza diverse teorie che esplorano i meccanismi motivazionali degli essere umani.

Alcune sono piuttosto interessanti ciaiutano a capirne i fenomeni antropologici, sociali e comportamentali. Di seguito ne riporto solo alcune, quelle di maggior rilievo che hanno fatto la storia della materia:

• The hierarchy of needs – Maslow
• Theory of needs – McClelland
• Theory x and y – McGregor
• Expectancy theory – Vroom
• Factor theory - Herzberg

Senza volersi perdere in troppa “accademia”, ci sono alcuni accorgimenti che personalmente ho tratto sia dalla disciplina cosi come viene descritta dal PMBOK, sia dalla teoria agile che mi ha portato a cercare di definire cosa sia un project team efficace ed efficiente.

Partiamo prima con il definire cosa intendiamo per “project team efficace“:

• Dimostrare appartenenza e self-development
• Farsi promotori di azioni innovative e creative
• Comunicare in modo efficace
• Emersione dei problemi
• Essere propensi alla risoluzione dei conflitti
• Essere orientati ai risultati
• Essere aperti al cambiamento
• Essere propositivi e positivi

Se mi venisse chiesto di prioritizzare la lista sopra non ne sarei capace: tutti i punti sono equidistanti in termini di importanza.

Con la frase “project team efficiente” invece consideriamo quanto segue:

• Orientamento verso il valore atteso dal cliente
• Competenza individuale nel campo d’azione
• Dimensione ridotta del team
• Auto-disciplina del team
• Personalità orientata alla collaborazione
• Buone capacità di adattamento
• Disponibilità e apertura all’apprendimento

Tutto quanto sopra è possibile solo lavorando sull’ambiente e creando le condizioni ideali che facilitino il lavoro di gruppo, la semplicità nelle comunicazioni, senza però dimenticare di rilasciare continue motivazioni ai membri fornendo sfide e opportunità di crescita.

Opportunità di crescita personale che possono essere anche fornite attraverso i nostri feedback frequenti, sui comportamenti e le performance, siano essi positivi o negativi da trattare ovviamente con il corretto stile comunicativo.

Crescita professionale che deve essere stimolata attraverso momenti dedicati alla formazione, anche interna.

Una formula che funziona piuttosto bene è di incaricare della formazione direttamente alcuni membri più esperti: questo produce anche effetti positivi di team building e aumenta la coesione tra i membri.

Performance eccellenti possono essere sviluppate grazie e modalità aperte e efficienti di comunicazione (vedi post precedente), sviluppando la fiducia nel team, gestendo i conflitti in maniera costruttiva e incoraggiando alla collaborazione e verso un approccio di problem solving.

Quanto sopra esposto non sarebbe, a mio avviso, possibile prescindendo da un rapporto personale, quasi dedicato, con ognuno dei membri del team. Direi un’attenzione giornaliera dedicata e quasi personalizzata, fatta di incontri e analisi delle performance dei singoli.

Qualche tempo fa parlavo di questi temi, con un imprenditore nel campo dell’editoria a capo di numerose testate di quotidiani locali. Mi raccontava di quanto ritenesse importante il rapporto continuo e personalizzato con i propri dipendenti.

Paragonava l’attenzione ai suoi dipendenti, a quella che un buon giardiniere ha per il suo giardino. Lavoro paziente a cui dedicarsi giornalmente, regolandone le siepi (fornire regole, modalità e approcci lavorativi), annaffiandone e concimandone piante e fiori (fornire stimoli, motivazione e possibilità di crescita) , estirpandone le erbacce dal prato (gestire i conflitti).

Lavoro, questo, che se fatto giornalmente, o comunque con buona frequenza, permette ai conflitti di non proliferare e al project manger di poter monitorare costantemente lo stato d’animo delle singole persone, aiutandolo a  nutrire e mantenere sempre acceso l’interesse e la passione per il progetto.

Beh? Cosa aspettate allora?

Forza: guanti, pompa dell’acqua, cesoie, fertilizzante e…….via in giardino!

Laboratorio di Coaching

In questo post vi racconto della mia esperienza sul coaching dopo alcune letture, indagini e attraverso un workshop dedicato al tema.

Oggi ho avuto il piacere di partecipare ad un workshop sul coaching organizzato da The Change Partenership Italia a Milano.

La mia curiosità riguardo al coaching, è nata dopo aver preso visione di un corso multimediale del sole 24ore della collana management e leadership. Una delle lezioni riguardava appunto la costruzione della squadra vincente attraverso l’operato del manager coach.

Quella lezione mi incuriosì parecchio in quanto approfondiva temi per me interessantissimi: il talento proprio e dei collaboratori (vedi post pregresso), come facilitarne la scoperta, come infine il coaching potesse essere strumento concreto per lo sviluppo del team di progetto.

Qualche ricerca nei giorni seguenti mi fece scoprire che dietro al coaching c’è un mondo molto simile a quello del project management.

Esistono differenti organizzazioni internazionali che normano e promuovono la professione del coach.

Una delle più importanti è ICF (Internation Coach Federation) che prevede certificazioni del tutto simili a quelle del PMI, con pre-requisiti piuttosto stringenti per ottenerle: si parla di diverse ore di formazione, di testimonianze sulla tua professionalità da parte di coach esperti che ti hanno tenuto a battesimo, da numerose ore di professione esercitate presso un numero minimo di clienti.

Insomma qualcosa di piuttosto organico e strutturato che ovviamente è circoscritto da codici etici ferrei, se vogliamo ancor più stringenti di quelli imposti dal PMI. Questo è spiegato dal fatto che facendo coaching si viene a stretto contatto con la personalità dell’interessato e si possono toccare questioni delicate.

Ma certificazioni e burocrazia a parte, la cosa che più mi interessava era capire come le dinamiche del coaching permettessero l’esplorazione del mondo dell’altro e di come questa esplorazione potesse essere utilizzata per favorire l’ottenimento di obiettivi e risultati.

Bene, per fare il coach è necessario in primo luogo mettere un pò da parte se stessi: dedicarsi all’altro e ai suoi problemi, essere empatici e rivolgere la massima attenzione all’ascolto, considerare i punti deboli ma lavorare ancora più attivamente sui punti di forza.

Un continuo fornire stimoli allenanti e verificarne i risultati.

Come per l’atleta : acquisire la tecnica sportiva, allenarla, attendere che il proprio corpo ne faccia patrimonio attraverso la compensazione e, infine, valutarne il risultato in gara. Il coach per uno sportivo è quella persona che dovrebbe fornire indicazioni discrete,  indurre alla riflessione, lavorare su specifiche aree allenanti, fornire feedback, non giudizi, supportare insomma l’atleta nella sua sfida.

Lo scopo del manager coach non è quello di fornire soluzioni.

Lo scopo del manager coach è quello di portare il coachee (colui che si sta allenando), in piena autonomia, alla scoperta di una soluzione ai suoi problemi o alla definizione di un piano per il raggiungimento dei suoi obiettivi.

Questo viene fatto dal coach attraverso la formulazione di domande inerenti l’area di studio, utilizzando la propria intuizione o utilizzando, per esempio, tecniche specifiche di astrazione del coachee dal proprio ruolo, che favoriscano l’osservazione della situazione da differenti punti di vista. Non sono un esperto e non me ne vogliano i coach per questa banalizzazione, ma credo comunque che possa rendere l’idea.

Come già detto il coach deve stimolare il coachee e aspettare che arrivi da solo alla soluzione. Questo ha un valore immenso perché è il risultato di un processo cognitivo liberamente espresso dal singolo, non il frutto di un consiglio esterno, spesso tenuto in poco conto.

E tutto questo cosa centra con il project management?

Centra con le performance. Quando il team arranca, è in difficoltà, quando vi sono comportamenti non corretti che i singoli ciclicamente tornarno a ripetere, forse è il momento di agire. A poco serve uno stile autoritario o direttivo in questi casi.

Certo in caso si tratti semplicemente di problemi inerenti la scarsa conoscenza di tecniche o approcci al project management, allora la mera formazione può bastare.

Ma, al contrario, quando il problema è legato a difficoltà imputabili al singolo e che il singolo da solo non riesce a risolvere, allora prepariamo mantellino e tutina da coach e mettiamoci in gioco, non prima però di esserci sottoposti ad un adeguato percorso formativo.

Istruzioni per i naviganti. Il nostro cervello ragiona per schemi, strutture o processi consolidati: esso attiva delle azioni (processo) per ottenere un obiettivo. Quando lo trova, anche se doloroso, utilizzerà sempre quello per quella categoria di obiettivi, difficilmente si porrà in una condizione di ricerca di alternative. Siamo noi a doverlo fare e un coach è sicuramente di aiuto.

…come dite? Vi serve un coach? Beh, tornate tra qualche tempo chissà che non vi possa aiutare!

Sweet dreams!

Gestione multi-progetto

Le aziende medio piccole, come per esempio la maggior parte delle software house, si trovano spessissimo a dover gestire l’esecuzione di più progetti contemporaneamente.

Tali progetti, nella maggioranza dei casi, richiedono l’utilizzo di differenti tipologie di risorse: sviluppatore junior, sviluppatore senior, software architect o specialist, project manager.

Tali progetti, inoltre, possono avere differenti gradi di difficoltà, redditività e rischi:

• Categoria A: semplici repliche o revisioni di qualcosa di già sviluppato
• Categoria B: nuovi sviluppi su tecnologie comunque conosciute
• Categoria C: nuove realizzazioni su tecnologie inedite o sulle quali non esiste in azienda un know-how specifico

Per queste categorie potrebbe essere sintetizzata la seguente tabella.

Le risorse a più alta specializzazione o responsabilità (software architect o project manager) sono quelle a maggior costo e spesso anche quelle meno numerose o disponibili in azienda.

Si pone quindi la forte  necessità di gestire al meglio tali progetti cercando il miglior bilanciamento economico, di risorse e di governo del progetto stesso.

L’obiettivo è molto sfidante e, più di quanto si pensi, rappresenta per una piccola azienda la differenza tra floridità,  mera sopravvivenza o fallimento.
Vogliamo aggiungere a questa considerazione il famigerato peso dell’ “attuale momento congiungurale e di crisi in cui verte l’economia mondiale?”

Già, le vostre preoccupazioni sono anche le mie.

Non posso dire di aver elaborato una soluzione.
Parto però dalla semplice considerazione che senza un metodo, la situazione, già di suo piuttosto complessa, non è risolvibile.
Proviamo a scomporre il problema in aree per cercare di delineare un approccio.
Tali aree le possiamo considerare componenti primarie di un progetto:

• Cultura di project management aziendale e relativo grado di maturità
• Regolamentazione della modalità di lavoro
• Framework metodologico
• Rapporto con il cliente
• Gestione del team
• Gestione del portafoglio progetti

Per ognuna cerchiamo di evidenziarne i punti chiave e i possibili approcci.

Cultura di project management

Non è un lusso. Non è qualcosa di cui possiamo fare a meno.
Non è necessario per riempirsi la bocca di termini molto “professional”; è l’unico modo per crearsi un background che guidi il nostro percorso attraverso le complessità crescenti dei progetti.

Non è pensabile si possano gestire progetti, soprattutto in ambito ICT, senza un’adeguata cultura di project management, dove vincoli stretti e difficoltà in genere sono la quotidianità:  tempi ridotti, budget tagliati, carenza di risorse, complessità comunicative, in altre parole progetti ad alto rischio.

Ecco che quindi il project manger deve conoscere le basi, deve costruire una cultura di project management partecipata dal team, dal management, dal cliente.
Deve creare quel lessico, vocabolario comune fatto di metodi, tecniche, strumenti quanto più possibile condivisi.

Modalità di lavoro

L’esecuzione del lavoro deve essere regolata, incanalata, per certi versi industrializzata.
Un team di progetto, sebbene di una piccola azienda, non può permettersi un approccio artigianale.

O meglio tale approccio, sia chiaro ad altissimo valore aggiunto, può essere mantenuto per quelle attività in cui esiste una forte componente creativa o nelle aree in cui un approccio dedicato, dettagliato, quasi ritagliato sull’esigenza specifica, è un presupposto per la buona riuscita del progetto stesso.

Per tutto il resto devono essere definite regole, metodi, tempistiche, template e layout standard, procedure, persino le modalità di comunicazione con il cliente andrebbero decise a tavolino.

Project Framework

In campo di sviluppo software un framework è una struttura di supporto al lavoro, composto funzioni, metodi, codice, organizzato in librerie riusabili indistantemente dal tipo di applicazione in fase di sviluppo.
Questo concetto è alla base dello sviluppo software: creare codice riusabile, già testato, che garantisce maggiore velocità di realizzazione, costanza di risultati e scalabilità su differenti realtà.

Perchè quindi non creare un nostro project framework? Un componente che racchiuda il nostro approccio ai progetti?

Tutto ciò descritto nel paragrafo precedente potrebbe essere in qualche modo reso astratto, generalizzato e organizzato in linee guida, template, layout, procedure, regolamentazioni, flussi di lavoro.

Che immenso vantaggio ne trarremmo?
Ogni componente del team è finalmente  in grado di lavorare per buona parte in completa autonomia e dedicarsi maggiormente alla questioni a più alto valore aggiunto.
Si passa quindi dal governare il quotidiano a governare le sole eccezioni (Exception management wikipedia).
Sarà anche molto più semplice inserire nuove risorse o spostare le risorse su differenti progetti (crashing, fast tracking) in caso di necessità.

Rapporto con il cliente

A prima vista potrebbe sembare il problema con minore peso specifico.

Quando si parla di conduzione e esecuzione di un progetto, di fatto realizziamo una nuova necessità del cliente, qualcosa che non esite, qualcosa che ha solo immaginato.
Qualcosa alla quale tiene particolarmente e sulla quale sta investendo tempo e denaro, semplicemente fidandosi di una promessa fatta, sulla base di alcuni capitoli scritti in un project plan.
Questo ci investe di una grossa responsabilità; personalmente faccio fatica a caricarmi sulle spalle tali pesi in mancanza di una piena fiducia.

Il cliente deve fidarsi di noi. E noi dobbiamo imparare a conquistarla.

Quando il cliente si fida di noi, diventa un alleato, non un nemico dal quale difenderci stando in trincea; evitaremo di spendere energie per giustificare, spiegare, puntualizzare.
Cominceremo a spostare il rapporto su piani diversi: sinergia e collaborazione.

Gestione del team

Come già accennato sopra, il team deve condividere pienamente modalità, regole e flusso lavorativo.
Deve riconoscere nel project mangaer un leader: una persona capace di fissare mete e obiettivi condivisi, capace di stimolare il lavoro, di motivare continuamente il gruppo e all’occorrenza di personalizzare il proprio stile alla situazione e alle singole persone.

Il successo di un progetto è vincolato alla regola: le persone giuste al posto giusto.
Qualcosa di cui ho già accennato in un precedente post.

Gestione del portafoglio progetti

La definizione ufficiale di portafoglio di progetti è la seguente.

Collezione di progetti raggruppati per facilitarne la gestione al fine di raggiungere l’obiettivo strategico di ognuno e indirettamente massimizzare quello aziendale. Tali progetti accorpati non necessariamente sono tra loro correlati e i risultati dell’uno potrebbero non influenzare quello degli altri.

In altre parole la loro gestione potrebbe correre su linee parallele.

Gestire progetti tra loro disgiunti presenta sicuramente una maggiore complessità, però ha il suo lato positivo.
Questo si chiama bilanciamento.
Potremo bilanciare le risorse tra progetti, rallentando o velocizzando lo sviluppo dell’uno o dell’altro a seconda delle necessità e dei vincoli di ognuno.
Di fatto stiamo diversificando e bilanciando la nostra redditività.
Di conseguenza bilanceremo anche i rischi.

La gestione multi-progetto non è un’attività semplice.
La creazione di un processo strutturato, in continua evoluzione, rifinitura e controllo, rappresenta forse l’unico vero strumento per far fronte a complessità e rischi collegati.