Agile@School – Anno terzo – Apertura del progetto

Siamo già al terzo anno consecutivo. Il tempo vola, ma devo dire che i progetti che sono nati in Engage IT Services sono anche solidi, graditi e duraturi. È successo con gli eventi (quest’anno ben tre per coprire i trend topic IoT, DevOps e il nostro SQL Saturday) e accade anche con Agile@School. Pensate che nel 2017 abbiamo “aperto” anche una nuova realtà in quel di Rovigo, grazie a Michele Ferracin (qui i suoi post in reblog e le statistiche finali). Insomma, il motore gira, forte e non dà cenni di arresto. Quindi siamo qui, 2018 nuovo vestito per il progetto e la scelta di scrivere i post ad esso relativi in italiano, anche per rispettare quanto fatto nel nostro Paese.

La nostra azienda è finalmente entrata a far parte di un progetto più ampio di Alternanza Scuola Lavoro per la nostra scuola di riferimento (I.I.S.S. Gadda di Fornovo, Parma) per cui, a differenza delle edizioni precedenti, quest’anno potremo sfruttare un intero mese. Gli studenti non avranno più incontri isolati ma una serie di giornate consecutive di lavoro “sul pezzo”, senza dispersioni e senza includere ore extra scolastiche, sulle quali è piuttosto difficile investire per gli adolescenti. Ma non solo, quest’anno abbiamo anche un “corpo docenti”: non mancherà chi ci ha supportato fin dall’inizio (la prof. Pinella Pedullà, informatica e tecnologia) ma avremo anche importanti aggiunte, come il prof. Stefano Saccani (informatica), la prof. Enrica Groppi, il prof. Graziano Maniello e tutti quanti hanno supportato il progetto “donando” le ore del normale programma di studi.

Edizione 2018

Partiamo con la descrizione di Agile@School 2018. Due anni fa, l’edizione pilota, spiegammo ad una decina di ragazzi di quinta superiore come affrontare un singolo progetto in agile (Scrum), mentre l’anno scorso abbiamo optato per un’idea multi-progetto e multi-team con supporto di kanban board. In entrambi i casi, la base è stata Visual Studio Team Services utilizzato con template differenti.

L’approccio

Quest’anno Gabriele Etta (lo ringrazio per essermi sempre di aiuto) ed io abbiamo optato per lasciare libertà agli studenti, concentrando l’iter sulla self-organziation e sul principio di responsabilità. L’obbiettivo è in definitiva quello di raggiungere un approccio “dal basso verso l’alto” (bottom-up) in cui scelte e proattività vincono su comando e controllo. Come? Ponendo gli studenti di fronte ai problemi, lasciandoli fare, sempre nell’ottica della realizzazione di un prodotto/servizio. Ovviamente la nostra presenza è quella che consente loro di ottenere consigli pragmatici su comportamenti e strumenti disponibili.

img_20180517_083248.jpg

Le novità

Questa edizione porta con sé differenze anche per la classe ed il numero di persone. Una ventina di ragazzi di terza, che molto probabilmente incontreremo ancora nel 2019 e, perché no, anche nel 2020. Ed è questa la vera novità. Agile@School sarà un progetto a lungo termine, non dedicato ad un solo anno scolastico. Approfondiremo la conoscenza con gli studenti e potremo valutarli anche su più aspetti, nel tempo. A mio modo di vedere ciò corrisponde ad un grande valore aggiunto per gli studenti, per la scuola e per noi. Un percorso da seguire tutti insieme.

Il primo incontro

Nella prima “puntata” abbiamo affrontato un punto delicato della comunicazione. Il farsi conoscere, capire le proprie attitudini ed esporre i propri interessi. Ma non solo, uno dei primi passi per responsabilizzare i ragazzi è stato quello di selezionarsi a vicenda, di lasciar costruire i team naturalmente, senza imporre nulla. Certo, abbiamo cercato di far capire che un team può essere costituito da ruoli diversi e che non è una cattiva idea far crescere anche persone che non sono “forti” in particolari ambiti, ma quello è stata l’unico consiglio. Abbiamo in poco tempo ottenuto cinque team, due dei quali da cinque elementi e tre da quattro.

I progetti

