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

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“

Acting as a zipper: here is the Product Owner.

The product owner (PO) in SCRUM, is one of the most crucial figure of the stakeholders community formed around a SCRUM project.

His role is to behave as an interface primarily between the team and the management, adapting the behaviour, the ledership style, the way he communicates time at a time, in relation to which he is confronting with.
He should master the communication and negotiation techniques, he should also know how to manage politics and take advantage from it.

On the other side, the Scrum Master is mainly a coach, a mentor, somehow it could be tought as a wise father in charge to give the team support and guidance. He must have strong communication skill as well and he should be an active listener and  a servant leader, protecting the team and creating a favorable workplace.

The PO is even more important when the client organization is not part of the one that is creating the product and, moreover, if it is not familiar with the agile practices and concepts.

It happens in these cases that the client organization is also particulary fond of the traditional way of conducting and controlling projects and it doesn’t want to change the way it works.
The PO, hence, must actively keep the client informed by sending at a regular basis, fresh information about project’s progress, using the same “project language” of the customer: gantt, Earned Value analysis, etc.

It is obviously auspicable, looking from the agile perspective, that the client participates at least to the Demo/Reiew meeting that the team holds every end-iteration, showing the actual progress in term of what was developed so far and that is ready to go live.

SCRUM and XP as well, indeed, prescribe the practice of “customer-on-site” that means the client is strongly involved in and engaged with the team, in the same workplace, during the entire lifecycle of the project. This could be challenging, but it brings lot of advantages that are mostly related with the fact of establishing short lines of communication that drives to short feedback between the team and the customer, avoiding misunderstandings and shortening the time necessary for decision making.

One last advantage is that the customer itself is able to see how the project is progressing, looking at the Task Board, the sprint and release Burndown Chart, the Impediment Log.

But, as we assumed initially for the sake of this example, our customer doesn’t want to be so much involved and engaged, he is not interested in any agile practices or knowledge, he only wants the product he asked for within the time, cost and quality decided and, finally, he wants to receive punctual updates about project’s progress

In short,a real nightmare for a pure agilist :\
Someone said me that in these case s/he refuses the job.

My opinion is that even in these cases, we should be adaptive and responsive to the situation, by adapting our style to the customer’s one, using the Product Owner (internal in this case) as a zipper, a tradeoff figure, an active interface between the traditional project management style of the customer and the agile approach of the internal team.

Let’s assume we choose the second case.
First of all, I suggest to the PO to try continuosly to engage as much as possibile the customer.

The first duty that the PO must assolve, is to gather the requirements and write the user stories. During the meetings he will held with the customer for that, he should find the way to give some “agile” pills to the patient: talking about the ceremonies (planning, daily, demo and retrospective meetings), the artifacts (product, release and sprint backlog, burndown charts, impediment backlog), the roles and, why not, the rules of SCRUM.

Another important thing the PO should do during the gathering requirements meetings, is to collect all the functionalities the customer wants, initially without a great extent of detail and to ask the customer to prioritize them, understanding the real business value the customer assignes (see this previous post).

The most important requirements, those with an high prority, must be “decomposed” into user stories, the other less important requirements will be put into the product backlog as they are, without exploring them too much in this first moment.
This because those requirement will be analyzed only after the first versions of the product are available, giving the customer the opportunity to change his mind, introducing something else or, even, cancelling such requirements because he already achieved the ROI.

Then, the PO, should try to bring the customer at the “war room“, the place where the team is working, to let him to be part of the “flow” even if for few moments.

In this occasion the Scrum Master must be present as well, behaving as a Cicerone explaining how and why the workplace is arranged that way, how the data reported on the information radiators can be interpreted, how the team works and why such a high level of involvement is so important.

Another important step of persuasion the PO should try, is to insist to have a customer representation present during the demo meeting, inviting him or asking to delegate someone else, to participate the demo/review meeting, to see how the product is evolving.

In these situations, indeed, I prefer to set short iteration lenght, because the fact that the client is not so involved and passionate, increases the risks and the probability of misunderstanding. Having the possibility to release frequently, on production, small chunks of working software, helps to prevent it.

The PO, then, must interact proactively with the team acting as the customer, giving opinions, guidance and solving problems about what and how the product should be and work.

