Here follow some contributions to the evolution and understanding of Agile values and practices from Kent Beck. Evolution of Agile Values Team vision and discipline over individuals and interactions over processes and tools Validated learning over working software over comprehensive documentation Customer discovery over customer collaboration over contract negotiation Initiating change over responding to change over following a plan You can read more about it in this Forbes article: Innovation: Applying "Inspect & Adapt" To The Agile Manifesto And you can watch this presentation: Startup Lessons Learned The 5th Agile Value ...

Agile Practitioner (practice) is someone who enact the values and principles of Lean and Agile Software Development and enact the practices of  many Lean and Agile methods and frameworks, based on what is best for the specific context, project, team, organization and situation. Agil-ist (ideology) is someone who without distinctions of context or situation take one side and is against the other side, without exceptions. Agil-ist can i.e. take side of  Agile against Waterfall or can take side of one favorite Lean-Agile Framework/Method against the other. Why you shouldn't be an Agil-ist (ideology)? Every value system, like the Agile's ones, are inevitably...

When the basic concepts and practices of Kanban are in place in the team, it is time to look at the whole picture. A general principle WIP limit is a tool to adapt the work commitments to the current whole system bottlenecks/capacity and an help to achieve continuous flow and implement a pull-system. WIP limit, continuous flow, whole system value stream mapping, a pull-system , transparency and visualization and frequent inspections are prerequisites in the sense that they are the means to achieve the goal of: Just-In-Time Production The main WIP to limit All the work done prior to the production use...

I'm reflecting about similarities and differences between Lean and Agile software development to challenge and deepen my understanding and gain new insights. You are welcome to add your comments with more reflections on similarities and differences. My reflections start with this interesting paper about similarities between Lean and Agile: When you’re Agile you get Lean by Charlie Rudd.  And continue with the book  "Prioritize, focus, deliver" by Tomas Björholm and Hans Brattberg from Crisp that name this long list of things that Lean have in common with Scrum and XP: - Prioritization and focus, transparence, high quality, iterative and incremental development, cooperation to...

What are in you opinion the most difficult things in Agile? This is my answer based on  observations in my personal experience: recognizing and accepting reality and uncertainty reducing control and anticipation trusting people achieving transparency practicing respect pursuing mastery How do you answer? See also: The dimensions of Agile Tags :  Team Work | Agile | Lean Agile | Complessità | Traduci al ITALIANO >>>

On doing Agile A genius break the rules to create something unprecedented a fool break the rules to achieve what others do better following the rules while most stand in between searching for a balance On being Agile When someone identify himself with his favorite Agile method or framework risk to became an Agile Religious or an Agile Superstitious and is not Agile See Also: Doing Agile & Being Agile Tags :  Team Work |Agile | Lean Agile | Complessità | Traduci al ITALIANO >>>

When you are doing Kanban and Lean for real, teams know the value stream of the business, the whole work flow and there is in place an end-to-end pull-system from users and customers requests to production When you are doing Scrum for real, teams are continuously inspecting and adapting from coding practices to business and marketing and sales practices When you are doing eXtreme Programming for real, teams are continuously exploring unknowns and uncertainties and you are building people and organization and business capacity to react to unexpected and unpredictable events When you are really Agile, you naturally and instinctively enact...

 We discuss on-line many hours in blogs, forums and twitter. To what degree do we discover something professionally useful and valuable and to what degree are we losing our precious time?   Information sharing proved to be extremely useful and valuable. Instead disagreement and diversity of opinions, that have a great potential for learning new things, very seldom lead to profitable discussions. At least in my personal experience.       Do we know what we are disagreeing about? Paul Graham write:  More often than not, two people arguing passionately about something are actually arguing about 2 different things. Sometimes they...

  We spend many hours in blogs, forums and twitter. How much we really understand each other, behind empathy, sympathy or  antipathy? The surprising hypothesis is that, yes, when we talk about computer programming and software development: we are often talking from different parallel alternative universes and we misunderstand each other because of the topic itself that is complex and slippery (what is called a wicked problem) and because we highly underestimate this complexity.   Really ? Let's start mentioning well known and documented misunderstandings. Martin Fowler about Model View Controller or MVC architectural pattern says "one of the most quoted and most misquoted patterns around". Jeffrey...

Here below follow some common criticisms about certifications that are a little superficial and inaccurate. I'll try to show what I think are the mistakes in those sentences using arguments, facts and evidences. Don't misunderstand me, with this I'm not implying that the opposite sentences are true neither. The goal is to move the conversation a little deeper. Whatever is your opinion, belief, intuition and feeling about Agile Certifications, good arguments, facts and evidences can help everyone to discuss effectively and have a better understanding of the topic. All the certifications are broken Fact: Would you get on a bus where the...