I professori prima dell’incontro hanno creato un elenco di cinque idee, tutte orientate al mondo dell’IoT e, per essere più precisi, al rapporto tra l’informatica e l’elettronica ai giorni nostri. Tutti i progetti sono basati su Arduino e sul kit di sviluppo con esso fornito. Ogni idea è vista come una “partenza”, che corrisponde al requisito minimo e necessario ma che, allo stesso tempo, può essere estesa e resa “personalizzata” a scelta del team, con analisi, implementazioni, studi e rischi annessi. Nel prossimo post descriveremo meglio i contenuti, ma possiamo affermare che la base è tendenzialmente la gestione di sensori di vario genere e la presentazione su web con utilizzo di storage per il salvataggio degli eventi che si verificano. Il prof. Saccani, dopo la presentazione dei progetti, ha osservato con noi i ragazzi procedere alla creazione autonoma dei team e all’assegnazione di progetti. Dopo un primo conflitto di preferenza (ogni idea poteva essere assegnata ad un solo team) e dopo aver capito la possibilità infinita di estensioni applicabili in ogni ambito, le squadre hanno concordato le assegnazioni finali.

img_20180517_101351.jpg

Le cerimonie

Il primo meeting che è stato suggerito ai ragazzi è il daily meeting. Con un’occasione del genere (tutti i giorni a lavoro per un mese, ricordo) non potevamo fare altrimenti. Abbiamo spiegato le tre fatidiche domande, illustrando i modelli di risposta accettabile e non, ponendo l’attenzione sui tempi e sul livello di dettaglio. Fare il daily meeting è stato uno dei compiti assegnati a tutti.

La gestione delle attività

Come strumento per il task management abbiamo suggerito Trello e come chat collaborativa Slack, cercando di non consigliare altro. Come compito, alla fine della settimana, ogni team dovrà aver ideato un nome per il proprio “prodotto”, un’analisi iniziale, soprattutto funzionale, e una relazione per descrivere i casi d’uso. E chiaramente dovrà presentarlo, simulando una sorta di “ricerca fondi” da investire nella produzione concreta del prodotto stesso. Proprio come una piccola startup.

Per chiudere

Tutti ci aspettiamo soddisfazioni da Agile@School 2018 e confidiamo nel fatto che sia una buona base per i prossimi anni. Le premesse sono più che soddisfacenti, ma dovremo valutare passo dopo passo, cercando di adattarci al cambiamento. Al prossimo appuntamento…

Stay tuned! 🙂

Dalle Stelle alla Sfera Celeste

Molte delle azioni che si mettono in campo per intraprendere la strada dell’agilità riguardano i team, andando a lavorare su Teamcon la “T” maiuscola, intesi come una cellulain grado di adattarsi e riconfigurarsi per creare Valore.

Questo aspetto è specificamente formalizzato in Lean, relativamente al JIT Pillar, e identificato come Cellular Manufacturing, con l’obiettivo di aumentare la produttività, riducendo il Lead Time grazie alla semplificazione della programmazione, al controllo produzione e alla riduzione delle scorte. Il tutto è reso possibile dalla spinta sulla comunicazionee sul coordinamento.

cellular manufactoring

L’aspetto fondamentale è che il Team lavora su un’attività specifica e lo fa al meglio, tendenzialmente inseguendo lo stato dell’arte, coordinandosi con le cellule a monte e a valle per garantire un flusso costante e sostenibile.

Ma cosa succede se il team è un teamcon la “t” minuscola, ovvero un insieme di Persone che sono sedute vicine, a stento si parlano e che sono impegnati su più progetti contemporaneamente, anche gestendoli in modo esclusivo?

Si tratta di una condizione più comune di quanto si pensi, che rende arduo attuare una trasformazione Agile/Lean (o DevOps), e che non tiene conto di principi ormai universalmente riconosciuti come il costo di uno switch continuoe un ritmo di lavoro sostenibile(entrambi MUDA).

Difficile in queste condizioni, ad esempio, pensare a Scrum, perché: che senso ha fare Scrum se le attività (parlare di Product Backlog in tal caso è un eufemismo!) sono in carico ad una sola persona? Come farebbe il Daily… guardandosi allo specchio?

Scherzi a parte, in alcuni casi è più utile immaginare un percorso progressivo che permetta di inserire elementi di ottimizzazione e cominciare a porre le basi di una cultura orientata alla comunicazione e alla gestione sostenibile delle attività.