And finally, the last great effort the PO has to do, is to keep informed the customer at a regular basis with the progress status of the product, by transforming the information spread around the several information radiators, into the documents the customer really wants: the WBS, the Gantt Chart, the Earned Value Analysis.

Creating the WBS is somehow simple because it is mainly a hierarchical structure of the work that must be done, dividing it into nodes, sub-nodes and leaves that must be arranged by deliverables. The term deliverable means a piece of finished functioning work, that can be released to the customer in order to be evaluated and eventually put on production. This, for an agilist, sounds good because the equation could be deliverable = iteration or in the worst case deliverable = release.

The WBS hence could be arranged by reporting the releases, the iterations for each release and finally which stories the team is going to implement for each iteration.

Actually, this is only the first step the PO should do to keep aligned a recalcitrant customer with the progress of an agile project, by creating traditional project management documentation. The other steps are create a Gantt chart from a SCRUM Task Board and produce a status and forecast report about the perfomance of the project, by relating the burndown chart data, the velocity, the iterations planned into a fantastic Earned Value Analysis.

I’ll try to cover also these two last point (the tough ones actually) in some future posts. Keep in touch!

Next Agile Course Dates

Hi everybody!

This post to inform about my next two agile courses organized by the European School of Project Management, for the next October (see below the details).

Title: Let’s SCRUM
Duration: 2 days (2011 October, 6th and 7th)
Place: Collegno (TO)
URL: http://www.espm.eu/index.php/it/corsi/catalogo-corsi/metodi/details/88-corso-scrum

Title: Agile Project Management
Duration: 1 day  (2011 October, 10th)
Place: Milan
URL: http://www.espm.eu/index.php/it/corsi/catalogo-corsi/metodi/details/87-agile-project-management

Agile Coach Camp Outcomes

The past week-end I attended the Agile Coach Camp un-conference, that took place in Umbria in a lovely venue called La Casella.

The main objective of that un-conference was to aggregate people interested in agile project management and coaching practices. As described in the event home-page:

Two days of highly collaborative, (mostly) self-organized event with Agile coach dojo and OpenSpace for everyone involved in coaching,training, mentoring and leading Agile Organizations, Teams and Individuals.
ScrumMasters, team leads, guerilla Change Agents, ProductOwners, managers, other roles are all welcome. Diversity makes us smarter!

What a fantastic experience it has been!

I’ve known special people: people whose only objective was to collaborate and share ideas, knowledge, experience and thoughts.

People who know that in these cases the real result of the sum of two ideas is more than the algebrical result.

People that consider more important the growth of the community that its.

Passionate people who love what is doing and ready to share its passion with you.

Did I already said that it has been a great experience?

Personal Alignment (2nd): “SCRUM” your life!

 How to realign yourself? Read below…

  The first step to start the process of personal realignment was done here.

How many times you took decisions that you felt far away from yourself?
And there were been situations that forced you to behave in a way that kept unsatisfied, feeling a sort of internal dissonance?
Do you remember the SWOT we did in the first post? Are you currently using your strengths in your work? Or again, does your boss point out only your weaknesses asking you to fill the gap?

When such a feeling is not an occasional and sporadic one, but pervades our working lives, is the time to take a break and think about what we are actually doing and what we would really like to do.

We should think about the environment, the physical environment, in which we work.
Think about the feeling we have about that environment and whether it is energizing or demeaning.
Do we love that environment? does it suit us?
What can be changed? Can we directly managing that process of change?

We should think about our job: does it fit us? are we really satisfied with it?
If yes, are you really sure you want to realign yourself? It seems there are no motivations to do that!
If there is something bad, however, what really hurt you?

Again, we should think about our behavior: is it such a professional one? Is there something that can be improved? Keep focused on the weaknesses of your behavior: are they so burdensome? If yes, which actions can be done to improve them?
Now, try to imagine yourself at work  in five years: are you doing the same work that you are doing now? Are you happy with that? Is the job you wish?
If yes, again, no actions are required, you are one of the luckiest men or women in the world!

Otherwise, there’s something to change and you should realign yourself towards your wishes and passions.