Alistar Cockburn describes in this post  the success of a methodology with the formula: Methodology Success = Project delivered + Staff would do it again In software projects people is a fundamental variable, so here with methodology is not intended say RUP or FDD or say XP or Scrum or Kanban. Instead is intended that A methodology is the conventions the team agrees to and actually follow When the team achieves a methodology success as defined above, it is possible to infer that the team and also the method they used, RUP or FDD or one of the others,  helped the project success. In case...

After hands-on experience with Agile practices, working in Agile environments and attending and speaking at conferences with Agile experts, I have annotated what I think could be the dimensions of Agile that detail and expand the original motto Embrace Change: work begin with respecting people dealing with uncertainty managing the unexpected recognizing the unknowns and accepting what cannot be measured ...

One of the bes computer programming technology conference I've been with lot of international speaker and where you can get a sense of the Scandinavian programmers talent, initiative and innovative spirit. What I've learned and I will try to apply ? Before my memories vanish, let's take a note. Only your mom wants to use your website Keynote from one of the founders of Reedit A success story about the possibilities for an entrepreneur in Internet, limited only by the fantasy The users driven product development (1 year release plans are for dinosaurs doomed...

One of the best Agile Conference of the year as usual, XP Days Benelux. What I've learned and I will try to apply ? I should answer this question and log the answer for every conference I attend. Overall I met two ideas cross different sessions: focus on understanding the problem before rushing to search for a solution don't relay only to intuition to find a solution. look at data and do experiments A War Story of the Rise and Fall of an "Agile" Company Focus on understanding the problem A...

Is there a Kanban process? Here the answer in two interesting post in the kanbandev group. Post from David Anderson: ... Kanban is NOT a software development life cycle or project management methodology! ... Use of a kanban system is not possible  unless there is an existing development process in use. ... The Kanban Method is an approach to change management that employs a kanban system on to an existing process context in order to provoke evolutionary/incremental change. ... There is no kanban process for software development Post from Ron Jeffries: ... I really welcome your coming in with these observations, clarifying that Kanban is not a process, but a way of visualizing...

The   bluepill   of software development: defined process outdated Gant charts procrastination of reality check The   redpill   of software development: empirical process inspect-adapt feedback/control loops continuous reality-checks Choose: http://en.wikipedia.org/wiki/Bluepill or http://en.wikipedia.org/wiki/Redpill Tags :  Team Work | Agile | Lean Agile | Leadership | Team | Progettazione Software | Traduci al ITALIANO >>>

Ho collegato 2 post che ho letto recentemente e... Il primo riporta il risultato di una ricerca secondo cui una coppia in pair "batte" 2 individui se la coppia discute liberamente dei loro disaccordi in particolare di quanto sono confidenti della loro decisione. Mentre la coppia "perde" quando una persona é incompetente su un argomento senza esserne consapevole o senza riconoscerlo. Il secondo riporta il risultato di una indagine secondo cui ogni anno un inglese in media spreca 2000 sterline di carburante perché sbaglia strada e non chiede informazioni. E il 41% dei maschi dopo aver sbagliato strada e dopo ...

A short excerpt from this article here: Tags :  Team Work | Agile | Lean Agile | Leadership | Team | Creatività | Innovazione | Team building |

Traduci al ITALIANO >>> Fear driven programming:  /fɪə(r) draɪvn prəʊgræmɪŋ / noun definition: copy-paste, add a new flag and a new IF, never change/delete code, put new classes in a new project/code repository Treatment: To enable code-base-wide refactoring and deletion of unused code: merge all repos in one repo, replace unnecessary Reflection abuse and replace IoC (and similar) harmful XML Configcopy-paste, add a new flag and a new IF, never change/delete code, put new classes in a new project/code repositorycopy-paste, add a new flag and a...

Traduci al ITALIANO >>> Have you ever happened to walk with one of your friends or your lover. Silently, no need to ask, no need to tell, no need to talk at all, instead just feel that connection, that shared understanding ?  And the simple astonishing joy for been there, in the same place, at the same time, now, together ? If you look at things from the outside, you will * not * notice an action, a word, a sound or a noise. The ingredient that make this moment special, is simply unvisible. I know, is...

Traduci al ITALIANO >>> In the beginning only the Strong Directive Leadership styles was know, then leadership style evolved and now also the Process Leadership style is known. Do you agree with this description of the evolution steps of the leadership style ? Commands: command and control often together with a shared vision and a clear goal Rules: rules proven to be effective by practice, applied with force and flexibility; generative rules ...