Di base può balzare in mente un approccio Kanban-like, ma non bisogna dimenticare che operare in tal modo richiede una forte maturità per non “lasciare indietro” aspetti fondamentali (si pensi al fatto di non fare la retrospettiva perché non si ha tempo), motivo per cui approcci di questo tipo spesso si utilizzano nello scaling… ma qui possiamo avere un problema: posso immaginare di usare Kanban come base e poi “scalare” a qualcosa più simile a Scrum quando aggrego più persone? Ha senso?

Per provare a immaginare un approccio che possa comunque supportare anche gruppi di 2 persone, guardando ad una dinamicità guidata dallo stream di attività legate ad un cliente, stiamo sperimentando quello che ha preso il nome di AgileConstellatione che trovate all’indirizzo agileconstellation.org

celestialsphere bigpicture

Siamo curiosi di avere i vostri feedback, suggerimenti o altro.

Stay tuned J

VSTS for beginners: release your web-app to Azure

In the previous post of this series dedicated to VSTS we talked about continuous integration. Now we’ll talk about publishing our Web-App hosted on Azure with the release management tools provided by VSTS. With this kind of tools we can deploy the latest version of our web-app to Azure in complete automation removing manual procedures and human errors. The setup of Azure will be covered in another blog post.

 

1. Release management

To setup a release we need to open the Build and Release menu and then Releases.

2018-04-25_15-00-11

From here we create a new Release definition with the “plus” menu and select Create release definition.

2018-04-25_21-40-05.png

VSTS opens a template browser for use and we choose the Azure App Service Deployment and click Apply.

3.png

As we can see the template has been applied and the Pipeline section of the definition needs our attention.
The basic components of a build are:

  • Artifacts: they are the output products of a build process (zip file, NuGet package, msi installer, etc.). A release process takes one o  more artifacts from one or more builds and deploys them into
  • Environments: they are the deployment target of the release process and they represent our infrastructure. Typical examples are Staging and Production.

Setup artifacts source

Now we need to configure the artifacts source of our release to tell VSTS where to get the bits that we want to deploy.  As we can see in the next image we have to click the “+ Add artifact” button.

5

Now we set a Build as source type and the source. In our case (linked to the previous post) we choose our Parrish Shoes project and the build definition that builds our web-app. Finally we click Add.

6

 

7

Environment

Now it’s time to setup the environment. In this basic tutorial we’re going to have only one environment. In a real world scenario you’ll probably have at least a test environment before production.

We click the link under the environment name with the red exclamation mark that’s telling us that some parameters are missing.

8

The release process in this environment called Environment 1 is composed by only one step that the template added for us: Deploy Azure App Service. If our Azure account is well configured, VSTS will prompt our Azure Subscription and App service Name when we open the respective combo-boxes (step 1 and 2). Now it’s time to save (Step 3).

 

92.png

Release it!

Our release process is completed, now let’s give it a try! In the upper-right side of the screen click Release and then Create release.

10

In the next screen we’ll use default values and hit Create.

11

As we can see we have a nice green feedback that a release has been created!

12

If we click on the name Release-1 we can see that it’s now in progress.

13

After a couple of minutes the build is ok: succeded! (you may need to refresh manually the page to get the deployment status updated)

(Bonus point) Continuous Deployment

We can deliver our latest version of the web-app without having to start our release process manually by activating the Continuous Deployment trigger. We click the lightning icon in the corner of the artifact source and enable the switch that by default is set to disabled. This way everytime a build is completed successfully the release process will start and our web-app will be updated without effort!

14100

TL;DR

With this blog post we’ve setup a simple release process for a web-app hosted on Azure. With the templates loaded in VSTS we had to complete a few fields to setup the artifact source and the link to our Azure account. We are more confident with the concepts of artifact and enviroment and their role in a deployment pipeline.

An automated process for a real world application can be much more complex than this. However, we can see that automation is a very powerful tool to reduce the global leadtime of our process and deliver features or quality improvements to our users.

In the fast-paced world of today this is the way we want to go through if  we want to give our project a brilliant success!

La congiunzione astrale dell’indipendenza del Verbo

Qualsiasi trasformazione richiede tre elementi fondamentali: tempobudgetsponsorship. Questo è un dato di fatto a prova di smentita, tant’è che il venir meno di uno di essi compromette fortemente, se non inesorabilmente, le possibilità di successo dell’azione intrapresa.

