28 minute read
PROGETTAZIONE/PROJECT MANAGEMENT AGILE E SCRUM. LE PROSPETTIVE DELLA PROGETTA ZIONE MODERNA/ AGILE AND SCRUM, THE PER SPECTIVES OF MODERN DESIGN di Alessandro Cappellozza
AGILE E SCRUM. LE PROSPETTIVE DELLA PROGETTAZIONE MODERNA
Negli ultimi anni le imprese hanno dovute fare i conti con richieste di produzione snella, mercati turbolenti e aggressivi, rapide innovazioni tecnologiche, nuovi modelli di governance. Tutto ciò ha determinato profondi cambiamenti nel dominio della progettazione, per la quale approcci e metodi tradizionali sono spesso inadeguati. Per aiutare le aziende e i progettisti a gestire progetti sempre più complessi sono state introdotte tecniche evolute di Project Management: Agile e Scrum. Cerchiamo di capirne di più in questo articolo.
Advertisement
Immagino vi siate trovati, o abbiate sentito parlare, di progetti che non finiscono mai o che disattendono le aspettative del cliente. In un mondo così dinamico e contemporaneamente anche così distratto, è facile caricare di aspettative un requisito o addirittura tutto il progetto, specialmente in campo informatico: il movimento agile cerca di rovesciare questo trend. Dall’ultima rivoluzione industriale ci si è cullati nell’illusione che pianificando a step il lavoro nel suo insieme e avendo un set di specifiche preciso, si possa stilare un bel diagramma di Gantt e rispettarlo: sapete bene che nell’informatica, ormai padrona di ogni aspetto, in un mondo in evoluzione vorticosa, il classico metodo a cascata semplicemente non funziona; tempi troppo lunghi, ora che si finisce il prodotto o una fase, è già vecchio o il cliente ha cambiato le specifiche. Ancora peggio l’informatica è piuttosto impalpabile e molto soggettiva, le aspettative di ognuno variano molto e spesso anche una buona specifica non basta.
Agile non è un metodo, è un insieme di principi. Agli inizi degli anni 2000 un gruppo di esperti ha delineato un insieme di quattro principi cardine e dodici enunciati da seguire, non solo per dare maggiore valore al proprio lavoro, ma per (finalmente) riuscire a abbattere il rischio e fare contento sia te che il cliente. Come si può immaginare non si tratta di una formula magica ma di un radicale cambio di prospettiva per tutti. Comincerei con lo spiegare perché non si parla di metodo: dobbiamo pensare all’Agile come un’impalcatura intellettuale all’interno della quale si svolge il lavoro, non vi dice come farlo ma che ritmo e che spirito dargli; all’interno di questa impalcatura (framework) potete usare il metodo che più vi aggrada. È come immaginare il lavoro come un fiume, il framework sono gli argini e l’acqua il tuo lavoro.
La gestione dei progetti con Scrum
Il contesto in cui si inseriscono poi è molto netto; nascono in campo informatico, perché più che in altri contesti qui è presente l’incertezza; Scrum (la versione di gran lunga più diffusa del framework Agile) funziona in sistemi empirici cioè dove si sa quanto ci si mette a fare le cose solo dopo che le hai fatte. Generalmente si tende a suddividere i processi in tre famiglie, quelli deterministici in cui si sa quanto ci si metta a fare un certo lavoro. Quelli statistici in cui ci si misura con un certo grado di incertezza ma è possibile calcolarlo. Infine abbiamo quelli empirici che sono propri dei processi creativi in cui è complesso determinare un tempo per svolgere un compito mai fatto prima, ed è qui che ha il suo massimo di utilità.
Per spiegare come funziona, si usa spesso un esempio di un team al quale è chiesto da un committente, un mezzo per recarsi al lavoro. Un sistema classico penserebbe subito ad un mezzo che è già stato usato in passato, in questo caso potrebbe essere una macchina. Si comincerà quindi a progettare motore, telaio, carrozzeria e interni. Il cliente sarà coinvolto solamente nei mockup e in fasi intermedie, si pianificherà con un bel diagramma di Gantt e ci si ritroverà alla
fine con un veicolo. Alla fine di questo processo ho la stessa possibilità sia che vada bene sia che non vada bene al cliente, l’incertezza è enorme e questo perché il cliente non ha mai visto il prodotto completo prima. A chi non è mai successo di sentire la frase del cliente “ma io pensavo”? Ci troviamo in un campo in cui il rischio è elevato, la macchina può far contento il cliente ma magari ben oltre le sue esigenze rendendo il progetto inutilmente costoso.
Il metodo iterativo invece si basa su un principio diverso, si fa leva su un principio conosciuto in ambiente Lean Manufacturing detto MVP, ovvero Prodotto Minimo Funzionante; è il minimo che si può fare per poter soddisfare l’esigenza del cliente. In questo specifico caso potremmo pensare che il team come prima cosa proponga uno skateboard, fa il suo dovere certo ma è scomodo, fa sudare e bisogna avere equilibrio. Si pensa allora ad un incremento, un monopattino: meglio ma ancora non ci siamo. Allora si fa un altro passo avanti e si propone una bicicletta, andrà magari meglio di prima ma costringe comunque ad uno sforzo fisico. Mettendo al monopattino un motore otteniamo un motorino, mezzo immune al traffico costa molto meno della macchina e consuma meno.
Manifesto for Agile Software Development agilemanifesto.org Scrum Alliance Certification www.scrumalliance.org
Uno dei principi cardine dello Scrum è proprio l’interattività e l’incrementalità; si stabilisce un periodo temporale fissato da una a quattro settimane e ad ogni fine periodo bisogna fornire un valore al cliente. In questa maniera il cliente è coinvolto, vi da un feedback immediato, vede crescere l’idea passo dopo passo e la possibilità di dargli in mano qualcosa, che non voleva diventa molto più bassa; l’intento di Scrum è quello di minimizzare il rischio. Esistono diverse declinazioni “Agili” che prediligono un aspetto piuttosto che un’altro, esiste Scrum, Kanban, Extreme Programming però il primo è quello che allo stato attuale rappresenta quasi l’80% del mercato che poi alla fine è quello che ho scelto. Come detto in precedenza Scrum è una maniera di applicare i principi del manifesto Agile, per andare nello specifico questi sono i principi e come io li interpreto.
Gli individui e le interazioni più che i processi e gli strumenti: mettere davanti alla rigidità degli strumenti e dei processi la comunicazione tra le persone dentro e fuori l’azienda. Serve trasparenza, bisogna cercare di far emergere i problemi e non metterli sotto il tappeto, tutti gli ostacoli devono essere evidenti a tutti per poterli superare.
Il software funzionante più che la documentazione esaustiva: legarli rigidamente alle procedure e documentare qualcosa che non è completo e che addirittura non va, è deleterio per il progetto.
La collaborazione col cliente più che la negoziazione dei contratti: se non c’è fiducia tra chi fa il lavoro e chi lo commissiona non si arriverà mai a un prodotto soddisfacente per nessuna delle parti; bisogna condividere con il cliente, la visione del prodotto. Determinare cosa c’è da mettere sul contratto e “difendersi” dal cliente non deve essere il perno del contratto; ci sono contratti che prevedono questo tipo di interazione ma se la nostra preoccupazione principale è quella legale, c’è qualcosa che non va.
Rispondere al cambiamento più che seguire un piano: fare un bel digramma di Gantt e cercare di seguirlo non è una soluzione, ma una fonte di problemi; bisogne essere flessibili alle richieste di chi commissiona il lavoro. Si deve abbracciare il cambiamento in qualsiasi momento e a qualsiasi livello, seguire le esigenze del committente; in una parola si deve avere il coraggio di iniziare a creare e cercare una soluzione senza aver tutti gli elementi in mano, anche senza tante specifiche.
Fig.1 Principi Scrum (Credit Scrum Alliance Professional)
Ovviamente scritti così dicono e non dicono, per questo esistono i framework agili, cioè delle maniere di applicarle che consentono di trovare un ritmo e non andare ad occhio.
Parliamo quindi di Scrum e iniziamo con i ruoli in gioco: non esiste il project manager (per chi si arriva dal lato prettamente tecnico è un hip hip hurrah!) A parte le facili battute questo aspetto ha fatto sì che Scrum mi colpisse da subito per il cambio di visuale. La parola d’ordine è co-creation, tutti devono dare il proprio contributo le idee possono arrivare da tutti, i ruoli sono meno rigidi.
Un’ottica interessante a tal proposito è il push-pull; quando noi diamo da fare qualcosa a qualcuno e gli diciamo come farlo stiamo lavorando push cioè spingiamo verso il nostro in-
terlocutore. Questo comporta che ci si focalizzi spesso sui piccoli problemi invece che pensare all’obiettivo del business, aumenta la competizione tra le persone e spesso gli individui cercano di fare il loro lavoro, per soddisfare la domanda che gli abbiamo posto quindi usando criteri minimi, facendo sì che la qualità ne perda aumentando così lo stress. Il principio pull è l’esatto opposto, si propone una problematica e si fa sì che la gente proponga una soluzione, le persone sono più motivate, si sentono parte di qualcosa e, soprattutto, si focalizzano sull’obiettivo così mettono il meglio di loro, non il minimo.
Scrum, il lavoro in “mischia”
Vediamo quindi come si organizza il lavoro, Scrum divide le figure in tre: innanzitutto il team di sviluppo cioè colui che esegue il lavoro; deve avere tutte le competenze necessarie per poter svolgere le proprie funzioni. Deve essere una squadra affiatata ed efficiente, il numero di persone consigliato è di 7 +/- 2. Anche team più piccoli possono andare bene, a patto che le competenze siano coperte, l’importante è che assolutamente non possono essere più grossi di così: questo per il semplice fatto che la comunicazione è fondamentale e cardine, tutti devono essere al corrente delle cose e più si è, più i canali di comunicazione si moltiplicano e il nostro cervello ha dei limiti fisici, e già con 9 sono (N * (N - 1)) / 2 quindi 36: già se abbiamo 15 persone abbiamo già 105 canali che sono impossibili di mantenere. Se si è in troppi si finisce per ignorare alcune informazioni a favore di altre, di perdere pezzi in giro magari nel momento in cui ne avevamo bisogno.
A fianco del team abbiamo altre due figure che derivano (detto in maniera semplice) dalla figura del project manager che è stata divisa in due figure ben distinte. La prima di cui voglio parlare è lo Scrum Master; la sua definizione spiccia è quella di “leader servente”. È una specie di garante che presenzia a tutti i rituali (che vedremo) di Scrum, fa da ponte tra il team e le altre entità, monitorare gli andamenti e si accerta che il team non venga mai disturbato e sia messo in condizioni di dare il meglio; è a disposizione del team e un coach, come un allenatore. Altra funzione fondamentale è quella di rimuovere gli impedimenti, cioè facilitare (appunto) il lavoro del tema rimuovendo gli ostacoli, incomprensioni comprese.
Sempre come costola del Project Manager, è il Product Owner. Si interfaccia con il cliente (stakeholder in generale) e ne raccoglie le esigenze, è un po’ se vogliamo “l’avvocato del cliente” o il portavoce nel team delle esigenze del committente. Il suo compito è quello di massimizzare il valore di quanto prodotto per il cliente.
Fig.2 I ruoli nello Scrum (credit Scrum Alliance)
Vediamo adesso come è ritmato il lavoro, Scrum infatti è un framework ben cadenzato che prescrive una serie di eventi, che spesso prendono il nome di cerimonie. Si inizia suddividendo il tempo in slot temporali chiamati sprint, possono essere lunghi da una a quattro settimane a seconda delle esigenze; in
ogni uno di questi sprint avvengono dei riti chiamati eventi che si ripetono ad ogni ciclo. Viene creata una lista di cose da fare detto backlog, è una coda di elementi che il PO discute con il cliente e che viene ordinata secondo le priorità. Durante ogni sprint vengono selezionati da questa lista una serie di elementi che si decide verranno fatti nello sprint successivo. Questi elementi sono sempre più dettagliati man mano che si va dal basso verso l’alto di questa lista, ad ogni iterazione bisogna tenerli aggiornati ed occorre aggiungere dei dettagli. Come abbiamo detto un cardine è la comunicazione, per questo ogni giorno lo scrum master fa una riunione di pochi minuti, con presente tutto il team. Ogni membro dice a che punto è, cosa farà e se ha trovato difficoltà o ci sono cose da chiarire. Lo scopo non è di discutere di come sistemarlo, ma di sincronizzare gli altri ed eventualmente chiedere aiuto; è qui che lo scrum master si prende in carico eventuali impedimenti. Questo incontro deve durare pochi minuti e di solito si tiene davanti ad una board dove sono presenti i task da fare; questa board è divisa in tre colonne, da fare, in lavorazione e fatto, serve per avere a colpo d’occhio lo stato di avanzamento. Durante lo sprint avvengono anche altri “riti” come la rifinitura del backlog dove product owner, scrum master ma anche il team elaborano i task per il futuro migliorandone il dettaglio. Importantissimo è che verso la fine devono avvenire due cose: la prima è che venga prodotto un incremento di valore per l’utente, una feature un modulo, qualcosa che il cliente possa usare da subito. Per avere feedback immediato a fine sprint avviene un evento chiamato review in cui tutti, stakeholder compresi, si trovano per visionare quello che è stato fatto; è qui che avviene il feedback e dove si vede se si sta andando nella direzione giusta. Ma non basta aver dato al cliente qualcosa di valore, ad ogni sprint bisogna migliorare il prodotto sì ma anche se stessi e i propri processi. Per questo un altro evento fondamentale è la retrospettiva: ci si trova tutti, team, scrum master e product owner per discutere cosa si può fare meglio, cosa migliorare così da avere un doppio feedback sia dal cliente che dal processo in sé. Differentemente da un processo classico si intuisce che dando un incremento costante al cliente, si finisce per convergere verso la soluzione ottimale però essendo incrementale, la domanda è come pianificare. Assumendo che ogni task abbia una stima e sapendo mediamente quanti task (e quanto grossi sono) il team può fare in uno sprint, si può fare una proiezione e calcolare una forbice di caso migliore / peggiore. Chiaramente per poter fare stime c’è la necessità di avere dello storico alle spalle, per questo si dice spesso che per adottare scrum, serve un percorso a volte di anni, non si può concretizzare in poco tempo. Un’altra astuzia sta nel dimensionare il peso delle cose da fare, non in ore; bisogna ricordarsi che è un processo creativo, non si può conteggiare il tempo come se fossimo in fabbrica. Si dà spesso un numero senza unità di misura così da poter distinguere task grossi da task piccoli, ma mai dandogli un tempo preciso, se no ricadiamo nell’errore originario cioè cercare di far diventare deterministico un processo empirico.
Da dove iniziare
È quindi Agile - e Scrum in particolare - una rivoluzione? No, è una presa di coscienza! Una frase che mi ha colpito molto nello studio del materiale di uno dei creatori di Scrum (Sutherland) è la frase “Non bisogna pianificare la fantasia”. Per anni ho visto i diagrammi di Gantt, redatti a inizio progetto pensando che quella fosse la pianificazione corretta; non tutti sanno che è uno strumento pensato per l’approvvigionamento delle truppe durante la prima guerra mondiale.
La domanda successiva è quindi, da dove inizio? Il consiglio è quello prima di tutto cercare di capire da dove si sta partendo, Scrum è collaborativo, se non si è tutti d’accordo è difficile da applicare; quindi la prima cosa è quella di trovare un team che voglia il cambiamento. Bisogna poi tranquillizzare le persone, perché in un assetto classico avremo vari manager che vedranno cambiato il loro potere e questo è un aspetto spesso complicato; vi ricordo che il project manager che si siede a fianco delle persone per interrogarle, e fare micro management non esiste più. I team leader diventano scrum master e gestiscono tutti i riti e i ritmi di scrum. I
project manager diventano product owner e a loro volta i team devono diventare interfunzionali e autogestiti e responsabili del proprio outcome. Il consiglio è quello di iniziare con del materiale, iscriversi ad un corso qualificato e se si vuole, farlo da soli per prendere confidenza. Poi ci sono tanti enti che fanno coaching e che possono accompagnarvi, ma questo è un secondo step. Ricordatevi sempre che Scrum è facile da capire ma difficile da applicare quindi non perdetevi d’animo; il cambiamento deve essere voluto prima di tutto!
Keyword: Project Management, Agile, Scrum, Product Owner, Scrum Master, Lean, Kanban, Extreme Programming, Gantt, Mockup, MVP *Alessandro Cappellozza, IoT Engineer
AGILE AND SCRUM, THE PERSPECTIVES OF MODERN DESIGN
In recent years, companies have had to deal with demands for lean production, turbulent and aggressive markets, rapid technological innovations and new models of governance. All this has led to profound changes in the design domain, for which traditional approaches and methods are often inadequate. To help companies and designers to manage increasingly complex projects, advanced Project Management techniques have been introduced: Agile and Scrum. We try to understand more in this article. by Alessandro Cappellozza*
I guess you’ve found yourselves, or heard about, projects that never end or fail to meet the client’s expectations. In a world so dynamic and at the same time so distracted, it is easy to load a requirement or even the whole project with expectations, especially in the IT field: the agile movement tries to reverse this trend. Since the last industrial revolution we have been lulled into the illusion that by planning the work as a whole in step and having a precise set of specifications, we can draw a nice Gantt diagram and respect it: you know very well that in computer science, now master of every aspect, in a world in whirling evolution, the classic cascade method simply does not work; too long times, now that you finish the product or a phase, it is already old or the customer has changed the specifications. Even worse, computer science is rather impalpable and very subjective, everyone’s expectations vary a lot and often even a good specification is not enough.
What is meant by “Agile Agile is not a method, it’s a set of principles. In the early 2000s a group of experts outlined a set of four key principles and twelve statements to follow, not only to give more value to their work, but to (finally) succeed in lowering the risk and make both you and the client happy. As you can imagine, this is not a magic formula but a radical change of perspective for everyone.
I would start by explaining why we don’t talk about method: we have to think of the Agile as an intellectual scaffolding within which the work is done, it doesn’t tell you how to do it but what rhythm and spirit to give it; within this scaffolding (framework) you can use the method that suits you best. It is like imagining the work as a river, the framework are the embankments and the water your work.
Project management with Scrum The context in which they are inserted is very clear; they are born in the IT field, because more than in other contexts here there is uncertainty; Scrum (by far the most widespread version of the Agile framework) works in empirical systems where you know how long it takes to do things only after you have done them. Generally we tend to divide the processes into three families, the deterministic ones where you know how long it takes to do a certain job. The statistical ones where you measure yourself with a certain degree of uncertainty but you can calculate it. Finally we have the empirical ones that are typical of creative processes in which it is complex to determine a time to perform a task never done before, and it is here that it has its maximum usefulness. To explain how it works, we often use an example of a team that is asked by a client, a means to get to work. A classic system would immediately think of a means that has already been used in the past, in this case it could be a machine. Then start designing the engine, chassis, bodywork and interior. The customer will only be involved in mockups and intermediate stages, will plan with a nice Gantt diagram and will end up with a vehicle. At the end of this process I have the same chance whether it goes well or not for the customer, the uncertainty is huge and this is because the customer has never seen the complete product before. Who hasn’t heard the customer’s “but I thought” phrase before? We are in a field where the risk is high, the machine can make the customer happy but perhaps far beyond his needs making the project unnecessarily expensive. The iterative method, on the other hand, is based on a different principle, it is based on a principle known in the Lean Manufacturing environment called MVP, i.e. Minimum Operating Product; it is the minimum that can be done to meet the customer’s needs. In this specific case we could think that the team first of all proposes a skateboard, it does its duty but it is uncomfortable, it makes you sweat and you have to have balance. We then think of an increase, a scooter: better but we are not there yet. Then you take another step forward and propose a bike, maybe it will go better than before but still forces a physical effort. Putting an engine to the scooter we get a scooter, half immune to traffic costs much less than the car and consumes less.
The principles One of the key principles of the Scrum is precisely interactivity and incrementality; a fixed time period of one to four weeks is established and at each end of the period a value must be provided to the customer. In this way the customer is involved, gives you immediate feedback, sees the idea grow step by step and the possibility of giving him something he did not want becomes much lower; Scrum’s intention is to minimize the risk. There are different declinations “Agile” that prefer one aspect rather than another, there is Scrum, Kanban, Extreme Programming but the first is the one that currently represents almost 80% of the market and then in the end is the one I chose. As said before Scrum is a way to apply the principles of the Agile Manifesto, to be specific these are the principles and how I interpret them. Individuals and interactions more than processes and tools: putting in front of the rigidity of tools and processes the communication between people inside and outside the company. We need transparency, we must try to bring out the problems and not sweep them under the carpet, all the obstacles must be evident to everyone in order to overcome them. The software works more than the exhaustive documentation: strictly linking them to the procedures and documenting something that is not complete or even wrong is detrimental to the project. Collaboration with the client more than contract negotiation: if there is no trust between the person doing the work and the person commissioning it, there will never be a satisfactory product for either party; you have to share with the client, the vision of the product. Determining what to
put on the contract and “defend” yourself against the client should not be the pivot of the contract; there are contracts that provide for this type of interaction but if our main concern is the legal one, there is something wrong. Responding to change rather than following a plan: making a good Gantt digression and trying to follow it is not a solution, but a source of problems; you have to be flexible to the demands of the person commissioning the work. You have to embrace change at any time and at any level, follow the needs of the client; in a word, you have to have the courage to start creating and looking for a solution without having all the elements in hand, even without many specifications. Obviously, that’s what they say and don’t say, that’s why there are agile frameworks, that is, ways to apply them that allow you to find a rhythm and not go by eye. So let’s talk about Scrum and start with the roles at stake: there’s no project manager (for those who come from the purely technical side it’s a hip hip hurrah!) Apart from the easy jokes this aspect made Scrum hit me right away for the change of view. The watchword is co-creation, everyone has to contribute ideas can come from everyone, the roles are less rigid. An interesting point of view in this regard is the push-pull; when we give someone something to do and tell them how to do it we are working push, that is, we push towards our interlocutor. This means that we often focus on small problems instead of thinking about the objective of the business, it increases the competition between people and often individuals try to do their job, to meet the demand we have set them then using minimum criteria, so that the quality loses and the stress increases. The pull principle is the exact opposite, you propose a problem and make people propose a solution, people are more motivated, they feel part of something and, above all, they focus on the goal so they put the best of them, not the least.
Scrum, the “melee” job... So let’s see how the work is organized, Scrum divides the figures into three: first of all the development team, that is, the one who carries out the work; it must have all the necessary skills to be able to perform its functions. It must be a close-knit and efficient team, the recommended number of people is 7 +/- 2. Even smaller teams can be fine, as long as the skills are covered, the important thing is that they absolutely can not be bigger than that: this is for the simple fact that communication is fundamental and pivotal, everyone must be aware of things and the more you are, the more channels of communication multiply and our brain has physical limits, and already with 9 are (N * (N - 1)) / 2 then 36: already if we have 15 people we already have 105 channels that are impossible to maintain. If you are in too many you end up ignoring some information in favor of others, losing pieces around maybe when we needed them. Next to the team we have two other figures that derive (in a simple way) from the figure of the project manager who has been divided into two very distinct figures. The first one I want to talk about is the Scrum Master; his definition stands out as “serving leader”. It is a kind of guarantor who attends all the rituals (that we will see) of Scrum, acts as a bridge between the team and the other entities, monitors trends and ensures that the team is never disturbed and is put in a position to give the best; it is available to the team and a coach, like a coach. Another fundamental function is to remove obstacles, i.e. to facilitate (precisely) the work of the theme by removing obstacles, including misunderstandings. Always as the rib of the Project Manager, is the Product Owner. He interfaces with the client (stakeholders in general) and collects their needs, it’s a bit if we want “the client’s lawyer” or the spokesman in the team of the client’s needs. His task is to maximize the value of what is produced for the client. Let’s see now how the work is rhythmic, Scrum is in fact a well cadenced framework that prescribes a series of events, often called ceremonies. It starts by dividing the time into time slots called sprints, they can be from one to four weeks long depending on the needs; in each one of these sprints there are rituals called events that are repeated at each cycle. A list of things to do called backlog is created, it is a queue of items that the PO discusses with the customer and is sorted according to priorities. During each sprint a series
of items are selected from this list that you decide will be done in the next sprint. These items are more and more detailed as you go from the bottom to the top of this list, with each iteration you have to keep them updated and add details. As we’ve said, communication is the cornerstone, that’s why every day the scrum master makes a meeting of a few minutes, with the whole team present. Each member says where he is, what he will do and if he has found difficulties or there are things to clarify. The purpose is not to discuss how to fix it, but to synchronize the others and eventually ask for help; this is where the scrum master takes care of any impediments. This meeting must last a few minutes and usually takes place in front of a board where there are tasks to be done; this board is divided into three columns, to be done, in progress and done, serves to have an overview of the progress. During the sprint there are also other “rituals” such as the finishing of the backlog where product owner, scrum master but also the team work out the tasks for the future improving the detail. Very important is that towards the end two things have to happen: the first is that an increase in value for the user is produced, a feature a module, something that the customer can use immediately. To get immediate feedback at the end of the sprint there is an event called review where everyone, including stakeholders, is there to see what has been done; this is where the feedback takes place and where you can see if you are going in the right direction. But it’s not enough to have given the client something of value, with each sprint you have to improve the product but also yourself and your processes. That’s why another key event is the retrospective: everyone is there, team, scrum master and product owner to discuss what you can do better, what you can improve so you get double feedback from both the customer and the process itself. Differently from a classic process you can understand that by giving a constant increase to the customer, you end up converging towards the optimal solution but being incremental, the question is how to plan. Assuming that each task has an estimate and knowing on average how many tasks (and how big they are) the team can do in a sprint, you can make a projection and calculate a better / worse case spread. Clearly in order to make estimates there is a need to have a historian behind you, that’s why it is often said that to adopt scrum, you need a path sometimes of years, you can not materialize in a short time. Another cunning lies in sizing the weight of things to do, not in hours; one must remember that it is a creative process, one cannot count time as if we were in a factory. We often give a number without units of measurement so that we can distinguish big tasks from small tasks, but never giving it a precise time, otherwise we fall back into the original error, that is, trying to make an empirical process become deterministic.
Where to start So is Agile - and Scrum in particular - a revolution? No, it’s an awareness! One phrase that struck me very much in the study of the material of one of the creators of Scrum (Sutherland) is the phrase “You don’t have to plan your fantasy”. For years I’ve seen Gantt’s diagrams, drawn up at the beginning of the project thinking that that was the correct planning; not everyone knows that it was a tool designed to supply troops during World War I. So the next question is, where do I start? The advice is to first try to understand where you’re starting from, Scrum is collaborative, if you don’t all agree it’s difficult to apply; so the first thing is to find a team that wants change. Then you have to reassure people, because in a classic setup we will have several managers who will see their power changed and this is often complicated, I remind you that the project manager who sits next to people to question them, and do micro management no longer exists. Team leaders become scrum masters and manage all the rituals and rhythms of scrum. Project managers become product owners and in turn teams must become cross-functional and self-managed and responsible for their own outcome. The advice is to start with some material, sign up for a qualified course and if you want, do it yourself to get familiar with it. Then there are many coaching organisations that can accompany you, but this is a second step. Always remember that Scrum is easy to understand but difficult to apply so don’t lose heart; change must be wanted first!
Safety You Can Rely On
In the process industry, even the smallest fault can have catastrophic consequences for people, the environment, and your assets.
That’s why you need a trusted safety partner to put your mind at ease.
HIMA is the leading global provider of secure functional safety solutions that you can count on. Run your plant not only safely, but also efficiently and profitably with HIMA’s comprehensive range of applications:
• Emergency shutdown • Fire and gas systems • Turbomachinery management • Burner management • Pipeline management • HIPPS • Wellheads
Become an Insider!
Subscribe to receive updates from HIMA.
www.hima.com/updates