Traduci al ITALIANO >>> Here I reflect about two concepts that Agile software development borrowed from Economics. And how they relate to the pit-stop that brought Button to win the Australian GP, and how they relate to the Alonso decision to delay the exit on the track for the Q1 session of the Malaysian GP that brought Ferrari to the early elimination. The concept of irreversibility was explained by Enrico Zaninotto italian professor in economics at the XP2000 conference: decisions the are irreversible, or to much expensive to revert,  are one of the prime drivers of...

Interesting post: 50 Little Things You Can Do to Empower Other People See also Empower del team : Il principio , Esempi , Conclusioni (in Italian) Tags :  Team Work | Agile | Lean Agile | Leadership |

Quali tecniche, quali invenzioni e quali scoperte fanno parte della tua Arte di Programmare? Dargli un nome, renderle esplicite e consapevoli, condividerle e confrontarle è più utile e vantaggioso di quanto potessi immaginare. Comincio con il condividere le mie e aspetto di conoscere nei comments anche quelle degli altri. (((Clicca x leggere)))

Gartner has identified seven properties that differentiate emergent architecture from the traditional approach to EA: Non-deterministic - In the past, enterprise architects applied centralised decision-making to design outcomes. Using emergent architecture, they instead must decentralise decision-making to enable innovation. Autonomous actors - Enterprise architects can no longer control all aspects of architecture as they once did. They must now recognise the broader business ecosystem and devolve control to constituents. Rule-bound actors - Where in the...

Ci sono le aziende che chiudono, quel­le che resistono e quelle che pensano. E che addirittura scoprono che il manage­ment può rivelarsi una risorsa decisiva anche per i Piccoli. Per di più senza biso­gna di assumere e pagare dei manager. Chi l'ha detto che le tecniche più sofisti­cate sono adatte solo alle grandi impre­se? Perché anche le aziende manifatturie­re con meno di 50 dipendenti non posso­no farsi in casa la loro rivoluzione cultu­rale? ... Caron è tutt'altro che pessimista. L'obiettivo è prepararsi per la ripresa e perciò è diventato, parole sue, «un fanati­co della lean production», il modello dell'impresa anti-burocratica alla...

Clicca sull'immagine per la MindMap in formato grande: Fonte:  http://bizdriven.blogspot.com/2009/07/lean-software-development-mindmap.html Gli altri post sul Lean Software Development: http://blogs.ugidotnet.org/luKa/Tags/Lean Agile/ Tags :  Team Work | Agile | Lean Agile | Leadership |

   Tempo fa ho organizzato un meeting su come avanzare l'uso di Scrum (leggi aumentare le chances di successo dei progetti, migliorare le prestazioni del team e realizzare sw realmente utile al business dell'azienda) in una azienda. Nel meeting era necessario dare con trasparenza anche alcuni feedback negativi riguardo 2 cose della implementazione corrente. Mi sono letto e riletto i suggerimenti annotati nei post precedenti. Il risultato? I feedback sono stati accolti, riconosciuti e discussi con interesse. E' stato chiesto di organizzare un altro meeting per proseguire il dialogo e approfondire gli argomenti. E alla fine del meeting invece della sottile tensione...

   In questo post ci sono idee su quando e come dare feedback negativo : Sul dare feedback negativi    Una cosa altrettanto importante é bilanciare il feedback negativo cioé proporre idee di come migliorare, segnalo questi link sul argomento: - Facilitation Antipattern: Negator - il Perfection Game     Qualdo per te l'argomento é importante, comunicalo con urgenza; quando le conseguenze possono essere serie descrivile esplicitamente; quando sei preoccupato, dí come ti senti (il linguaggio del corpo spesso giá parla da se). Funziona meglio di un atteggiamento catastrofista o allarmante. Tags :  Team Work | Agile | Lean Agile | Leadership | Comunicazione |

Un articolo che mi ha fatto riflettere, molto interessante spiega la tesi che spendere il complexity budget sulla Continuous Integration e a cascata TDD ha un impatto positivo sul progetto maggiore che investire su programming languages e frameworks:    Taming the project complexity budget by focusing on continuous integration Quale di queste 2 progetti descritti qui preferisci ? Project is “awesome”, as it uses nice a programming language plus frameworks and tools. Design is “perfect”, methodologies are used...

Un programmatore senior si crea degli spazi sicuri per il divertimento, la scoperta e l'apprendimento di nuove tecnologie[1] all'avanguardia, le pesa le valuta quanto sono stabili e affidabili e dopo le usa sul lavoro solo  dove, quando e quanto sono utili al progetto Un programmatore inesperto usa progetti cliente al lavoro per provare nuove tecnologie che non conosce bene, che non ha provato e valutato a sufficenza, i cui benefici al progetto e alle persone sono poco chiari Sei quello che mangi...