In particolare, è necessario riflettere molto sulla sponsorshipe capire se essa sia reale opportunistica:

  • la sponsorship è realequando gli sponsor sono i primi ad essere coinvolti nell’azione di trasformazione, calandosu di sé quando si sta sperimentando e accettandodi rimettersi in gioco, consci che il tutto possa portare un reale beneficio all’intera organizzazione. Bisogna essere convinti della necessità del cambiamento, unitamente ad una buona dose di umiltà e capacità di guardarsi intorno per capire se il percorso intrapreso sta portando benefici;
  • la sponsorship è opportunisticaquando non è minimamente sentita, ovvero quando si supporta un cambiamento solo perché “qualcuno lo ho detto o perché tutti lo fanno”. In tal caso si cerca di piegare la stessa ai propri interessi, intervenendo fortemente nelle diverse azioni al fine di plasmarle secondo le proprie necessità e mantenere la propria confort zone, eventualmente appuntandosi una nuova “etichetta” che però non modifica la sostanza. 

Come diceva Tancredi ne “Il Gattopardo”: Se vogliamo che tutto rimanga come è, bisogna che tutto cambi… e quindi bisogna fare molta molta attenzione nel rispondere rapidamente alla condizione che ci vede difronte ad una sponsorship opportunistica. 

lampedusa gattopardo

Purtroppo, è molto difficile riuscire inizialmente ad indentificare la specificità: solo il tempo ci da la possibilità di captarecapireed analizzarei segnali ed i fatti che possono portarci ad avere un’idea in merito. 

Un elemento che però è fortemente indicativo è l’Indipendenza degli Agenti di Trasformazione (o dei Coach se siete in chiave Agile), che devono potersi muovere calando sulle evidenze le azioni che ritengono più consone, dando messaggi chiari che evidenzino sempre quale sia l’obiettivo ideale e quali, invece, sono i compromessi da accettare per cominciare ad innescare il cambiamento e generare miglioramenti.

Guai se i messaggi sono “tarati” sui desideri dello sponsor: in questo caso non stiamo solo dicendo addio al nostro “viaggio”, ma anche alla credibilità stessa dell’approccio che stiamo proponendo. Nessun commento superfluo è ovviamente utile per definire chi si presta a tale azione.

Se si verifica una congiuntura astraleche allinea tutti questi elementi, il risultato ultimo si sintetizza con una frase che purtroppo si sente non di rado: “Agile non funziona!”che di per sé è priva di significato essendo Agile un mindset formato da Valori e Principi e non da processi che invece vanno contestualizzati… …nel modo giusto.

Stay tuned J

VSTS for beginners: improve quality with continuous integration in 3 easy steps

In this blog post we’re going to configure a build process in VSTS to enable continuous integration for our ASP.Net Core example web-app.
Continuous integration is a powerful technique to prevent merge-hell and improve quality on the “left” stages of our software production process. In the fast-paced world of development we want to merge into the main line of development the new developed features as soon as possibile to avoid open branches that will cause painful merges. If we keep our unit of work small and focused we’ll have great benefits.

In this tutorial we’ll start from scratch creating a new .net core 2 web-app and then we configure VSTS.

If you have a working project you can jump to the second step.

1. Create a .Net Core web-app

We open a PowerShell command line and create a new folder for our project. For this example I’ll use the name Parrish (the shoes company from the movie Jumanji).

>PS mkdir parrish-mvc

And then we turn this into a git repository:

>PS git init

We add a gitignore file into the root of the repository to commit into git only the meaningful files. We can use this one.

Now we create a standard .NET Core MVC project with the PowerShell command line:

PS> dotnet new mvc

Then we open the project with Visual Studio and hit F5. We can see the web app up and running.


Now we have our web-app that we want to build in an automated fashion on VSTS.

2. Upload the code to VSTS

To leverage VSTS features we need to upload our repo.

  1. We commit everything we’ve done with the commands
    git add .
    git commit -m "Init"

    With this commands we’re adding to the git index all the files we created and making the first commit with the “Init” message.

  2. We upload to VSTS with the commands:
    git remote add origin https://xxxxx.visualstudio.com/_git/ProjectName
    git push -u origin --all

The code is now on VSTS and we can browse like this:

5.png

6

3. Setup a Build Process

A Build Process is a set of tasks required to compile, test and validate our software project. In the old days all of this was done manually but thanks to solutions like VSTS (and many others on the market) we can automate this task and avoid manual steps. Automation is a powerful way to increase a team productivity and reduce errors. It also enforces a standard process.
Setting up a build process can be long and boring but VSTS is loaded with templates we can use to jumpstart the configuration.

