From conflict to collaboration through a good (or even not good) backlog en it

“Read the functional analysis,” ‘it is written in the comment on jira,’ ‘why didn't you write it?’ are some of the sentences that gave the figure of communication within a development team. Incidentally (?) the team was composed of sub-teams from different companies. Analysts and developers appeared to be in conflict and, as a result, it seemed impossible to do planning or proceed constructively to resolve difficulties.
Both sub-teams were entrenched behind formalities (e.g., analysis documents) or technical jargon that hid either mutual distrust.

The strategy used to overcome the state of affairs saw the backlog as the central element. The backlog was used, and structured, as a pure communication tool and not as a to-do list, or a list of specifications.

To avoid opening discussions to potentially divisive, if not irrelevant, details, the backlog was generated, on purpose, at a high level, not particularly detailed.
The reason lies in the goal of improving communication. The backlog was used as a diversion, something “third party” that could be attacked without attacking the other parties. Within a few sessions we were able to shift the conversation from the people to the problem, find then, almost unconsciously, the space for collaboration.

Come un backlog, anche non tanto buono, cambia le dinamiche: dal conflitto alla collaborazione en it

"Leggi l'analisi funzionale", "è scritto nel commento su jira", "perché non l'hai scritto?" sono alcune delle frasi che davano la cifra della comunicazione all'interno di un team di sviluppo. Incidentalmente (?) il team era composto da sotto-team di aziende diverse. Analisti e sviluppatori risultavano in conflitto e, come conseguenza, sembrava impossibile fare pianificazione o procedere in maniera costruttiva a risolvere difficoltà.
Entrambi i sotto gruppi si trinceravano dietro formalità (es. i documenti di analisi) o gergo tecnico che nascondevano una reciproca diffidenza.

La strategia utilizzata per superare lo stato delle cose ha visto il backlog come elemento centrale. Il backlog è stato usato, e strutturato, come puro strumento di comunicazione e non come elenco di cose da fare, o di specifiche.

Per evitare di aprire le discussioni a dettagli potenzialmente divisivi, se non irrilevanti, il backlog è stato generato, apposta, a livello alto, non particolarmente dettagliato.
Il motivo sta nell'obiettivo di migliorare la comunicazione. Il backlog è stato usato come un diversivo, un qualcosa di "terzo" che poteva essere attaccato senza attaccare le altre parti. Nell'arco di poche sessioni siamo riusciti a spostare la conversazione dalle persone al problema, trova do poi, in maniera quasi inconsapevole, lo spazio di collaborazione.

Si tratta di un talk frontale, partecipato perché il pubblico viene coinvolto continuamente con domande ed esempi.
La durata può essere personalizzata da 25' a 45'

Organization design creates dysfunctional teams en it

Large companies have departments that deal with organization design. These departments work on organizational charts, processes, and necessary standards and keep them up-to-date with respect to the type of business.
The Agile community has, over time, produced many examples of organizational design to support, if not replace, organization departments, from the famous/famous Spotify model to the more recent practices on Reteaming or Unfix.
All of these practices offer a simplification to organizational design that makes them only applicable in laboratory settings.
One of the aspects that are not taken into account is the HR organization. Referring to Pink or the elements that create motivation is unfortunately not enough. Another greatly underestimated aspect is time; changing teams often is certainly possible, perhaps not on a weekly basis, at the price of reviewing all training and team consolidation practices.
This talk assumes that Agile organizational design practices suffer from a local view of the organization.
I want to demonstrate this assumption by telling what organizational design is, how it is carried out in the traditional and agile sense, why it is contrary to agile logic, and what visible effects it produces in some real examples from our client companies.

Ogni viaggio inizia con il primo passo ma non devi inciampare subito. it en