Ho aggiornato la lista di giochi e simulazioni con i nuovi link che ho raccolto utili a definire un buon piano di lavoro per apprendere Scrum e team-work [*]: Qui game/simulazioni: http://blogs.ugidotnet.org/luKa/archive/2009/04/21/comportamenti-che-funzionano-la-pratica-12.aspx Qui coding dojo / kata: http://blogs.ugidotnet.org/luKa/archive/2009/01/22/coding-migliore-lo-stile.aspx _______________________________ [*] Why Role-Plays work to learn Agile   Tags :  Team Work | Agile | Lean Agile | Complessità | Leadership | Team building |

   Per ricordarci quando programmare ci piaceva davvero e ancora, il senso della scoperta e dell'avventura Una storia da non perdere Code Rush:  the commercially-unavailable documentary from 2000 about the open-sourcing of the Netscape code base and the beginning of the Mozilla project. A proposito di Startup 2 link in tema Baltic & Nordic Startup index, Sweden 100 da cui mi annoto queste : - Spotify  (Music biz snapped up Spotify shares - http://www.stardoll.com/ (teenage girl community, 25 million user accounts) - http://www.emotionr.com/ - http://www.bodybug.se/ - http://www.bluewalks.com/ (condividere percorsi di passeggiate) - http://hittatiden.nu/ (fissare un meeting) - http://jalbum.net/ (album fotografici di qualità) Tags :  Team Work |...

Una presentazione interessante di Jeff Sutherland : Shock therapy self-organization in Scrum e qui il video 2 slide divertenti Scrum Sensei When you need me, but do not want me, then I will stay. When you want me, but do not need me, then I have to go. Nanny McPhee The Senior Agile Programmer "Unfortunately, no one can be told what the Matrix is. You have to see it for yourself." Morpheus serve saper essere forti e flesibili con la Shock Therapy  : l'esperienza dello ScumMaster é fondamentale perché serve la certezza della reale utilità nel applicare le regole li, in quel preiciso momento e...

Da Crisp ecco il pdf con le slide  indicato per chi é interessato al percorso di adozione/Uso di metodi Agili Tags :  Team Work | Agile | Lean Agile | Leadership |

One of the Toyota Way principles is « Nemawashi », take decisions by consensus. ... The consensus-building process solicits ideas and review from everyone involved so that the final idea is usually a lot stronger than the original. But there’s one big misunderstanding about consensus. Consensus doesn’t require Compromise Leggi il post : http://blog.nayima.be/2009/06/19/nemawashi-decisions-by-consensus-without-compromise/ Guarda anche: Negoziazione integrativa : nasce dalle differenze Tags :  Team Work | Agile | Lean Agile | Conflitto | Negoziazione | Motivazione | Progettazione Software |

Queste slide sono anche l'occasione per scoprire la storia dell'Agile dalla sua nascita, come è vista l'adozione dell'Agile in italia e perchè e la Tecnica del pomodoro tutta italiana. Ecco le slide di A View on the Future: http://www.crisp.se/futureofagile/slides/davidanderson E qui la presentazione Beyond Agile: Cultural Patterns: http://www.infoq.com/presentations/beyond-agile Tags :  Team Work | Agile | Lean Agile | Pratiche | Leadership | Creatività | Innovazione | Progettazione Software |

Il multi-task nel lavoro delle persone produce più danni che vantaggi. Un dato di fatto chiarom noto e assodato. Compito del Coach, Scrum Master è schermare il team e fermare immediatamente il multi-tasking. Riporto un nuovo post a questo proposito :  Kanban learnings - Running multiple projects hides impediments (da Crisp) 6 months after we began using Kanban to two support / system administration teams they realized that the downside of having multiple projects running outweighed the possible upside. ...

Differenze Iterations - In Scrum you work in iterations, Kanban sees development as a forever ongoing flow of things to do. Commitment - In Scrum team commits to what they will do during a sprint Estimations - In Scrum you must estimate. In Kanban it's optional. Crossfunctional teams - That's one of the pillars of Scrum. For Kanban it's optional. Similitudini Prioritized backlog self-organizing team transparency inspect & adapt pull scheduling ...

Una immagine meglio di 100 parole :) Fonte: http://www.crisp.se/bok-lean-agile-scrum-xp (in svedese) Dalla stessa azienda di Scrum and XP from the Trenches (inglese) Tags :  Team Work | Agile | Lean Agile |