We go in the “Build And Release” section of VSTS and search in the search-box for “core”. Our simple web-app is a ASP.Net Core App and we’ll find the right template for us named “ASP.NET Core”. We choose that template.

8

VSTS will show us a set of steps. The first one that we need to configure is the source of our source code that we want to build. We select VSTS git, our Parrish Shoes project and the master branch.
Since our project is not very complicated all other default values for the other steps are fine.

9.png

Now we need to setup a trigger to start a build every time a commit is pushed in the master branch. We go in the “Triggers” section and check the “Enable continuous integration” option.

15.png

We hit Save & queue to save the configuration and queue a build.

10VSTS gives us the feedback that a build has been queued.

11We can browse the builds and we can see the detail of the work in progress in the running agent. An agent is a server where the build process can be executed. VSTS provides us a default agent with some capabilities but we can create our own to better fit the needs of our complex real-life-company-enterprise project.

12

If the build is OK everything will turn green!
In this simple project we have no tests but the template is already configured to search for tests in our solution: as we can see there is a specific “Test” step.

13We also receive an e-mail as confirmation.14

TL; DR

In this blog post we created a simple .Net Core web-app from the command line and uploaded it to VSTS. That was our starting point to setup a build process that we created leveraging a template found in VSTS. Now our web-app is featured with a CI process that is a very good first step to protect the quality of our source-code.

La frizione implosiva del connettore sdoppiato

Non di rado si assiste alla creazione di un ruolo aggiuntivo nei team Agili che si imbarcano nel lungo e tortuoso cammino della propria evoluzione: si tratta del Team Leader.

Come sappiamo, Scrum, non contempla questa figura specifica, mentre, ad esempio, in Disciplined Agile Delivery è contemplato il ruolo di Team Lead, inteso come colui che supporta il team nella crescita organizzativa e che può assumere anche alcune connotazioni tecniche a supporto (spesso, nei piccoli contesti, il Team Lead è anche l’Architecture Owner).

 

dad roles

DAD Roles

Se si istituisce il ruolo di Team Leader, il focus di chi lo impersona (attenzione alla solita questione ruolovs posizione) è quello di supportare la crescita del teamin chiave Servant Leader, sia in ambito organizzativo che in ambito tecnico.

Operando in quest’ottica, l’approccio permette di creare una figura chiave che diventa un connettoredel team con le diverse interfacce aziendali, andando effettivamente ad accelerare la crescita dell’autonomia del singolo team e creando un ecosistema in grado di operare secondo i più nobili principi agili.

Esistono però tutta una serie di rischi relativi: primo tra tutti, il Team Leader non deve diventare il “capo” del team che dice agli altri cosa fare. Purtroppo, si tratta di una deriva spesso comune, sorretta anche dalla difficoltà dell’organizzazione stessa nell’inquadrare correttamente il ruolo. Se si torna ad operare in chiave command-and-control, il team agile smette semplicemente di esistere, trasformandosi in un insieme di persone a cui vengono assegnate attività che sono definite, decise e strutturate da qualcun altro.

Inoltre, il Team Leader non riesce a “coltivare” la crescita del team, trasformandosi a sua volta in una sorta di “controllore” e “passa carte”, ovvero uno strumento di un’organizzazione strettamente piramidale.

Certo, è possibile avere due figure separate, una per il “Team Leader” e l’altra per Scrum Master/Coach, all’interno di un singolo team, ammesso che questo sia economicamente sostenibile. Il rischio è quello di creare due figure “lead” per il team, generando confusione e anche frizione:chi è più qualificato nel prendere decisioniChi risponde ai quesiti?Chi dirime le controversie tra i due? Insomma, la cosa può funzionare, ma richiede una forte maturità e la capacità personale di capire il proprio perimetro operativo.

InterruptionCop

Nel caso in cui il tutto resti estremamente nebbioso, il rischio è che il team cominci a procedere in modo indipendente, ovvero prendendo decisioni localiper ottenere quanto possibile, senza però preoccuparsi del perché delle cose e, soprattutto, rendendo di fatto il ruolo del Team Lead una sorta di “guscio vuoto”.

Si crea così una spirale implosivache porta ad una rottura di fiducia tra il Lead e il team (eventualmente anche con lo Scrum Master ed il Coach) che a sua volta si trasforma in frustrazione e incapacità di produrre miglioramenti sui diversi fronti. 

