

Pino Decandia
Agile Coach, Agile Reloaded
Milan, Italy
Actions
I like organizations and the complex mechanisms that govern them. From business architectures to processes, from words to behaviors, I deal with business change. As an Agile Coach, I combine the Agile Manifesto principles with specific expertise and experience in medium to significant realities and transformation processes. I am pragmatic and concrete-oriented. I believe that:
- People can change; they do not oppose change but offer their vision. To be respected.
- Needs are the basis of behavior; if I want to help, I must allow them to be expressed clearly. And I must be the first to state my needs.
- Ideological battles are meaningless; it matters more to understand the problem and what can be done to solve it.
Area of Expertise
Topics
From conflict to collaboration through a good (or even not good) backlogenit
“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.
Organization design creates dysfunctional teamsenit
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.iten
"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."
Maturity e dintorniit
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.
Business Agility Day 2024Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top