Here is the article on Scrum Alliance site: Scrum Delivers Tags :  Team Work | Agile | Lean Agile | Pratiche |

       Li trovo utili quanto i feedback positivi per avvicinarsi al risultato ottimale Quando darli quando si sperimentano in prima persona conseguenze tangibili e indesiderate che sono la conseguenza diretta di una specifica azione quando ci viene richiesto esplicitamente un feedback in un rapporto di amicizia per una questione importante comunque il più presto possibile cioè il più possibile ravvicinato all'azione a cui...

    Ricapitolando ecco i post sui principi del Lean Software Development: Eliminare gli sprechi : Il pricipio , Esempi , Considerazione finale Amplificare l'apprendimento : Il principio , Esempi , Considerazione finale Ritardare la decisione all'ultimo momento responsabile : Il principio , Esempi , Considerazione finale Rilasciare il più spesso possibile : Il principio , Altre info , Esempi e conclusioni ...

      Questo post Simple Guidelines for Workday Quality Over Quantity [Email] mi ha fatto ricordare un vecchio episodio        Una compagna di team mi fece notare che restando focalizzato sul codice che stavo scrivendo rischiavo di ignorare mail molto urgenti (visto il contesto in cui stavamo lavorando la preoccupazione era legittima)        La mia idea (che avevo mancato di sottoporre e condividere col team) era che per le cose veramente urgenti le persone normalmente usano il telefono: te lo immagini chiamare i pompieri o l'autoambulanza con una e-mail ?               Un processo che investe in questa naturale abilità delle persone è...

Secondo me il punto chiave del settimo e ultimo principo del  Lean Software Development è che per completare con successo progetti complessi, per far crescere un team una organizzazione serve capire le dinamiche con cui i vari componenti in gioco interagiscono, fare attenzione a non confondere il sintomo con la causa, pesare l'effetto di una azione sull'obiettivo ultimo Come ci si sente a spegnere incendi, ampliare i processi e irrigidire l'applicazione delle norme, analizzare scomporre misurare e ottimizzare ?       per esempio una piacevole sensazione di controllo, poi sorpresa quando problemi che sembravano risolti si ripresentano magari in forma diversa e...

Degli esempi dal principio #7 del  Lean Software Development Guarda l'insieme    In una gara di F1 di un pilota può fare uno o più pit-stop. La strategia di gara migliore è quella che lo porta davanti agli avversari all'uscita dell'ultimo pit-stop e non quella che lo tiene davanti a ogni pit-stop     Quando i tempi di sviluppo si allungano o i bug aumentano, la complessità del codice sale o le build si rompono più spesso è utile guardale le cose nell'insieme, capire le...

Lean Software Development descrive principi e pratiche utili a introdurre i metodi agili nella propria organizzazione. E lo fa dal punto di vista del Manager e del Responsabile tecnico di progetto Un principio del Lean Software Development è Guarda l'insieme Guarda alle interazioni e al risultato complessivo che producono, migliorandole complessivamente ottieni benefici maggiori che ottimizzare a singole parti : - gli utenti di una azienda interagiscono con il software e con i colleghi per riuscire nel proprio lavoro...