In generale, il Team Leader non deve necessariamente essere il “più bravo”, ma deve essere una persona capace di ispirare gli altri e mettersi al servizio del team e dell’organizzazione per generare valore, gestendo rapidamente i rischi, attivando quanto e chi necessario per risolvere gli impediment e celebrando i successi del team.

Il suggerimento è sempre quello di individuare persone che abbiano una spiccata capacità di “guardare agli altri”, con forte esperienza in ambito Agile e che abbia maturato competenze tecniche a differenti livelli tanto da porre la tecnologia a servizio del Business e non piegare quest’ultima in funzione della prima.

E ricordate: si tratta di un ruolo, per cui se la persona candidata/scelta non si trova a suo agio o non è accettata dal team… si può sempre cambiare!

 

Stay tuned J

Il panorama nebbioso della terminologia ambigua

DevOps oppure Agile? Ma sono la stessa cosa? Che c’entra Lean?… il nostro mondo è un mondo che sembra amare la confusione, fattore che, unito alla complessità tipica dei problemi affrontati, porta ad un panorama nebbioso che sembra non diradarsi mai.

La tendenza è ormai ventennale, tant’è che gli stessi autori di Scrum utilizzano spesso la Teoria dei Giochi per descrivere il proprio framework, mettendone in evidenza i principi di equilibrio e muto interesse. Tutto bello, ma possibile che non riusciamo a trovare un modo sintetico per raccontarlo a chi vuole andare diritto al sodo?

Stesso problema per Deploy e Delivery: cosa li differenzia? Da un lato, fino a qualche anno fa, si parlava di Deploy per indicare il rilascio fino agli ambienti di pre-produzione, mentre la Delivery era il rilascio finale in produzione. Ok, ma in fondo cosa cambia da un punto di vista tecnico? Probabilmente ben poco e se si automatizza l’ultimo miglio (dalla Continuous Integration al Deployment in produzione) tendenzialmente niente.

Ecco che quindi oggi, con l’ascesa di DevOps, il Delivery viene ricondotto al più nobile significato contemplato in Lean, ovvero la produzione continua di Valore per il cliente…. interessante, ma… un attimo… ricordiamoci del primo principio dell’Agile:

La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua”

hmmm… praticamente dice la stessa cosa…siamo di nuovo punto e a capo!

Anche le pratiche che vengono definite di DevOps sono riconducibili all’Agile: si pensi alla Continuous Integration, Pratica di Extreme Programming.

Provando a cercare qualche suggerimento in letteratura, un post di Sakshi Gaurav propone una interessante lettura di DevOps rispetto all’Agile, secondo la quale:

            “DevOps è una pratica, laddove Agile è un Processo”

presentando un’infografica che mette a confronto le due affermazioni.

devops to agile infographics

Ora, per quanto è vero che, comunemente, Agile viene associato agli aspetti di sviluppo, mentre DevOps a quelli di rilascio, se si legge il tutto in chiave Lean, dove è importante ragionare in termini di Value Stream e di organizzazione complessiva e non locale, qualcosa sembra non tornare in questo… e anche i framework di Scaling mixano il tutto.
Quindi DevOps non può essere ricondotto solo a “pratiche e tool”, ma ad una visione complessiva che coinvolge anche team terzi (differenti da Dev e Ops) ma comunque funzionali alla creazione di una Soluzione Consumabile, così come enfatizzato da Disciplined DevOps.

La definizione che spesso mi piace utilizzare è che “DevOps è la declinazione più efficace di Lean applicato al mondo del Software”, una sorta di Lean Software Development 2.0, in cui i tool hanno un forte impatto perché ormai maturi a supportare l’automazione dell’ultimo miglio ma il tutto è sempre funzionale ad obiettivi di business. Si parla quindi di Work Center e, in quest’ottica, Dev e Ops sono il fulcro delle attività, con Dev che utilizza gli approcci Agili ben consolidati, estendendoli ad Ops, e Ops che si occupa di creare l’infrastruttura a supporto per il deployment (fino in produzione) e garantire l’affidabilità dei servizi, condividendoli con Dev.

Se poi vogliamo completare il discorso… beh… un po’ di Design Thinking può esserci di aiuto per la fase di Inception e per tirare giù nuove idee e Lean StartUp per validarle velocemente rispetto ai potenziali clienti… ma di questo parleremo prossimamente.

Stay tuned J

La metafora del Mappazzone