And here it is what can be done: SCRUM your life!
Yes, do you remember SCRUM? The effective pm framework that uses ceremonies, artifacts, roles and rules to gather what the customer really wants!
You are lucky, today the customer is you…and we are going to APPLY part of it to your life.
First of all, you as the product owner of your life, must formulate your own objectives.
Start thinking about  the opportunities you pointed out in your SWOT and the objectives necessary to change your life from the current one to the one you have just imagined!
Your objective must be: Specific, Measurable, Attainable, Relevant and Timely, in one word SMART.
Enumerate your objectives and prioritize them: from the most important to the less one (we call it the objectives backlog).
Consider to use Excel, it will help to keep them arranged and easily reordered by priority.

Now is time to think how to reach those objectives: the activities and actions you must address, execute and realize. Again, write them down and start prioritizing again (we call it activities backlog)

A little suggestion when prioritizing, remember what Pareto said in his law:

the 80% of the results can be achieved with the 20% of activities

Think about each activity: is that directly connected to one of the objectives? And the objective to which is related iso ne of the most important?

If yes, assign to it a high priority.
Great, now you have your prioritized lists of objectives and activities.

The next step is to decide the sprint length.

The sprint is a time that normally lasts from 2 weeks to 6 weeks, during which you will commit in order to put in practice the actions and the activities you identify.
One of the most important rules of the sprint is that at the end of the expected time, you must “deliver” something effective into the real life.
Something that gives you a tangible results, something that can be intended as a ROI (return on investments) of your project.

Remember, your activities duration in order to be started and finished within a sprint, must obviously be smaller than the sprint duration itself.
An action like ‘Learn to drive a F1 car’ probably cannot be achieved neither in 2 weeks nor 6 weeks. Start attending to a go-kart driver training course and get the driver license, instead, can be a first effective and achievable target.

Now it’s time to estimate your activities, starting with those with high priorities. You must assign to each one a duration in days, in order to start, execute and finalize it.

Ok, we are almost near the end of the planning phase.
Now it’s time to finally choose the sprint duration and select the activities, starting from the top of your list, that can be included into that sprint.

When finished, you have just created your first “Sprint backlog”, the list of activities you will execute during the sprint.
Now it’s time to focus on the activities contained into the sprint backlog and for each one think how you will perform in terms of actual things to do, tools and information needed, etc.
You should have a brief (very brief remember the agility) plan to follow about it, at least in your mind.

Finally, it is up to you: it’s time to sprint!

Agile PMI Certification: News

Qualche news dopo la visione del webcast della presentazione del lancio della nuova certificazione e di qualche ricerca su internet.

Oggi ho assistito al Webcast di presentazione della nuova certificazione agile del PMI, che si era tenuto il 17/3 e al quale non avevo potuto paretecipare.

Sembrerebbe che il PMI stesse seguendo con interesse l’evoluzione delle discipline agili, da almeno due anni (marzo 2009) e che nel marzo 2010 abbia deciso di lavorare alla nuova certificazione professionale.

Durante la presentazione, sono state riassunte le informazioni base di cui ho già scritto in questi post (Il PMI e la nuova certificazione “agile” e Agile PM Certification Suggested Books). 

Nella presentazione sono citate le seguenti metodologie come appartenenti alle discipline agili: scrum , xp , kanban , fdd e dsdm.

L’interesse del PMI per la tematica, è risultato evidente soprattutto nel modo in cui è stato rimarcato il messaggio che il PMBOK non debba essere pensato come alla “vecchia metodologia” di conduzione dei progetti.

Esso, invece, rappresenterebbe la cassetta degli attrezzi a dispodizione del project manager:  il “cosa fare“; mentre le discipline agili il “come farlo“. Strumento (PMBOK) e processo di implementazione (Agile).

Papers

Curiosando qua e là nella rete, alla ricerca di qualche papers tra quelli segnalati, ho trovato qualcosa di interessante soprattutto su un paio di autori: Michelle Sliger e Mike Griffiths.

Ecco il risultato delle miei ricerche:

• Agile Project Management and the PMBOK® Guide by Michelle Sliger
  • 1^ Puntata http://tinyurl.com/ekb4p
  • 2^ Puntata http://tinyurl.com/k4n4n
  • 3^ Puntata http://tinyurl.com/f9uop
  • 4^ Puntata http://tinyurl.com/vvnjc
  • Presentazione http://140.99.29.241/images/uploads/PMBOKtoAgileMapping.pdf