Secondo me il punto chiave del sesto principo del  Lean Software Development è che per relizzare prodotti software di successo nel tempo serve l'equilibrio tra agire localmente (quando l'utente usa una funzione, fa una richiesta, definisce le priorità e quando il programmatore scrive un test, fa un refactoring, rilacia una funzionalità, fa un test di accettazione) e pensare globalmente (quando si guarda all'intero dominio applicativo, alla evoluzione del prodotto, alla soddisfazione degli utenti, alla economicità delle soluzioni, alla efficenza degli sviluppi, a che direzione strategica prendere) Come ci si sente con un prodotto eterogeneo, parziale, bacato ?       per esempio l'utente si...

Segnalo questa presentazione interessante:   http://www.infoq.com/presentations/poppendieck-agile-leadership Tags :  Team Work | Agile | Lean Agile | Leadership |

Mi annoto da un post interessante come i progetti si concludono prima quando ogni persona/team ne segue uno alla volta    Il punto é decidere dal portfolio dei progetti quale progetto seguire (sino a quando e´prevista la prossima valutazione delle prioritá del portfolio progetti). E metterci il focus al 100% su quel  progetto Make a Real Commitment When you commit to a project, make it a full commitment, meaning that all the necessary people are on the project full time and that they have all the necessary resources they'll need, such as a project room,...

Lean Software Development descrive principi e pratiche utili a introdurre i metodi agili nella propria organizzazione. E lo fa dal punto di vista del Manager e del Responsabile tecnico di progetto Un principio del Lean Software Development è Mantieni l'integrità del sistema Sviluppa ogni programma, funzione, maschera cosi che gli utenti la trovano  semplice, intuitiva, uniforme e consistente Impementa ogni metodo, classe, componente, applicativo cosi che i programmatori lo trovano in condizioni buone  per cambiarlo, correggerlo e...

Il nostro lavoro é quello di programmare computer, la abilitá di scrivere del buon codice é spesso sottovalutata a favore della conoscenza delle tecnologie Un po come fanno gli sportivi e i musicisti il trucco é esercitarsi A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there to have fun and to engage in DeliberatePractice in order to improve their skills: http://codingdojo.org/ Ho partecipato anche a una variante dove tutte le coppie in contemporanea scrivevano codice per poi discutere insieme le diverse soluzioni Update 14 AGO - ThePrimeFactorsKata - TheBowlingGameKata - Groovy Sales Tax Problem -...

Secondo me il punto chiave del quinto principo del  Lean Software Development è che si guadagna di più a investire sulla qualità, sul talento e i punti di forza del team e sulle potenzialità di crescita, sui compiti sfidanti e sulla competizione con i proprio concorrenti mentre si perde a puntare sul risparmio, sul cautelarsi dalle debolezze e le carenze del team e sulla lotta tra colleghi e reparti Come ci si sente a dirigere e controllare il team ?       per esempio con progetti complessi ci si sente sommersi dai dettagli da studiare e dalle decisioni da prendere, caricati di lavoro...

Questo post di PierG dichiara una tra le cose più importanti che ho imparato in questi ultimi tre anni di lavoro: Quando il tuo software si è trasformato in un ammasso di codice legacy, rifarlo da zero probabilmente è la cosa peggiore. Infondo i problemi di quel codice sono comiciati quando il software è stato scritto da zero: perché dovrebbero andare meglio  riscrivendolo da capo ancora allo stesso modo ? In linea con una ipotesi che avevo condiviso qualche tempo fa: Il codice quando è Legacy lo è dal momento stesso in cui viene scritto Il punto è che scrivere...

Degli esempi dal principio #5 del  Lean Software Development Empower del Team Quando recluti persone per il team ingaggia senior in gamba : 2 senior con 1 junior fanno più e meglio di 1 senior con 4 junior Fai attenzione a scegliere persone responsabili di carattere (verso il codice, l'intero prodotto e il team) più gli incoraggi e gli lasci libertà più risultati ti portano Dagli la direzione, tienigli allineati agli obiettivi di business, spronagli alla semplicità...

E' una presentazione davvero bella. Da indicazioni al Product Owner su come esprimere i requisiti e ai membri del team su come raccoglierli/scomporli/ragrupparli al meglio per Produrre il maggior valore di business $$$ Trovare le soluzioni/funsionalità che meglio realizzano l'obiettivo di business Procedere in modo da chiarire sempre meglio quello di cui si ha bisogno Garantire le funzionalità indispensabili al business in...

    Lean Software Development descrive principi e pratiche utili a introdurre i metodi agili nella propria organizzazione. E lo fa dal punto di vista del Manager e del Responsabile tecnico di progetto. Un principio del Lean Software Development è Empower del Team Ingaggia tecnici esperti e fai crescere il team, fallo guidare da un leader tecnico, delegagli responsabilità sfidanti, dagli libertà d'azione e lascia che la partecipazione sia su base volontaria per ottenere i risultati migliori Prendi junior e gente...

  Un Master Developer per un team di sviluppo software e come un direttore d'orchestra ... Alcuni team sono come una Jazz Band e hanno bisogno di una guida che gli incoraggi a improvvisare Altri team sono come un'orchestra sinfonica e hanno bisogno di una guida per andare tutti a tempo seguendo lo spartito Da Lean Software Development Tags :  Team Work | Agile | Lean Agile | Leadership | Team |

     Dal quarto principo del Lean Software Development alcuni esempi che ho preso dal libro Lean Software Development: Rilasciare il più spesso possibile Quando nel mercato qualcuno riusce a ridurre i tempi di consegna i concorrenti si adeguano per recuperare il vantaggio competitivo oppure ... Nel 1971 la Federal Express ha introdotto le consegne overnight dei pacchi. Anche la L.L.Bean si è adeguata e nel 1980 ha introdotto le consegne in giornata mentre la Sears Catalog non lo ha fatto ed è uscita dal mercato ...

   Altre informazioni sul quarto principio del Lean Software Development Rilasciare il più spesso possibile Questo principio è di complemento anche a altri principi del Lean,         ad esempio il #3  Ritardare la decisione all'ultimo momento responsabile  perché senza velocità nei rilasci si è costretti ad anticipare le decisioni per avere più tempo per metterle in pratica        e il #2 perché il feedback che si ottiene con rilasci frequenti è utile ad Amplificare l'apprendimento        e pure il #1 perché ridurre al minimo codice realizzato e non ancora consegnato significa Eliminare uno spreco Tags :  Team Work |...

Lean Software Development descrive principi e pratiche utili a introdurre i metodi agili nella propria organizzazione. E lo fa dal punto di vista del Manager e del Responsabile tecnico di progetto. Il principio #4 del Lean Software Development è Rilasciare il più spesso possibile Cioè riuscire a consegnare in modo affidabile e ripetibile più velocemente aumenta i guadagni e riduce i rischi dell'utente e del team di sviluppo sw Qual'è il tempo minimo (pratiche di coding Agile) che serve al team per produrre qualcosa di valore ? E qual'è il tempo massimo (processo e business) che il Product Owner può...

Secondo me il punto chiave del terzo principio del Lean Software Development è che si fa software più velocemente quando si riconoscono gli istanti di non ritorno e si usano a proprio vantaggio Come ci si sente a cercare di scrivere sw ignorando l'ultimo momento responsabile ?       per esempio ci si sente       tranquilli quando il progetto inizia e il tempo stimato è ancora tutto disponibile,       sorpresi quando le scelte prese danno risultati diversi da quelli che servono,       seccati quando non c'è il tempo per fare le cose in modo diverso come la pratica suggerisce,       preoccupati e rassegnati quando la dead-line si...

Dal terzo principo del Lean Software Development alcuni esempi che ho preso dal libro Lean Software Development: Ritardare la decisione all'ultimo momento responsabile Enrico Zaninotto è l'economista italiano :) che ha mostrato con i suoi studi che quando si eliminano le cose che rendono irreversibile una decisione una volta presa la complessità scende velocemente E ha mostrato che rimandare le decisioni irreversibili a dopo riduce l'incertezza e è una strategia economica conveniente e vincente. Questo è il vantaggio economico che si vuole ottenere dalle pratiche di coding Agile E un po di storia Microsoft. Al Comdex trade Show del...