Ebbene lo ammetto! Spesso mi diverto a guardare la nota trasmissione televisiva masterchef, non tanto per la gara in sé (a malapena so cucinare un piatto di pasta con il sugo pronto), ma per la capacità dei giudici di creare un’atmosfera che coniuga il momento gioviali all’interno di attività che richiedono forte concentrazione, preparazione e precisione.

In realtà, in masterchef troviamo molti elementi comuni del mondo Agile: timeboxed, capacità di adattamento (es: mistery box), l’importanza fondamentale di lavorare in team (brigate), l’obiettivo ultimo di soddisfare sempre l’utente (i giudici).

Potremmo, probabilmente, immaginare addirittura qualcosa di simile ad un’Agile Masterchef workshop.. e non è detto che prima o poi non lo faremo J

Quello su cui però voglio soffermarmi è un termine, preso in prestito proprio dalla trasmissione in oggetto, che mi è capitato spesso di utilizzare ultimamente nell’azione di coaching, soprattutto quando affrontiamo questioni tecniche inerenti al design applicativo: il mappazzone!

Il termine è usato dallo chef Bruno Barbieri e, come lui lo usa per descrivere un piatto che non ha anima, ma che è semplicemente l’insieme caotico di ingredienti mischiati alla meglio, così lo si può utilizzare per descrivere un cattivo design applicativo.

barbieri mappazzone

Ma cos’è un cattivo design applicativo? E ci mancherebbe altro che, da Coach, non rispondessi “dipende” J, anche se abbiamo a disposizione diverse linee guida: dai principi SOLID, a GRASP e quindi ai Design Pattern e ai concetti di Separation of Concern.

Per scoprire se quanto stiamo realizzando si sta trasformando in un mappazzone, suggerisco spesso ai team di sfruttare approcci come TDD o, se preferiscono qualcosa di meno stringente, Test First Programming, e farsi una semplice domanda: il codice è facile da testare? Riesco a creare uno o più test che mi verificano quanto realizzato in chiave end-to-end?

Ecco, se la risposta a queste domande è tendenzialmente no, stiamo creando un mappazzone!

È sempre interessante riuscire a parlare con i team in modo diretto, trovando formule di uso comune che, con semplicità, apra una riflessione e porti a delle azioni di miglioramento… a mio avviso, un bravo coach si riconosce spesso dalla capacità di sintesi, ovvero di riuscire a esprimere in con poche parole o metafore, concetti complessi, portando il team a farsi delle domande e cercare delle risposte… un po’ alla Lubrano.

Stay tuned J

La dissonanza delle sfere di azioni del valore

Nel precedente post abbiamo parlato del Fattore Canguro, ovvero del fatto che lo Scrum Master è spesso costretto a saltare da un’attività all’altra non potendo garantire l’impegno totale sul proprio ruolo, troppo spesso “non capito”.

Ma anche il Product Owner non vive sempre (o spesso, decidete voi J) momenti felici.

po

Questa cosa può decisamente stupire, visto che il ruolo del PO è ormai universalmente riconosciuto nel mondo agile, indipendentemente dal framework o dalla metodologia che si decide di utilizzare

Troppo spesso, però, il PO viene inquadrato al pari del Product Manager, o ancora peggio del Project Manager, ovvero il garante dei “tempi”: la sua attività primaria diventa quella di riportare al management di livello superiore l’andamento delle attività e preoccuparsi di “assegnare” le cose da fare. Se poi si utilizza un tool per la gestione digitale delle Storie, diventa colui che scrive le storie nel tool…

In tal modo si spoglia il PO della sua attività chiave che, come sappiamo, è quella di mantenere costante il focus sul Valore, supportando il proprio team e l’organizzazione nell’adattamento costante in relazione alle attese degli stakeholder e in funzione del contesto corrente.

po role

Una cosa ben diversa dal “dover guidare” il team nelle proprie decisioni, soprattutto se di carattere prettamente tecnico, appartenendo quest’ultime primariamente alla sfera di azione del team di sviluppo, con l’eventuale supporto di specialist e team esterni.

Ma allora, come rispondiamo a domande come:

  • Ma il PO stima le storie?
  • Il PO può dare suggerimenti tecnici?
  • Il PO può dire di “no” al management?
  • ….

Sono tutte domande che non hanno una risposta assoluta (se si esclude ovviamente quanto specificamente previsto dalla letteratura) ma dipendono, banalmente, dal contesto operativo di riferimento. Prendiamo la prima: se l’intero team ritiene che la stima del Product Owner abbia un “valore” per la Storia specifica, nonostante valga sempre la regola “stima chi fa il lavoro”, non c’è nessuna legge divina che impedisce al PO di effettuare la stima, dotandosi, ad esempio, di un planning poker deck esattamente come tutti gli altri. Non è una scelta che mi piace consigliare e adottare, ma in alcuni contesti può effettivamente aver senso.

