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“

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.

Prioritizing User Stories

One of the most important survey results conducted by an important international organization, states that 64% of the functionalities included in software products are never or almost never used!
How come?!?
One way to avoid such a waste of resources, is to assign priorities to the user stories and to develop them starting from the highest.

 This post wants to address that 64% of features to be developed, which are never used by the final users once the product is deployed on production. After all, avoiding those features isn’t a way to reduce costs and time necessary to go live?

Let’s see how SCRUM faces to this issue.
As you probably know, the SCRUM framework provides three different roles: the team, the scrum master (SM) and the product owner (PO) (see URL). All of them are important. Maybe the team can be considered the most important, but for sure, SCRUM cannot work if any of those is missing.

This post is dedicated to the important role of the Product Owner and to one of its duties: prioritizing the features!

Once the gathering requirements phase is finished, the product owner should have in her hands a list of index/note cards in which are written the user stories.

The process of prioritization, must be conducted in order to:

1. Maximize and accelerate the ROI
2. Reduce risks

In order to maximize te ROI, the PO must have a clear understanding of what the customer wants in terms of: objectives, necessities, opportunities to reach, in one word, she must understand what is the actual Customer Business Value to gather.

Reducing risks, on the other hand, is primarily a matter of:

• Remove any impediments
• Give answers and explanations to any doubts or open points
• Deepen, if necessary, user stories that are not clear
• Execute as soon as possible any critical project activities

We can consider critical, an activity that will use a new technology not yet known to the team.
Or, furthermore, an activity that is one of the most important of the entire product, over which there are lot of expectations from the project stakeholders.

For the first case mentioned (new technology) is important to work on that feature as soon as possibile in order to “understand” the new technology and how to work with it. This will allow the team to capitalize the knowledge just acquired and will lower the risks.

Facing the second case (hot feature), it is again a matter of work quickly on it and to fast deliver it in order to receive, even here as soon as possible, feedback from the stakeholders.

Thus, it’s only a matter of assigning the right priorities, isnt’ it?! Yes but, how?

Actually, there are many methods available to achieve that goal, but the one I want to explore today, is the one that takes care of the customer business value and the risks associated to each feature, assigning to them an index (from 1 to 10 for example) in order to draw a point in a x/y graph.

This method is also mentioned in one of Mike Cohn’s books (Agile Estimating and Planning) that I strongly suggest to read.

So, let’s use Excel.

Create a new worksheet containing three columns: User story ID (or title), Business Value Index, Risk Index.

List all the user stories and for each one first assign a business value index: 1 for the lowest and 10 for the highest.
Higher values should be assigned to each activity that directly aims to one or more of the objectives to be achieved.
Lower values should be assigned to the activities not so important in achieving the goals like ancillary activites, maintenance or administrative activities, reports, etc.

Once a business value index is assigned for each feature, is time to provide risk indexes.
Higher values should be assigned to critical features like those that uses new technologies, those not well described or well understood, those that have  many interactions with external systems, those that will serve different typology of users and so on.
Lower values should be assigned to the remaining acitivities.

Now it’s time to create a graph, having excel plotting the points.

Now, compare the graph you obtained with the reference matrix above reported.

Well, it is time to start working and remember: the features never or almost never used, are the ones having a lower business value assigned; so, do them at the end and, furthermore, try to avoid those with an high risk associated!

Risks?!? TimeBox them!

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

The meetings for example:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Stay tuned!

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!

Scrum Master Certified!

Evvai!

A due anni dalla certificazione PMP, è arrivata la certificazione CSM.

Certified ScrumMaster Training: Done!

Sono sopravvissuto

Ieri è terminato il training inerente alla certificazione ScrumMaster.

E’ stato tanto complesso e faticoso quanto interessante e coinvolgente.

Innanzitutto l’intensità e la durata del corso: diciotto ore in totale nelle due giornate. Pause, diciamo così, ridotte al minimo per evitare dispersioni e cadute di concentrazione; in aula sempre disponibili caramelle, snack vari e ampia disponibilità di caffé e bevande, evitando di doversi allontanare per cercare “ristoro”.

La lingua: data la sede (Scozia) interamente in inglese. Ero l’unico non madre-lingua o che comunque non usava l’inglese giornalmente. Questo ha ovviamente giocato a mio svantaggio ed è stato di fatto un impedimento (termine caro a uno ScrumMaster).

Cervello in perenne stato di saturazione nel tentativo di gestire l’ingente mole di dati in input, i processi di traduzione, decodifica e di interpretazione e per finire con la memorizzazione di quanto appreso ed elaborato.
In certi momenti devo aver fatto un pò la figura del tonto, in quanto la mia reattività non era certo da guinness dei primati!

Golden Formula of Retrospective

E’ stato però estremamente avvincente confrontarsi con persone così differenti in termini culturali, ma ancora di più ritrovare sé stesso in quel contesto, così diverso da quello usuale ed essere obbligati a cavarsela.

Lo svolgimento: SCRUM è una modalità agile, concreta e coinvolgente di condurre progetti.
Simon (il trainer) ha gestito il corso allo stesso modo. Le giornate pensate come fossero degli sprint, in cui gli argomenti da trattare erano riportati nella SCRUM Tasks Board e, all’inizio delle quali, abbiamo condotto gli SCRUM daily meeting (rigorosamente in piedi e entro i famosi quindici minuti) e a fine corso una specie di review meting per verificare quanto appreso.

SCRUM Task Board

E infine, cosa dal mio punta di vista a maggior valore aggiunto dell’intero corso, una serie di esercizi pratici in cui noi (il team) eravamo direttamente e “fisicamente” coinvolti nello svolgimento. Esempi dai quali ho tratto i più importanti spunti e insegnamenti.

La sfida: cosa c’è di più sfidante nel sostenere ritmi molto serrati, comunicando in una lingua diversa dalla tua, trovandoti coinvolto in team con persone che non conosci?
Infine, per dare ancora più senso alla sfida, uno stravolgente cambio di mentalità nel gestire i progetti! Questa di certo è la sfida nella sfida!

Wall of Wisdom

La creatività: SCRUM è un framework che indica regole piuttosto chiare a cui attenersi per gestire progetti in modo agile. Sebbene possa sembrare un contesto piuttosto rigido in cui muoversi, il team al fine di meglio collaborare, crescere e auto organizzarsi, deve essere molto aperto ai cambiamenti, agli adattamenti, essere molto curioso e coraggioso nello sperimentare: in una parola parola deve fare largo uso della creatività. Così anche noi durante il corso siamo stati chiamati a disegnare, trovare soluzioni innovative, avere a che fare con post-it di vario colore e forma per tracciare e gestire i task, valutare, trovare accordi.

Free your Creativity with SCRUM

 Una nota a margine.

Ero uno dei partecipanti più “anziani”: sono io che mi sono mosso in ritardo, oppure in generale, in Italia siamo parecchio indietro rispetto a questi argomenti?

L’aereo mi aspetta, ho diverse ore per pensarci! Be good

SCRUM & Large Projects

Come conciliare SCRUM e grossi progetti?

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.