Lean Software Development descrive principi e pratiche utili a introdurre i metodi agili nella propria organizzazione. E lo fa dal punto di vista del Manager e del Responsabile tecnico di progetto. Il principio #3 del Lean Software Development è Ritardare la decisione all'ultimo momento responsabile Cioè tenersi aperte più possibilità di scelta il più a lungo possibile per decidere dopo aver raccolto più elementi e più fatti concreti. Aspetta a decidere (YAGNI) sino a quando rimandare ancora la decisione eliminerebbe automaticamente  una alternativa importante (Last Responsible Moment)        Usa le pratiche di coding Agile per scrivere  software...

  Secondo me il punto chiave del secodo principo del Lean Software Development è che si realizza software meglio quando si procede per piccoli passi (rilasci, iterazioni, user-story, check-in, cicli red-green-refactor, pomodori) che svelano  le alternative possibili e tentativi che migliorano la comprensione e guidano alla costruzione del software che realmente serve con del codice che tutti capiscono. Come ci si sente a cercare di scrivere sw nel modo giusto al primo colpo ?       per esempio preoccupati per la riuscita o al contrario esaltati dalla difficoltà, incerti sul avanzamento reale del progetto o sulla validità delle scelte fatte di fretta, innervositi ...

Dal secondo principo del Lean Software Development alcuni esempi Amplificare l'apprendimento Quando arrivano nuove tecnologie, quando capita di applicarle per prima volta per quel dominio applicativo dove c'è ancora tutto da scoprire e da inventare, quando serve collaborare e condividere informazioni con altre persone che hanno dei compiti o delle conoscenze molto diverse. Perchè nella scrittura del codice non ci sono i vincoli fisici come nelle altre discipline ingegneristiche il vincolo maggiore è  l'immaginazione, perché il software è che è "facile" da modificare evolvere adattare e personalizzare e questo è importante per l'utente e crea anche la complessità. E...

    Lean Software Development descrive principi e pratiche utili a introdurre i metodi agili nella propria organizzazione. E lo fa dal punto di vista del Manager e del Responsabile tecnico di progetto. Un principio del Lean Software Development è Amplificare l'apprendimento Cioè immaginare le possibili soluzioni e anche le loro varianti e con la pratica imparare scoprire esplorare. Rilasciare spesso e in continuazione, imparare dai risultati delle propria implementazione quando viene usata dall'utente come adattare il software in modo che si dimostri nella pratica ancora più utile all'utente. Tags :  Team Work | Lean Agile | Leadership |

Secondo me il punto chiave è che si può eliminare sempre e comunque e ci si risparmia il costa dello spreco insieme agli impacci che crea. Basta riuscire a imparare o scoprire il modo di farlo, il limite maggiore è l'immaginazione e la convinzione di poterci riuscire. Come ci si sente a vedere uno spreco che continua a ripetersi?  Irritati perché crea fastidi. Tristi e anche demoralizzati perchè si subisce questo problema. Come ci si sente a scoprire uno spreco e riuscire ad eliminarlo?   Soddisfatti perché si vede proprio che si lavora meglio dopo. Più sicuri e confidenti per essere riusciti...

  Dal primo principio del Lean Software Development degli esempi di spreco per ogniuna delle  principali categorie di sprechi Eliminare gli sprechi   Quando si raccolgono dei requisiti che poi restano accantonati per un bel po a prendere polvere è spreco (Partially done work)    Quando viene implementata una funzionalità che servirà dopo ma non subito è spreco (Extra features)    Quando due gruppi si rimpallano un lavoro o un problema...

    Lean Software Development descrive principi e pratiche utili a introdurre i metodi agili nella propria organizzazione. E lo fa dal punto di vista del Manager e del Responsabile tecnico di progetto. Un principio del Lean Software Development è Eliminare gli sprechi Un cliente/utente quando dice che una certa cosa secondo lui   non da più valore   al suo software, programmare quella cosa è uno spreco.  Anche una cosa che   rallenta   lo sviluppo e il rilascio di una funzionalità...

