Category Archives: Visual Studio

La difficile equazione dell’introspezione adattiva

Quando penso e parlo di DevOps, il mio focus è sempre rivolto al valore nobile della Continuous Delivery: produrre costantemente (e non velocemente!) valore per gli stakeholder, interni o esterni che siano.

Si tratta di temi fondamentali, in funzione della verità assodata che oggi ogni azienda è una software house, ovvero che nessuna organizzazione può fare a meno di un nucleo IT che sviluppa soluzioni abilitanti per il business.

Durante i vari workshop e le azioni di coaching, prima o poi, salta sempre fuori una domanda: “Ma queste cose a loro [ai Manager] verranno dette?” “Faranno anche loro [i Manager] lo stesso corso?

Sembra quasi che i Dev e gli Ops farebbero tutto (poi “tutto” bisogna capire cosa sia) domattina, ma il loro freno sono sempre i responsabili che non vogliono ragionare e investire sulla trasformazione Culturale che io dico, affermo e riaffermo, essere indispensabile. Se non lo si fa, si condanna l’azienda ad una sopravvivenza forzata e non la si mette nella condizione di innovare e guardare ai nuovi traguardi

Poi, però, quando cominciamo a soffermarci sul ruolo che Dev e Ops devono avere in tutto ciò, le facce cambiano espressione: 

Non dovete più ritenervi coder, ma professionisti in grado di usare tecniche e tecnologie innovative per innovare il Business”.

Molte volte si stenta a capire l’importanza di questa frase, perché significa, in soldoni, assumersi responsabilità guardare oltre il proprio monitor.

Eppure, la realtà è così! 

Non esiste il “DevOps Engineer” (si tratta di un Sistemista che sa usare i tool di automazione per il deploy… chiamiamo le cose con il loro nome per favore), ma esiste una organizzazione che abbraccia DevOps (Lean, Agile, quello che preferite) avendo come obiettivo l’Enterprise Agility, ovvero essere in grado di rispondere prontamente al mercato, guardando al proprio interno, ma al contempo contribuendo a formarlo.

Non si tratta più di trovare il programmatore più bravo nello scrivere codice, si tratta di trovare il professionista che sa dove mettere le mani, ma che è in grado di supportare un cambiamento continuo in relazione alle nuove sfide che si presentano.

nerd vs thinker

Bisogna tornare a PENSARE!

I manager non sono persone generalmente “ottuse” e capiscono bene il valore dei diversi elementi di cui discutiamo, solo che anche loro sono trascinati nell’operatività giornaliera e spesso hanno difficoltà a fare quello che dovrebbe essere il loro obiettivo primario: mettere in atto quanto necessario per le prossime sfide, non quelle attuali, perché se siamo in quest’ultimo caso… è già tardi!

In pratica dobbiamo allontanarci dall’idea di essere “macchine banali” e riappropriarci del nostro essere “macchine non banali”, ovvero un giacimento di risorse inesauribili.

Ricordate sempre: il vero valore è nelle Persone e non nel codice scritto!

Stay tuned J

La rilevanza del Piano B

Si è appena chiusa l’edizione 2018 del Coach Camp Italy

Due giornate condite da spunti, riflessioni e discussioni legate alla tematica del Coaching Agile, nel panorama magnifico di Garda e del suo lago. Una grande agorà in cui è stato possibile confrontarsi con gli esperti italiani e non solo (forte la presenza degli omologhi tedeschi).

In particolare, durante la sessione “Resident Coach, Consultant Coach… DOs and DON’Ts”, si è discusso delle azioni che ci si aspetta da un Coach, soffermandosi in modo specifico sulla domanda: “ma un Coach esterno è un Consulente nella tradizionale accezione dell’esperto che deve fornire risposte?”

acci 2018 1

La questione può sembrare solo “filosofica”, eppure ha generato un’ampia riflessione, sintetizzata dall’ottimo Alessandro Giardinache ha evidenziato come, alla fine, i partecipanti abbiano concordato sul fatto che le azioni di un Coach non dovrebbero dipendere dal suo status di dipendente/consulente. Questo perché le attività sono sostanzialmente le stesse: dalla capacità di guida, a quella di supporto e sprono alla trasformazione. Il bandolo della matassa si è sciolto quando è emerso come il problema, in realtà, sia nell’idea che l’agile Coach è un “consulente esperto di Agile” e non un Coach in senso lato che, per definizione, è qualcuno che aiuta gli altri negli specifici ambiti sfruttando le proprie attitudini e conoscenze.

La discussione si è poi estesa, virtualmente, nel pomeriggio con il panel “Be a Coach” in cui ci si è soffermati sulle pressioni che un Coach “interno” può subire quando è rigidamente inquadrato nell’organigramma, cosa che potrebbe pregiudicarne la libertà d’azione in funzione delle dinamiche di management e di “capi” poco inclini agli aspetti tanto cari al mondo Agile (self-organizing team, continuous improvement, fail fast/fail often, ecc).

acci 2018 2

Quanto emerso è che il Coach deve essere capace di creare una forte Empatia con il contesto interessato, e conquistare la necessaria Fiducia per avere un ruolo di leadership nel percorso di trasformazione e rinnovamento.

Molto interessante l’idea del “Plan B”: avere un piano di riserva se non si è messi nelle condizioni di operare in modo indipendente nel proprio ambito professionale. Bisogna sempre essere alla ricerca del proprio State of Flow.

 