• Selling Agile: How to get buy-in from your team, customers and managers by Michelle Sliger
  • http://140.99.29.241/images/uploads/WhitePaper_SellingAgile.pdf
• Development Projects by Mike Griffiths
  • http://leadinganswers.typepad.com/leading_answers/files/developments_in_agile_project_management_mike_griffiths.pdf

Ah, dimenticavo. Per chi volesse seguire il tema su Twitter ecco il tag di riferimento: #pmiagilecert.

Stay tuned!

SCRUM? Proviamo per 30 giorni a tornare bambini!

Come imparano i bambini? E se Scrum vi offrisse di tornare bambini per trenta giorni? Accettereste di provarlo?

Innanzittutto non conoscono pregiudizio. Nessuna sovrastruttura mentale che li condizioni nella loro esplorazione: solo tanta voglia di capire cosa gli stia intorno.

Poi fanno largo uso di una tecnica efficacissima: sperimentano il mondo e la sua complessità, semplicemente attraverso l’uso dei propri diretti sensori: i cinque sensi.

Ed eccoli lì a toccare tutto, prese della corrente comprese, con mani e piedi. Li troverete sempre con in bocca qualcosa (la peggiore), intenti ad assaporarne il gusto, oppure a fissare sbalorditi la coda del vostro gatto che incessantemente si muove ritmicamente al suono del pendolo appeso alla parete.

Questo tipo di esplorazione ha l’enorme pregio di giovarsi di un ciclo di feedback estremamente corto. Tra la sperimentazione e il risultato, tra l’ispezione e l’eventuale adattamento, passano pochi attimi.

Subito saranno in grado di comprendere se la sperimentazione fatta, possa e debba essere ripetuta. In caso affermativo, al prossimo giro, saranno in grado di applicarvi un adattamento capace di far evolvere il loro modo di ”essere” in rapporto a quella esperienza.

Fantastico, chi di voi ha figli, riscopre giornalmente quella magia

Bene. Cosa centra tutto questo con Scrum?

Scrum si basa su un approccio alla gestione dei progetti, di tipo empirico  basato su tre pilastri fondmentali: trasparenza, ispezione e adattamento.

La trasparenza. Nei rapporti, nei comportamenti, nel mostrare il lavoro fatto e nello scegliere e ‘accettare quello ancora da fare, nel reperire e interpretare le informazioni; insomma, nel permettere alla realtà di emergere, per come è “realmente”.

L’ispezione. In quel contesto di trasparenza, l’ispezione è il miglior modo per esplorare la complessità del mondo e capire se il tipo di approccio da noi utilizzato è quello corretto.

L’adattamento. Risultato “automatico”, obbligato, quasi imposto e forzato dalla stessa esperienza dell’ispezione. Ci permetterà, senza ombra di dubbio alcuno, di scartare ciò che non ha funzionato e reiterare e migliorare nella sua applicazione, ciò che ha funzionato.

E finalmente arriva quello che considero il vero collante di Scrum, nonché il suo valore più alto: il corto ciclo di feedback “impostoci” dalla sua organizzazione “time-boxed” del tempo.

Lo sprint: massimo trenta giorni di lavoro per fornire risultati veri, tangibili, verificabili da tutti! Membri del team, ScrumMaster, ProductOwner, management, committenti.

I daily scrum meeting: quindici minuti per raccontare cosa ho fatto ieri, cosa farò oggi e quali sono gli impedimenti che ho trovato. Quindi minuti appunto, non uno di più, per raccontare agli altri la tua esperienza e ascoltare e percepire quella degli altri. Farla tua.

Hai poco tempo, lo devi sfruttare al meglio per fornire agli altri le informazioni più importanti, condividerne l’esperienza: non più ego-centrici ma team-centrici.

Il planning meeeting. Una giornata di analisi, non di più. Il team deve scegliere dal product backlog, cosa implementare nel prossimo sprint e decidere come farlo. Non c’è tempo per i dettagli, per stime accurate, ti devi fidare di te, della tua esperienza, del gruppo.

Il review meeting. Mezza giornata in cui il team mostra cosa ha fatto, in piena trasparenza. Funzionalità realizzate e non, cosa ha funzionato e cosa no. Anche qui la realtà deve emergere, gli stakeholders coinvolti devono capire quale è la realtà dei fatti (sia in positivo sia in in negativo) perché anche per loro si metterà in moto il processo di adattamento. In base ai risultati raggiunti, alla velocità e alle performance dimostrate, alla visione “dal vivo” e “in anteprima” delle funzionalità, modelleranno nuove aspettative che si concretizzeranno per voi, in una revisione tangibile del product backlog.