Restano però imprescindibili i doveri del PO di accertarsi che quanto si stia realizzando ha un effettivo valore (per il committente così come per il service provider), così come è suo diritto/dovere apportare tutte le modifiche che ritiene opportuno al Product Backlog, possibilmente sempre in maniera collaborativa.

Chiudiamo sottolineando che nche per il PO valgono le stesse identiche considerazioni fatte per lo Scrum Master rispetto alla distinzione “ruolo/posizione”: bisogna avere un ingaggio a tempo pieno sul ruolo per consentire alla Persona di coprirne i diversi aspetti e poter migliorare costantemente nelle proprie attività.

Stay tuned J

Kangaroo Factor: il Fattore Canguro nell’agilità del dualismo Ruolo e Posizione

Se vi siete imbarcati nella lunga strada che porta all’Agilità, e avete deciso di adottare uno dei framework più comuni (Scrum, DA, SAFe, ecc…), vi sarete sicuramente scontrati con un problema estremamente comune in tale scenario: il cambiamento e l’associazione dei Ruoli.

Per evidenziare il concetto, prendiamo come riferimento Scrum che, come ben sapete, prevede tre ruoli fondamentali: Scrum Master, Product Owner e Developers.

scurm roles

Scrum Roles

Quello su cui tipicamente ci sono le maggiori difficoltà, sia da un punto di vista aziendale dell’inquadramento sia nel riconoscerne l’ambito in modo da lasciarlo operare attivamente e full-time rispetto a propri compiti, è il ruolo dello Scrum Master.

Molto spesso non si intende il ruolo dello Scrum Master come un “ruolo”, ma come una “posizione” che viene assegnata al più bravo degli sviluppatori, come se fare lo SM desse potere e rappresentasse una scalata nella gerarchia organizzativa. Si può facilmente intuire come questo porti ad innumerevoli rischi, mettendo in crisi l’adozione del framework selezionato (e prima ancora il percorso di trasformazione Agile) a causa di una serie di disfunzioni primarie:

  • Tipicamente “il più bravo tecnicamente” non è detto che abbia i soft skill (caratteriali) e gli hard skill (know-how agile) necessari… anzi!
  • Se anche le condizioni del punto precedente fossero verificate in positivo, il “più bravo tecnicamente” è tipicamente preso, per la maggior parte del suo tempo, dalle attività di sviluppo e nel relativo supporto ai propri colleghi, occupandosi dell’Agilità nei tempi morti… praticamente mai!

Possiamo sintetizzare il discorso, evidenziando come la disfunzione di avere un ruolo di Scrum Master non ricoperto da una persona dedicata in modo esclusivo (o praticamente esclusivo) attivi il Fattore Canguro (Kangaroo Factor), costringendo la stessa a “saltellare” tra più attività con il risultato di perdere costantemente concentrazione ed eleggere sempre e comunque un ambito di focus primario: tipicamente quello tecnico. In tal modo l’azione di coaching e supporto costante in chiave Servant Leader dello Scrum Master è solo un miraggio, un bell’intento scritto in letteratura.

kangaroo

Fattore Canguro (Kangaroo Factor)

Per essere pragmatici, è comunque doveroso evidenziare come l’associazione del ruolo di SM al technical leader ha dalla sua almeno un vantaggio, ovvero il fatto che gli altri membri del dev team sono generalmente portati ad ascoltarlo, vedendo in lui una figura di riferimento rispetto alle proprie attività.

Il consiglio, in linea con quanto suggerito da DAD (in cui il technical leader è definito Architecture Owner, mentre lo SM assume il nome di Team Lead), è quello di optare per questa scelta solo se il team è di piccole dimensioni, non è necessario confrontarsi con gli aspetti di scaling e anche il progetto è relativamente piccolo.

In tutti gli altri casi, ma direi in generale, evitiamo tale scelta e poniamoci come obiettivo quello di eliminare l’effetto canguro non solo per il ruolo dello Scrum Master, ma per tutte le figure della nostra organizzazione: meglio uno Scrum Master che segue due team (se il problema è economico/giustificativo) che uno Scrum Master allo 0,00001%!

Stay tuned J