Chiudo ringraziando gli organizzatori del Coach Camp Italy 2018 e tutti i professionisti che hanno reso le giornate fruttifere e di indubbio valore.

Stay tuned J

Posting SQL Server notifications to Slack

Introduction Automation, proactive monitoring, repeatability, reducing waste of time and technical debt. This is something you should know about when trying to do some DevOps. Why automation? Because you can reduce technical debt and the number of failures that can happen with a manual interaction. You can create environments using a provisioning procedure without falling […]

ALM DOs & DON’Ts – Definition of done

We all have been in this kind of situation: someone in the team states that a feature is done but in reality there is that little thing to figure out and the coding is completed the day after. Why is that? Because every person has a different definition of done inside his mind. How can […]

Spazio… ultima frontiera…

Persone e Interazioni più che Processi e Tool”, il primo Valore è il punto di partenza di qualsiasi cambiamento che si ispiri all’Agile, Lean e DevOps, e sottende esplicitamente la necessità del cambiamento Culturale come aspetto portante.

Spesso però c’è un elemento che viene dimenticato o sottovalutato, ma che rappresenta un aspetto portante se si vuole promuovere la cultura Team basedalla base stessa dell’agilità: lo spazio fisico di lavoro.

Se ci si riflette per un momento, si riesce subito a capire come spazi adeguatisono essenziali per tutta una serie di motivi: dalla comunicazione diretta(come suggerito dai Principi), alla possibilità di avere i necessari Information Radiator, come la classica Kanban/Scrum Baord, che accompagnano il team nella visualizzazione e gestione dell’avanzamento delle attività.

Ogni team dovrebbe avere la propria area sufficientemente aperta, per comunicare trasparenza e disponibilità verso gli altri, e chiusa quanto basta, per garantire una condizione di privacy e generare il senso di appartenenzaal team.

In pratica, solo varcando la sogliadel working space del team possiamo conoscerlo realmente senza però trasformarci in ospiti indesiderati che vanno ad alterarne le dinamiche naturali.

L’importanza degli spazi è ben evidente in Lean, dove la tecnica/tool delle 5S (Seri, Seiton, Seiso, Seiketsu, Shitsuke) è tra quelle primarie, evidenziando come un’area di lavoro ordinata sia abilitante per poter lavorare in modo efficace ed efficiente. 

poster 5s leanproducts

In questo caso, però, la postazione è più intesa come scrivania personale di lavoro che come area del team. La connotazione più “Agile” è, invece, ben esplicitata in Disciplined Agile, rappresentando uno dei Goal della fase di Inceptiondi DAD: Form Work Environment.

dad goal form work environment

L’attenzione, però, non si limita ai soli ambienti fisici, ma si estende anche alla selezione dei tool e la creazione degli ambienti digitali di lavoro, aspetto fondamentale per introdurre un approccio che guarda a DevOps sin dall’inizio, andando ad abbracciarne le principali pratiche abilitanti come la Continuous Integration e Continuous Deploy o la creazione automatizzata di ambienti consistenti per il testing.

Interessante anche il concetto di “Tailor initial process”, recentemente aggiunto, che nella creazione degli ambienti tiene conto dello specifico lifecycle adottato e della relativa incidenza sul resto (principio “Choice is Good”) 

Tornando agli ambienti fisici, è fondamentale affidarsi ad esperti che vadano a studiare effettive soluzioni di riorganizzazione, tenendo anche conto di vincoli come, ad esempio, la sicurezza delle persone e gli spazi minimi individuali previsti per legge. Fondamentale è ricordarsi di creare, oltre alle aree dedicate ai team, le cosiddette Quite Room in cui potersi “ritirare” per fare delle riunioni che richiedono un isolamento completo e massima concentrazione.

Il tutto non deve mai portare alla creazione di enormi “pollai”, ovvero mega open-space con decine di persone in cui il caos comincerà a regnare sovrano non appena si inizierà a lavorare e comunicare.

 

Stay tuned J

Wrong version of ISDeploymentWizard in SSMS 17.8.1

The problem Years ago, with SQL Server 2016 release, Microsoft came up with a separated brand new version of SQL Server Management Studio. It’s been a happy day for the SQL Server community and database developers. Shortly afterwards, our company started to migrate every instances from older version of SQL Server to the 2016, using […]

How to release a hotfix with pull-request inside VSTS in 3 steps

We all know the situation: the customer finds a critical bug in the latest release and he wants us to release a new version of our application with a fix. How do we handle this situation without breaking our team policies? How to release a specific fix to avoid regression problems? First we need to […]

ALM DOs and DON’Ts – Unit test

A unit test is a runnable piece of code that verifies that another piece of code (called production code) does what it is supposed to do. A unit test has many characteristics and one of the most important is that a single unit test must verify one and only one thing. If a unit test specifies more […]

ALM DOs & DON’Ts – Database source control

The database is a critical part of our application. If we deploy version 2.0 of our application against version 1.0 of our database, what do we get? A broken application. And that’s why our database should always be under source control right next to our application code.

ALM DOs & DON’Ts – Database source control

The database is a critical part of our application. If we deploy version 2.0 of our application against version 1.0 of our database, what do we get? A broken application. And that’s why our database should always be under source control right next to our application code.