"Il sopralluogo è il primo momento in cui un qualunque professionista conosce il campo su cui deve operare. Nel mondo delle aziende il sopralluogo è un processo più lungo, l'assessment.
E’ uno dei primi passi da compiere quando un cliente chiede una mano per un cambiamento; quel lavoro che permette di capire dove ci si trova e in quale direzione ci si vorrebbe muovere, per poi scegliere le opzioni disponibili per rispondere alla domanda del cliente. E' il momento cioè in cui davvero si può capire cosa è utile al cliente e cosa si può proporre.
L'assessment basato sui valori agili deve essere un meccanismo di ascolto e di trasparenza che, assieme ad una maggiore comprensione del contesto, serve al cliente come uno specchio per aumentarne la consapevolezza.
Il talk prende spunto da un caso di studio per guidarvi attraverso approccio e strumenti che possono essere utili nella vostra attività di assessment e oltre."

L'Organization design crea team disfunzionali en it

Le grandi aziende hanno dipartimenti che si occupano di organizzazione. Tali dipartimenti lavorano su organigrammi, processi e standard necessari e li mantiene aggiornati rispetto al tipo di business.
La comunità Agile ha prodotto nel tempo molti esempi di disegno organizzativo a supporto, se non in sostituzione, dei dipartimenti di organizzazione, dal famoso/famigerato modello spotify fino alle più recenti pratiche su Reteaming o Unfix.
Tutte queste pratiche offrono una semplificazione al disegno organizzativo che le rende scarsamento applicabili se non in contesti di laboratorio.
Uno degli aspetti che non vengono presi in considerazione è quello dell'organizzazione HR. Fare riferimento a Pink o agli elementi che creano motivazione non è purtroppo sufficiente. Un altro aspetto fortemente sottovalutato è quello del tempo, cambiare spesso team è sicuramente possibile, magari non su base settimanale, al prezzo di rivedere tutte le pratiche di formazione e consolidamento dei gruppi di lavoro.
L'assunto di questo talk è che le pratiche di disegno organizzativo Agili soffrono di una visione locale dell'organizzazione.
Vorrei dimostrare questo assunto raccontando cos'è il design organizzativo, come viene portato avanti in senso tradizionale e agile, perché è contrario alle logiche agili e quali effetti visibili produce in alcuni esempi reali di aziende nostre clienti.

Maturity e dintorni it

A che punto siamo nel diventare Agili? 80%? Meno? Quanto ci manca?
Queste domande, lo sappiamo ormai, sono un pò fuori contesto rispetto al percorso di trasformazione Agile. Il bisogno che esprimono, invece, è chiaro e condivisibile.
Le trasformazioni costano tempo e denaro, oltre che un impegno organizzativo e personale di chi è coinvolto. E' un investimento che ha bisogno di un ritorno, e di un modo per valutarlo.
Diversi anni fa abbiamo iniziato a sperimentare tecniche e processi che consentissero di misurare il percorso e di rispondere al bisogno, più che alle domande.
Abbiamo sperimentato modelli, noti e non, modalità di raccolta dati e di coinvolgimento delle persone con l'obiettivo di provare a misurare il valore della trasformazione.
Vorremmo darvi conto del percorso e di quello che inizia ad assomigliare ad un modello standard, basato sul valore e sugli aspetti di cambiamento. Vi mostreremo come le aziende hanno reagito ai vari esperimenti e come sia possibile misurare la trasformazione.

Every journey begins with the first step, but you don't have to misstep immediately. it en

The inspection is the first moment when any professional knows the field in which they have to work. In the corporate world, the site survey is a longer (usually) assessment process.
It is one of the first steps to be taken when a client asks for help with a change; figuring out where you are and in what direction you would like to move and then choosing the options available to answer the client's question. That is, it is when you can understand what is helpful to the customer and what you can propose.
The agile value-based assessment should be a mechanism for listening and transparency that, along with a greater understanding of the context, serves as a mirror for the customer to increase awareness.
The talk draws on a case study to guide you through approaches and tools that can be useful in your assessment activities and beyond.