Studiando le dinamiche interne delle aziende con cui evolvono e si trasformano e quelle con cui si innovano si è scoperta l'importanza che hanno le politiche aziendali. Formalizzando matematicamente le politiche di una azienda (vedi Dynamic systems) e usando questo modello in una simulazione al computer si riesce spesso a predire i limiti di crescita determinati dalla struttura stessa di quelle politiche e cioè si riesce a predire i principali ostacoli e le maggiori difficoltà che l'azienda si troverà ad affrontare (vedi il pdf System Dynamics and the Lessons of 35 Years ). Nel momento in cui si raggiungono...

Nel 2002/2003 quando ho cominciato a interessarmi ai metodi agile come XP e Scrum ero molto concentrato su le pratiche   :   sulle cose nuove da scoprire e capire -  sui nuovi strumenti da usare - sulle difficoltà tecniche da superare ( QualityAssuranceAgile#Agile )   In seguito ho iniziato a guardare/vedere la "big picture" ossia sulle pratiche collettive, i processi  e come migliorarli per consegnare più valore all'utente ( QualityAssuranceAgile#LeanAgile )    Per tutto questo -  lungo ? :D - tempo mi è sfuggito ... il primo punto del manifesto agile : le persone e le relazioni tra persone prima che processi e tool A mia discolpa ;-)  come la maggioranza degli sviluppatori sono più TaskOriented...

Ho appena finito di leggere, rileggere, sminuzzare, ricomporre e analizzare articoli sulla differenza tra questi due modi di guidare un team. Metterli a confronto mi ha aiutato a capire meglio il significato di Leadership agile e a chiarire ciò che attraverso l'esempio, l'emulazione e il training on the job di colleghi illuminati ;-) sono riuscito a intuire. Annoto qui i passassaggi chiave a mio avviso. Il vantaggio di una leadership agile è quello di produrre un'organizzazione agile in grado di gestire situazioni estremamente mutevoli, che è in grado di valutare velocemente le nuove condizioni e adattarsi e reagire velocemente per raggiungere i propri obiettivi. Mi fa pensare a...

Nel Corriere di ieri c'è un articolo interessante di Alberoni. Parla di chi non ascolta, non delega, è autoritario o dispotico, non si consulta con i colleghi e con gli esperti, oppure ha una personalità troppo incombente. Ed in cambio ottiene il timore, un atteggiamento servile, il silenzio. Il feedback si spegne e questo porta all'errore. Parla di chi non decide, non vuole correre il rischio di sbagliare, non vuole assumersi responsabilità, ne prendere iniziativa. Ed in cambio ottiene l'immobilità, nessun passo verso la meta,  nessun miglioramento da sedimentare. Parla di chi ascolta troppo, prolunga troppo la mobilitazione, accoglie troppi progetti nuovi, inserisce sempre...

Secondo un sondaggio internazionale della NFI Research 1 azienda su 4 da più valore alla qualità che alla quantità e la domanda di qualità da parte dei superiori è ancora maggiore più di un quarto ha risposto che il loro responsabile da importanza alla qualità prima che la quantità. Qualità e quantità sono due obiettivi in conflitto tra loro la quantità serve a ben poco se la qualità è insufficente a volte è il cliente stesso che preme a discapito della qualità per ottenere maggiori volumi e maggiori velocità ...

Un elenco di caratteristiche comuni ai migliori dipartimenti IT : Alignment with the business Managing change Establishing trusted relationships with vendors and outsourcers Managing infrastructure systematically Assimilating information about new technologies Deriving best practices and lessons learned from...

Annoto alcuni spunti dal pdf segnalato qui da Antonio con l''intento di migliorarmi su questi temi: Fai galleggiare la barca sulla superfice (il flusso di lavoro e i processi) Rendi e mantieni sempre evidente il flusso (del lavoro, del processo) e fa in modo che sia noto ed evidente a tutti attraverso la tua cultura aziendale Crea un flusso che muove insieme materiali e informazioni (per me applicazioni e codice, dati applicativi e conoscenza del dominio) e che lega il processo...