Il retrospective meeting. Momento fondamentale di revisione del lavoro svolto: cosa ha funzionato? cosa invece no? cosa potrebbe essere migliorato? I giapponesi chiamano questo processo con una sola parola “Kaizen“. Noi lo chiamiamo miglioramento continuo.

Ken Schwaber, in uno dei suoi libri, ci racconta che in progetti SW complessi, permettere alla trasparenza di emergere, è piuttosto difficile. Pensate infatti ad un team di sette persone, in cui quattro sviluppano, due effettuano test e l’ultima scrive la documentazione. E’ impensabile permettere ad ognuno di loro di conoscere cosa stia facendo il collega affianco; e anche il daily scrum non permetterebbe loro di fare piena esperienza, delle esperienze degli altri.

E’ per questo che in quei casi ci può venire in aiuto la metodologia XP Programming e alcune sue specifiche tecniche, che permettono l’emersione della realtà in maniera automatica, costante e giornaliera. Quali sono queste tecniche?

• Integrazione continua del codice e build giornaliere: faranno emergere subito eventuali problemi e, quando invece le cose vanno bene, permetteranno ad altri membri del team di usufruire immediatamente del lavoro fatto dai colleghi.
• Test-driven development: scrittura dei test anticipatamente allo sviluppo del codice. Permette di verificare al termine della codifica di una routine, se quanto scritto è corretto.
• Pair programming: lavoro congiunto sullo stesso codice, da parte di due sviluppatori. Quattro mani, quattro occhi, due cervelli.
• Collective code ownership: ogni membro del team accede ed è responsabile di tutto il codice. Lo usa, modifica, visiona in piena libertà.

Allora? Torniamo bimbi per trenta giorni?

Beh, ora vi lascio… anche se mi è venuto in mente giusto ora, un parallelismo tra Scrum e Zen.

Si, ok, ho capito. Per stasera ve lo risparmio!

Agile PM Certification Suggested Books

Ecco i primi libri e papers suggeriti dal PMI per chi guarda alla certificazione Agile PM (vedi anche post precedenti: post1 e post2).

Papers (acquistabili per circa 15 dollari dal marketplace di PMI.org):

• Agile Project Management and the PMBOK® Guide by Michelle Sliger
• Agile PMP®: Managing software projects in the face of uncertainty by Mike Cottmeyer
• Challenges in Implementing Agile Project Management by Jesse Fewell
• Looking for an Edge by Jesse Fewell
• Selling Agile: How to get buy-in from your team, customers and managers by Michelle Sliger
• Utilizing Agile Principles Alongside the PMBOK® Guide for Better Project Execution and Control in Software
• Development Projects by Mike Griffiths

Libri:

• Agile Project Management by Jim Highsmith
• Effective Project Management: Traditional, Agile, Extreme by Robert K. Wysocki
• Project Management the Agile Way by John C. Goodpasture, PMP
• The Software Project Manager’s Bridge to Agility by Michele Sliger and Stacia Broderick
• Running an Agile Software Development Project by Mike Holcombe
• Managing Agile Projects, First Edition by Kevin Aguanno, editor
• Agile Project Management: How to succeed in the face of changing project requirements by Gary Chin
• Agile Project Management with Scrum by Ken Schwaber

La lista sopra non è ancora quella ufficiale di riferimento per lo studio, ma essendo comunque fornita dal PMI credo non sarà molto diversa.

Io sono partito acquistando l’eBook dell’ultimo libro dell’elenco sopra (Agile Project Management with Scrum di Schwaber), perché consigliato anche da Simon Bennet, il trainer del corso Scrum a cui ho partecipato.

Buon libro. Approfondisce le tematiche Scrum con molti esempi sul campo e, cosa ancor più a valore aggiunto, cerca di tracciare legami tra le modalità di conduzione e rappresentazione di progetti standard con progetti agili (in questo caso Scrum appunto).

Per chi infine fosse interessato a seguire su Twitter la tematica, ecco il tag di riferimento: #PMIAgileCert

Nice morning!