123 Matching Annotations
  1. Mar 2024
  2. May 2023
    1. ake sure you are mentoring someone, always. Make sure you’re always mentoring others. And I have found that mentoring others gives me new perspectives on things. Because I may be telling them things, but I’m learning a lot while I’m telling them.


  3. Mar 2023
  4. Jan 2023
    1. My takeaways

      why the LS? → conventional structures are either too inhibiting (e.g. presentations, status reports, managed discussions) or too loose/disorganized (e.g. open discussions, brainstorms) → conv. structures fail and generate frustrations → no space for new/good ideas to emerge

      what are the LS? → 33 methods/tools to replace traditional meeting/facilitation structures → aim to include everyone

      for whom? → everyone from C-suite to grassroots organizations

      how? → minimal structure through simple constraints → DOs and DON'Ts

      principles 1. Include and Unleash Everyone 2. Practice Deep Respect for People and Local Solutions 3. Build Trust As You Go 4. Learn by Failing Forward 5. Practice Self-Discovery Within a Group 6. Amplify Freedom AND Responsibility 7. Emphasize Possibilities: Believe Before You See 8. Invite Creative Destruction To Enable Innovation 9. Engage In Seriously-Playful Curiosity 10. Never Start Without Clear Purpose

  5. Nov 2022
    1. Mark: Yeah. And I actually think the Agile revolution in software development is software development catching up to the fact that it’s a writer-ly art. Writers don’t know where they’re going or how they’re going to express it when they start out. Neither, it turns out, does software developers. They can pretend by writing it the first time in a spec language and then coding it and then, checking the specification, then finding out that they’ve written the wrong thing and writing a new specification. That was when I was getting started, the right way to write software.

      Agile software development is akin to the design of the writing process.

    1. engineers and product people just hate working on features “sold” by the sales department without asking them in an effort to meet objectives for bonuses.

      Allmost all corporations isolate sales from development, and that's a root cause of the decline (see Microsoft's dissapointing software products, eg. Teams).

    2. A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves. (Lao Tzu)

      No rulers allowed without a good excuse.

    3. The idea that agile is bordering on micromanagement is not a new one. Mike Cohn

      Mike Cohn (author of the linked page, already annotated as important) is one of the contributors to the Scrum software development method.

    1. It's all about micromanagement. Almost every principle and practice of agile is there to support micromanagement. The daily scrum is about micro-managing the team's daily work plans and making sure that everyone is doing what they say they'll do. Continuous integration is put in place so that the minute some developer screws up and breaks a build, it becomes known. Pair programming is about making sure that programmers don't lose focus, don't goldplate, don't work on only the fun stuff, and that they clean things up. Ah, but who is it that is doing this micromanagement? It's the team. Yes, agile is about micromanagment, but it's about the team micromanaging themselves and for their own benefit.

      Reason why Agile == Micromanagement(!!) BUT performed by the devs themselves.

    1. You can also check out the video below to see how the structure comes together in GitLab. Read more about Agile at GitLab See more information about our Agile delivery solution Build your Agile roadmap in GitLab

      Good read & video on PM with GitLab.

    1. The teams that have worked well are teams where the engineers make decisions about process collectively, and decisions don’t get forced down upon them.

      How Agile does not become micromanagement? Devs take over.

    1. The most significant problem of a code review is asynchronous ping-pong of quite difficult questions/answers. This is inefficient, but also makes people frustrated.

      Indeed it's disheartening to await for a code-review.

    2. A session means there is a one driver — one who types/clicks, and one navigator — navigator tells the driver what to do. The 2 other team members keeps attention, and only when the navigator goes in a wrong direction, then interrupts. Navigator navigates for 3 minutes — really, just 3 minutes, and then rotate.

      Nice terminology for mob-programming: - Friver (the programmer - Navigator (feature owner)

    1. There was just one rule, a quirk that seemed crazy but was vital to the company’s success: No one could keep a record of the factory experiments that were tried and failed.

      Henry Ford had this counter-intuitive rule: experiment, but keep no records of failed ones! But...rigorous science needs explicit description of what failed, and why...how to reconcile?

    1. Simplicity--the art of maximizing the amount of work not done--is essential.

      Nicely phrased!

    1. At Buurtzorg, all new team members take a course called Solution-Driven Methods of Interaction, learning sophisticated listening and communication skills, techniques for running meetings and making decisions, and methods of coaching one another and providing perspective. You might assume that all this is managed through staff functions — the source of capability and power in many Orange and Green organizations. But Buurtzorg’s 9,000 nurses are supported by fewer than 50 staff people. The nurses do their own recruiting and purchasing, contracting for specialized medical or legal expertise when needed.

      Instead of PM staff, train the workers!

    1. How to reveal if developers are micromanaged? Ask the following.How do you handle bugs? Do you handle these as a team or an individual solves them?What’s your on-call policy? Do you have one?Do developers feel in control of the tasks? Do you have clear task scopes?

      Nice Qs no2 to the interviewer (and to the team members!).

    2. What can you use to find out fake agile practices?Ask the following questions:How do you handle bugs? Are bugs resolved as a team or an individual handles them?How often do you release software? What’s your release cadence?Do you have a product owner, scrum masters? How is communication to the client done?What’s your code review process? How many required approvals do you have? What’s the last comment you left on a code review?What’s your take on tech debt? How would you classify tech debt?Tell me more about testing practices. Do you use Sonar or other static analysis tools? Do you use integration, unit tests? Do you have a dedicated team of testers?How do you handle issues? Do you have an issue tracker?

      Nice Qs no1 to the interviewer (and to the team members!).

  6. Sep 2022
    1. Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.
  7. Jul 2022
    1. SAFe: Lean-Agile principles according to the Scaled Agile Framework

      Scaled Agile Framework is an industry proven method consisting of 3 levels. Agile team-level development is the best option for companies looking for a strategy that allows them to effectively deliver quality, fully tested products to their customers. SAFe, short for Scaled Agile Framework, is one of the value-added methods for scaling agile to enterprise level. Scaling a team is the priority of this framework.

  8. May 2022
    1. Any software developer will recognize it, The Eureka Moment. This is when you suddenly see how to solve a particular problem. We have them in all shapes and sizes and at the strangest moments. How does that work in SCRUM and DevOps teams?

      The Eureka Moment in Agile Teams

      Any software developer will recognize it, The Eureka Moment. This is when you suddenly see how to solve a particular problem. We have them in all shapes and sizes and at the strangest moments. How does that work in SCRUM and DevOps teams?

    1. if you are on the job market looking for a team that cares more about being agile than going through the motions to look agile, ask these questions
      1. "Tell me about the last time you refactored a module or class."
      2. "Tell me about the last piece of user feedback that became a feature."
      3. "Tell me about the last feature of yours that got dropped."
  9. Mar 2022
    1. groups, especially if they include nonexperts, are better at making decisions than individuals


    2. family meeting. Following the lead of the Starrs and others, we ask three questions, all adapted from agile: 1) What went well in our family this week? 2) What didn't go well? 3) What will we agree to work on this week?


    3. more agile system, in which ideas would not just flow down from the top but also percolate up


    4. weekly family meetings increased communication, improved productivity, lowered stress and made everyone much happier to be part of the family team


    5. agile development that has rapidly spread from manufacturers in Japan to startups in Silicon Valley. It's a system of group dynamics in which workers are organized into small teams, hold daily progress sessions and weekly reviews


  10. Feb 2022
    1. Google killed SG&E about one year after Stadia launched, before the studio had released a game or done any public work. In a blog post announcing Stadia's pivot to a "platform technology," Stadia VP Phil Harrison explained the decision to shutter SG&E, saying, "Creating best-in-class games from the ground up takes many years and significant investment, and the cost is going up exponentially."

      I suspect Google wanted faster, more measurable results than is possible with game development. There's a reason why tech companies are vastly more profitable than game companies.

      I don't particularly see the shame in changing a strategy that isn't working. As an early user of Stadia I do see the lost potential though, maybe that's where this is coming from.

    1. The waterfall methodology for software development is rapidly losing popularity, while the Agile methodology is increasingly used for software development by companies around the world.

      Important differences between Agile and Waterfall methodology

      The waterfall methodology for software development is rapidly losing popularity, while the Agile methodology is increasingly used for software development by companies around the world.

  11. Nov 2021
    1. Is Agile/SCRUM Modern Slavery? https://en.itpedia.nl/2021/11/30/is-agile-scrum-moderne-slavernij/ What do you say Modern Slavery? Yes, when I first read the Agile Manifesto, I felt an unease. Especially when I also read the 12 accompanying principles. I realize that I am making extreme statements in this article, but they are intended as a mirror and to reflect for ourselves what we are actually doing.

  12. Oct 2021
    1. Avere un limite su ogni colonna ti assicura che gli Item si spostino velocemente da una colonna all’altra, visto che questo è l’unico modo per inserire nuovi Item.

      Quale è il vantaggio principale del #[[WIP limit]] nella metodologia #agilekanban ?

      Sta nel fatto che determinando un numero limite di task da poter inserire nella colonna allora spostare i task da una colonna all'altra (quindi avanzare nello sviluppo) sarà il solo modo per poter inserire nuovi task dal #[[product backlog]] alla board

    2. Il Pull system funziona in modo diverso, ovvero con un limite sul numero di elementi inseribili in ogni singola colonna della board, questo limite viene chiamato WIP Limit, ovvero Work in Progress Limit.

      In che modo differisce il sistema di #pull tra metodologia #agilescrum e #agilekanban ?

      La differenza principale emerge nel fatto che nella metodologia kanban su ogni colonna della board kanban c'è un numero limite di task che si possono inserire, questo numero limite viene chiamato #[[WIP limit]]

    3. La principale differenza è che nel Kanban non esistono le sprint. Il processo di sviluppo è continuo.

      Quale è la differenza principale tra #agilescrum e #agilekanban ?

      La differenza principale è nelle tempistiche dello sviluppo, nella metodologia scrum il processo è di breve durate ed iterativo, in quella kanban invece lo sviluppo è continuo

    4. Per tracciare i progressi si usa una board chiamata Scrum Board, Agile Board o per fare un po’ di casino Kanban Board.Di solito ci sono 4 colonne: To Do, Doing o Progress, Test o QA, Done. La premessa di tutto è che queste due metodologie non sono prescrittive per cui ogni team poi può decidere di aggiungere o rimuovere colonne in base alle proprie esigenze.Il Movimento ideale degli Item sulla scrumboard è da sinistra verso destra, se il movimento è al contrario c’è qualcosa che non va.

      In che modo avviene il tracciamento dei progressi nei progetti di sviluppo, che siano #agilescrum o #agilekanban ?

      Avviene tutto tramite delle board kanban divise in colonne e in cui si deve passare da sinistra a destra.

    5. Questa parte è il Pull di cui stavamo parlando prima, ovvero gli item vengono “tirati” dal backlog e non “pushati” da qualcun altro.

      In cosa consiste la parte #pull delle metodologie #agilescrum e #agilekanban ?

      Essenzialmente si riferisce all'atto con cui i team prendono dal #[[product backlog]] i task su cui si devono concentrare e non vedono questi task essere imposti loro dall'alto e/o qualcuno di esterno.

      Compito di #[[product owner]] e #[[scrum master]] è quello di fare di tutto per permettere al team di concentrarsi sullo sviluppo ed implementazione, nel minor tempo possibile e maggiore efficacia, sui task che sono stati inseriti nello #[[sprint backlog]]

    6. Quello che accade tra il product backlog, ovvero la mega-lista di cose da fare, e il customer, ovvero l’utente che userà il tuo prodotto, è quello che distingue Scrum da Kanban.

      Cosa sono, in una frase, le metodologie #agilescrum e #agilekanban ? Che funzione assolvono?

      Essenzialmente portano tutto quello che c'è nel #[[product backlog]] da quella lista al customer.

    7. Alcune caratteristiche del Product Backlog:Ogni Item in Backlog deve aggiungere valore all’utente finaleIl Backlog deve essere ordinato e prioritizzatoIl Backlog è un documento vivente. Il processo di revisione e modifica giornaliera del Backlog da parte del Product Owner si chiama Backlog GroomingI dettagli di ogni Item dipendono tipicamente dalla loro posizione sul Backlog: in alto tanti dettagli, in basso pochi dettagli.

      Quali sono alcune caratteristiche fondamentali del #[[product backlog]] ?

      L'atto di pulizia e aggiornamento del backlog è definito come #[[backlog grooming]]

    8. Il Product Backlog è  la lista prioritizzata di tutto ciò che si vorrebbe fare (occhio a queste due parole!) all’interno del progetto. Qui sta una delle prime intuizioni semplicissime, ma geniali, dei due metodi.Il fatto che un Item sia in backlog non vuol dire che verrà sicuramente affrontato, sviluppato e rilasciato.

      Cosa è il #[[product backlog]] e cosa è presente al suo interno?

      Si tratta di una lista prioritizzata di tutto quello che si vorrebbe fare all'interno del progetto.

      Importante è l'aspetto del "si vorrebbe", il fatto che qualcosa sia in backlog non significa necessariamente che sarà poi sviluppato e rilasciato.

      All'interno di questo backlog si possono trovare #userstory oppure task tecnici oppure bug oppure knowledge task.

    9. Secondo i principi dell’Agile, come abbiamo visto nel post precedente, il software viene consegnato al customer in piccoli pezzi che incrementano il valore del software progressivamente, inoltre il feedback dal customer viene preso costantemente in considerazione e diventa parte essenziale del ciclo di sviluppo.

      Quale è la differenza principale tra metodologia #waterfall ed #agile ?

      La differenza principale è nelle modalità di rilascio del prodotto: nella metodologia waterfall il rilascio avviene interamente e di blocco, nel caso invece di agile il rilascio avviene in fasi iterative e frequenti, piccoli rilasci e implementazioni ad ogni fase.

      Nel metodo agile, ad ogni iterazione, il #[[product owner]] raccoglie i feedback di utenti e stakeholder e le utilizza per le prossime iterazioni, inserendole nel #[[product backlog]]

    10. n una cascata (waterfall), infatti, l’acqua cade sempre dall’alto verso il basso e così funziona nello sviluppo software Waterfall:Il responsabile di prodotto definisce i requisiti di tutto il progettoIl team di sviluppo realizza il progetto per interoIl progetto viene consegnato al customer tutto in una voltaTutto va nella stessa direzione. Dall’alto verso il basso. Sempre

      Come è caratterizzato il metodo #waterfall di sviluppo?

      È il metodo classico di sviluppo, in maniera unidirezionale il responsabile di prodotto #[[product owner]] fornisce agli sviluppatori i requisiti di tutto il progetto, questi li implementano per intero, l'intero progetto viene fornito ai consumatori in un'unica volta.

    11. “concretizzazione” dei principi dell’Agile nelle due metodologie più diffuse, ovvero Scrum e Kanban, esplorandone le principali differenze.

      Cosa sono le metodologie Scrum e Kanban?

      Si tratta di due metodologie che rendono concreti i principi alla base dell'Agile.

    1. Nell’esempio di Giuseppe potremmo chiamare la nostra Epic “Funzionalità di login”. All’interno di quest’ultima andremo poi a inserire le varie User Stories come “Frontend – processo login”, “Backend- processo login”, “Processo di recupero password” e così via fino ad aver completato la nostra funzionalità di login.Per non perdere di vista le varie Epic, andiamo a nostra volta a raggrupparle all’interno di “iniziative”. Tornando al nostro esempio possiamo chiamare la nostra iniziativa “Sito e-commerce – primo rilascio”. All suo interno inseriremo tutte le Epic che riteniamo indispensabili per il rilascio del nostro sito.”

      In che modo si può risolvere il problema della mancanza di contesto per le #userstory ?

    2. Uno dei problemi nell’uso delle User Story è la mancanza di contesto attorno alla storia. Esistono diversi stratagemmi per risolvere.

      Quale è il problema maggiore che emerge dall'utilizzo delle #userstory ?

      La mancanza di contesto, questa rende difficile sia l'empatizzare con l'utente sia avere chiaro l'obiettivo e la natura delle implementazioni.

    3. Questi sono dettagli che vanno aggiunti all’interno della User Story, solitamente si definiscono Criteri di Accettazione. I Criteri di Accettazione sono fondamentali anche per poter verificare se la funzionalità sviluppata rispecchia ciò che era stato deciso. Vi accorgerete che il 90% delle volte ciò che viene implementato non rispecchia quanto era previsto!

      Una volta create le prime #userstory cosa deve accadere secondo la metodologia di #agilescrum ?

      Avviene una riunione con il team di sviluppo, una riunione in cui insieme al team si stabiliscono dei criteri minimi che l'implementazione dovrà rispettare.

    4. Il formato tipico delle User Story ci impone di fare una scelta e decidere le priorità. Quando scrivete una User Story focalizzatevi sempre sulla funzione più importante. Scrivete User Story separate per dettagliare i bisogni differenti. Può creare ridondanza ma vi permetterà di condividere con chiarezza quali sono le priorità.

      In che modo fare #userstory ci permette di determinare delle priorità nella creazione del #prodotto ?

      Ogni user story deve essere focalizzata su una sola cosa, un solo tipo di utente, un solo obiettivo, una sola azione ed in questo modo dovremo scrivere diverse user story per ogni caso, poi tra le diverse user story stabilire delle priorità ed un peso.

    5. Come prima cosa descriviamo quale utente stiamo servendo. A prima vista si potrebbe pensare che l’utente è unico per un prodotto. In realtà ogni prodotto ha una varietà di utenti con diversi intenti.In un e-commerce possiamo sicuramente distinguere tra utenti alla prima visita, utenti registrati, utenti che hanno fatto 1 o più acquisti, e così via. Inoltre molti prodotti hanno alle spalle un servizio e spesso una parte dello sviluppo è dedicata ad utenti interni come per esempio il servizio clienti.

      Quanti utenti e quali utenti possiamo distinguere normalmente in un #prodotto ?

      Ci sono tanti utenti ad utilizzare un prodotto ognuno contraddistinto da diversi intenti

    6. Le User Story hanno solitamente il seguente formato:Come [descrizione dell’utente], voglio [funzionalità o azione] in modo che [obiettivo o valore per l'utente].

      Quale è un esempio di #userstory nella metodologia di #agilescrum ?

      Una. volta compilato, questo esempio dovrebbe essere qualcosa di questo tipo: "Come utente registrato voglio poter effettuare il log-in in modo che posso accedere alle mie informazioni personali. "

    7. L’utente a cui ci stiamo rivolgendoil bisogno che vogliamo soddisfareil motivo per cui dobbiamo soddisfarlo. Un po’ di esempi pratici renderanno tutto molto più chiaro!Ma, prima di partire con gli esempi, voglio dirvi quali sono per me le 2 caratteristiche essenziali delle User Story: chiarezza e confronto.

      Quali sono le caratteristiche alla base delle #userstory ?

      Ogni #userstory deve descrivere in maniera fondamentale l'utente a cui ci stiamo rivolgendo, il bisogno che questo utente ha e che noi vogliamo soddisfare ed il motivo per cui dobbiamo e vogliamo soddisfarlo.

    8. Il concetto più interessante che introducono le User Story è quello di mettere l’utilizzatore del nostro prodotto (lo User) al centro dell’attenzione durante il processo di sviluppo. Pari importanza è data anche all’identificazione del bisogno che ogni funzionalità promette di soddisfare (la storia).

      Cosa sono le #userstory e perché è importante utilizzarle come alternativa alla classica requisitazione?

      Le #userstory contribuiscono a mettere lo user al centro del percorso di sviluppo, inoltre attraverso una storia forniscono anche l'identificazione dei bisogni di questo utente e come ogni funzionalità possa essere capace di risolvere questi bisogni.

      Queste sfumature si perdono nel corso della classica requisitazione in cui il #productowner fornisce requisiti ai tecnici senza nemmeno spiegarne il motivo.

    9. Mi piace molto la definizione di User Story di Mike Cohn: ogni User Story è la promessa di una conversazione. Per Mike quello che c’è scritto nella User Story non è molto importante, è solo un promemoria per innescare una discussione con tutto il team.

      Quale è la definizione di #userstory ?

    1. Lo Sprint inizia con lo Sprint Planning dove il Product Owner prioritizza il Product Backlog ed insieme al team crea lo Sprint Goal, ovvero l’obiettivo da raggiungere per la Sprint in partenza.

      Da cosa inizia lo #sprint all'interno della metodologia di #agilescrum ?

      Tutto inizia dallo #sprintplanning in cui il #productowner analizza le diverse #userstory e attribuisce loro gli #storypoint.

      Dopo l'effettiva esecuzione dello #sprint allora avviene la fase si #sprintreview in cui insieme agli stakeholder si analizza quanto fatto ed il #backlog mettendolo in discussione per le prossime iterazioni.

    2. In alcuni casi viene anche chiamato Agile Coach. Lo Scrum Master è colui/colei che si adopera per far si che il team raggiunga la massima produttività ed efficienza. È il facilitatore di tutte le cerimonie Agile tramite tecniche di negoziazione e mediazione.È anche la voce del team di sviluppo. Chi promuove la metodologia Scrum e fa sì che i suoi principi/valori vengano applicati in maniera corretta tramite un durissimo lavoro di coaching e mentoring. Lo scrum master si occupa anche delle metriche di avanzamento per fare venire a galla i problemi, ma anche i successi del team. 

      Chi è lo #scrummaster e cosa deve fare nel corso della metodologia #agilescrum ?

      All'atto pratico è colui che si occupa di spingere il team a raggiungere la massima produttività ed efficienza. Cerca anche di definire e raggiungere le metriche di avanzamento per far emergere problemi e successi del team.

    3. È colui/colei che guida il team nella giusta direzione, che prioritizza le user storiy e come un direttore d’orchestra si interfaccia con gli stakeholders e col team per far in modo che tutto funzioni alla perfezione. 

      Chi è il #productowner cosa fa e in che modo opera nel corso della metodologia #agilescrum ?

    4. Le skills/conoscenze individuali devono essere trasferite al team tramite peer programming (sviluppo di una funzionalità a due mani) o mob programming (sviluppo a più mani). Questo porterà il team nel lungo periodo ad essere molto più efficiente, dato che ogni membro del team avrà come bagaglio la conoscenza del prodotto e del software utilizzato e potrà essere intercambiabile.Tipicamente un team cross funzionale è composto da Product Manager, Design, Sviluppo, Data Analysis.

      In che modo è strutturato il team cross funzionale che lavora in uno #sprint ?

    5. È un momento di ispezione per tutti, per i processi, per le persone e per il modo in cui si lavora. Qui si ispeziona quel che è stato fatto chiedendosi:Cosa è andato bene?Cosa potrebbe andare meglio?Quali sono gli improvement / miglioramenti che si possono implementare nel prossimo Sprint?

      In cosa consiste la #sprintretrospective nel metodo #agilescrum e cosa accade?

    6. L’incremento, ovvero la somma delle funzionalità che si sono sviluppate durante lo sprint vengono finalmente mostrate al cliente e ai più importanti stakeholders del progetto. Qui si riceve il feedback che porterà a decidere quale corso il prodotto deve prendere e quali user story saranno prioritizzate nel prossimo sprint.La Sprint Review non è solo una Demo, ma è l’elemento di raccordo con la Sprint precedente: un incontro fondamentale su cui costruire la cultura, creare prodotti migliori e rinforzare la fiducia del team.Queste sono alcune delle attività:Definire cosa è stato completato e cosa no, commentando il lavoro.Demo individuali Rivedere impatto delle feature su Metriche ChiaveVerifica User Story e aggiunta nuove per completareBacklog Grooming

      In cosa consiste la #sprintreview nel modello #agilescrum e cosa accade nel corso di questa ?

    7. La cosiddetta stima dell’effort è un concetto fondamentale, specie nel Backlog Refinement e in Sprint Planning dove il team di sviluppo si riunisce per dare un valore numerico alle user stories. Questo aspetto non è assolutamente da sottovalutare, perché dalla stima delle user story possono scaturire tantissime discussioni interessanti per capire effettivamente il grado di rischio, complessità, fattibilità di ciascun task.L’estimation a differenza degli altri rituali non ha una sua precisa collocazione, può essere fatto in qualsiasi momento, ma considera che il Team dovrebbe dedicare al meno il 10% del suo tempo alla stima del lavoro necessario per sviluppare una User Story.

      In cosa consiste il rituale di #estimation in #agilescrum ?

    8. Lo Sprint Planning è forse uno dei meeting più importanti nelle cerimonie Agile ed è il momento in cui business (product owner) e technical team si riuniscono per decidere cosa faranno nella prossima iterazione/sprint. Di solito dura circa 4 ore ed avviene il giorno prima dell’avvio della sprint.L’obiettivo dello Sprint Planning è proprio quello di pianificare la Sprint definendo l’Outcome (L’obiettivo di sprint) e passando dalle user story alle singole task per ciascun componente del team.

      In cosa consiste il rituale dello #sprintplanning nella metodologia #agilescrum ?

    9. il daily scrum è un meeting giornaliero dove il team si riunisce e raccoglie le proprie impressioni su come sta andando lo Sprint e quanto ci si sta avvicinando o allontanando dallo Sprint goal. Ogni membro deve rispondere a tre domande ben precise:Cosa ho fatto ieri?Cosa ho fatto oggi?Ci sono impedimenti che stanno bloccando il mio percorso nel raggiungere lo Sprint Goal?

      In cosa consiste il rituale del #dailyscrum nella metodologia #agilescrum ?

    10. Daily Scrum: allineamento giornaliero Sprint Planning: preparazione della SprintEstimation: stimare il peso di ogni user storySprint Review: demo e review del lavoro svoltoSprint Retrospective: migliorare il modo in cui si lavora insieme.

      Quali sono i rituali alla base della metodologia #agilescrum ?

    11. Man mano che passano le sprint il team di lavoro acquisirà il proprio ritmo, “heartbit” o velocità.La Velocity è la somma degli story point completati a fine sprint. Questa servirà da metro di paragone per pianificare gli Sprint successivi.Facendo un passo indietro infatti ogni User Story prima di essere portata in sviluppo deve essere analizzata e ne deve essere valutato il peso in termini di impegno del team.Es: una User Story che pesa poco impegna solo alcuni membri del team (anche uno solo) per poco tempo, una Storia che pesa molto impegna tanti membri del team per tanto tempo.Solo dopo aver dato un valore ad una User Story usando appunto gli Story Points, questa può essere aggiunta allo Sprint Backlog.

      Cos'è il concetto di #velocity nella metodologia #agilescrum ?

      È il quantitativo di #storypoint accumulati dal team nel corso di uno #sprint.

      Ogni #userstory infatti avrà un peso e valore determinato dagli #storypoint e deciso in funzione dell'impegno di sviluppo che richiede per la sua produzione.

      La #velocity permette di avere una metrica per pianificare i prossimi #sprint anche in funzione dell'#heartbit raggiunto dal team dopo alcuni #sprint.

    12. La User Story è la funzionalità o l’incremento di prodotto che si vuole portare in sviluppo scritta dal punto di vista dell’utente. Ogni User Story incorpora al suo interno CHI beneficerà di quella funzionalità, COSA si richiede e PERCHÈ è importante per l’utente

      Che cos'è una #userstory nella metodologia #agilescrum ?

      Si tratta della funzionalità o incremento che si vuole portare in sviluppo, scritta dal punto di vista dell'utente. È parte fondamentale del #productbacklog ed in essa deve comprendere:

      • CHI trarrà beneficio dall'incremento?
      • COSA sarà l'incremento?
      • PERCHÈ è importante per l'utente?
    13. Il backlog è la lista di user stories o task che non è ancora stata introdotta nello Sprint e risiede in uno spazio apposito. Considerala come una wishlist di funzionalità che potrebbero essere implementate e che saranno prioritizzate dal product owner durante lo Sprint Planning.

      Cos'è il #productbacklog nella metodologia #agilescrum ?

      È la lista di #userstory e task che non è ancora oggetto dello #sprint in atto, è una wishlist più che una tasklist

    14. Anche chiamato “iterazione” è un lasso di tempo che può variare da uno a quattro settimane dove il team si adopera per creare un “incremento”, un prodotto/funzionalità, anche non finito, che crea valore e che può essere ispezionato alla fine, ricevendo feedback positivi/negativi dagli stakeholders interessati.Nello Sprint si usa il concetto di time-box, dove all’inizio del progetto si decide quanto l’iterazione debba essere lunga (da una a quattro settimane, non di più)

      Cos'è lo #sprint nella metodologia #agilescrum ?

      È il lasso di tempo in cui il team lavora per arrivare ad un incremento nel prodotto, questo incremento servirà a creare valore per gli utenti e sarà ispezionato alla fine dagli stakeholder interessati tramite #feedback negativi o positivi

    15. Agile Scrum è a tutti gli effetti un sistema di regole, procedure e rituali ben definiti su come applicare la metodologia Agile, dove, come ho detto qualche riga prima, il tempo è l’elemento più importante.A scandire il tempo in Agile Scrum ci pensano gli Sprint, dei piccoli time-frame in cui il team di sviluppo lavora per il rilascio di una o più funzionalità.

      Quale è la variabile più importante della metodologia #agilescrum ?

      È sicuramente quella del tempo, rappresentata dallo #sprint che è un piccolo time-frame in cui il team di sviluppo lavora per rilasciare una o più funzionalità.

      Ogni sprint avrà come obiettivo il rilascio di specifiche #feature del prodotto e queste avranno come specifica funzione il dare valore all'utente che usa il prodotto.

      Non si tratta solo di suddividere il lavoro ma di impostare l'intero lavoro in funzione dell'utente, cercando di stargli più vicino possibile.

    16. Nel rugby, la parola “Scrum“ è un termine usato per spiegare il goal del team di ottenere il possesso della palla in quanto unità molto coesa. In maniera simile, in Agile Scrum, il team di sviluppo lavora insieme per raggiungere uno o più obiettivi alla fine dello Sprint/iterazione. 

      Quale è la definizione di #agilescrum ?

      Con questa metodologia si intende far focalizzare tutto il team ad un singolo obiettivo che sarà utile per lo #sprint previsto.

    17. Qui di seguito ti riassumo quali sono i punti chiave:Accettare l’incertezza e tutto ciò che ne derivaIl fallimento è la via più sicura per imparareSe non lo misuri non lo saiFiducia nelle persone e nella loro capacità di avere impattoOwn your Outcome: assumersi la responsabilità a tutti i livelli

      Quali sono gli assunti fondamentali del mindset #agile ?

    18. fino a quel momento tutta l’attenzione nel processo tradizionale di sviluppo software, chiamato Waterfall, era stata posta su documentazione, processi e specifiche tecniche, adesso la lente si spostava sulle persone e sulle interazione tra di esse, sui team e sul loro spirito di adattamento e risposta al cambiamento.

      Quale è stata l'innovazione più grande apportata dalle metodologie #agile rispetto alle vecchie metodologie #waterfall ?

      La principale differenza è che si è cominciato a ragionare sulle persone che effettivamente creano il prodotto, sulle interazioni tra loro, sui team ed in che modo si risponde al cambiamento, non ci si concentra sui task da vomitare in testa ai tecnici.

  13. Sep 2021
    1. All too often a Sprint Review is nothing more than a team saying they did a bunch of stuff with no actual feedback happening. The same can be said of Retrospectives, where the team produces many stickies, but no change manifests. The Daily Scrum Is a daily feedback mechanism, but all too often reduced to merely a task status update.

      Seems to be a pretty common pattern ... :/ I observe it, too, all day. And I wonder how to change that. Every time we decide to talk about obstacles and challenges instead of just give a status update in the daily we don't do it at the end. In reviews we hardly get any feedback. This is not just not agile but de-motivating as well. And then I realize, that we are not in a lifecycle state where Agile is the right framework for us ...

  14. Jul 2021
  15. May 2021
    1. Agile as a methodology is designed to be adaptive to multiple conditions and drivers to enhance the speed of delivery, but it is most successful when the organisation adopting it understands its own in-built cadence, i.e. its specific rhythm of project delivery.
  16. Apr 2021
    1. Coordination: More environments require more coordination. Teams need to track which feature is deployed to which environment. Bugs need to be associated with environments. Every environment represents a particular ‘state’ of the codebase, and this has to be tracked somewhere to make sure that customers & stakeholders are seeing the right things;

      Try to remember the last time you heard one of the following phrases:

      • "Oh, I deployed it in the X environment"
      • "It was working in the stage environment"
    1. Bring up the board that shows the status of every item the team is working on.Starting in the right-most column, get an update for each ticket in the column.Be sure to ask: “What’s needed to move this ticket to the next stage of progress?”Highlight blockers that people bring up and define what’s needed to unblock work.Move to the next column to the left and get updates for each ticket in that column.Continue until you get to the left-most column.

      Format of "walk the board" daily standup

    2. More people brings more status updates.More updates mean more information that others won’t care about.The team may be working on multiple projects at once.If the team has customers, ad-hoc work will regularly come up.

      Problems of dailies when more people show up

    3. I start thinking about my update to prove I should keep my jobPeople zone out when a teammate starts talking about how they worked on something that doesn’t affect me.It’s finally my turn to give an update. No one is listening except for the facilitator.We go over our time and end when the next team starts lurking outside the room.

      That's how a typical daily usually looks like

    4. What did I complete yesterday that contributed to the team?What do I plan to complete today to contribute to the team?What impediments do I see that prevent me or the team from achieving its goals?

      3 questions to be answered during a daily meeting

  17. Mar 2021
    1. The number one problem that I see developers have when practicing test-first development that impedes them from refactoring their code is that they over-specify behavior in their tests. This leads developers to write more tests than are needed, which can become a burden when refactoring code.
  18. Feb 2021
  19. learning-oreilly-com.ezproxy.sfpl.org learning-oreilly-com.ezproxy.sfpl.org
    1. One of the most misunderstood quotes in history is attributed to Field Marshal Helmuth von Moltke, the Elder: “No battle plan survives contact with the enemy.” Ever since, this statement has been taken out of context as a justification for no planning at all—the complete opposite of its original intent. Von Moltke, known as the architect of the Franco-Prussian War of 1870, was a military planning genius credited with a series of stunning military victories. Von Moltke realized that the key to success in the face of rapidly changing circumstances is to not rely on a single static plan. Instead, you must have the flexibility to pivot quickly between several meticulously laid-out options.
    1. Programming to interfaces is at the core of flexible structure.
    2. Rather than implement features you might need, you implement only the features you definitely need, but in a way that accommodates change. If you don't have this flexibility, parallel development simply isn't possible.
    3. At the core of parallel development, however, is the notion of flexibility. You have to write your code in such a way that you can incorporate newly discovered requirements into the existing code as painlessly as possible.
    4. many successful projects have proven that you can develop high-quality code more rapidly (and cost effectively) this way than with the traditional pipelined approach
  20. Dec 2020
    1. As facilitators, scrum masters act as coaches to the rest of the team. “Servant leaders” as the Scrum Guide puts it. Good scrum masters are committed to the scrum foundation and values, but remain flexible and open to opportunities for the team to improve their workflow.

      [[scrum masters are facilitators and coaches]], they understand

      • [[scrum fundamentals]]
      • [[scrum values]]

      While [[agile is a mindset]], [[scrum is a framework for getting things done]]

  21. Nov 2020
    1. Third, you can create value in any span of time. If we see our work as creating these intermediate packets, we can find ways to create value in any span of time, no matter how short. Productivity becomes a game of matching each available block of time (or state of mind, or mood, or energy level) with a corresponding packet that is perfectly suited to it.

      The Intermediate Packet approach ensures you are delivering value after every iteration, regardless of size

      You no longer need to rely on large blocks on uninterrupted time if you focus on delivering something of value at the end of each block of time.

    1. Scrum-Based Learning Environment: Fostering Self-Regulated Learning.

      Linden, T. (2018). Scrum-Based Learning Environment: Fostering Self-Regulated Learning. Journal of Information Systems Education, 29(2), 65–74.

    1. An Agile Framework for Teaching with Scrum in the IT Project Management Classroom

      Rush, D. E., & Connolly, A. J. (2020). An Agile Framework for Teaching with Scrum in the IT Project Management Classroom. Journal of Information Systems Education, 3, 196.

  22. Oct 2020
  23. Aug 2020
    1. "Off-line" vs "On-line". The RAT's focus is to get to a final state, and then ship it, all at once. During the working process, the thing we're working on is "off-line". It's not in the field and no one is using it

      This is a common problem when trying to do agile with enterprise clients.

      Can end up in a bubble where we are working on requirements that have been passed down - from how long ago? and then take even longer until users are actually using it.

  24. May 2020
    1. managing yourself and others.

      Authors promote two ideologies.

      1. Managing Self: The Five Eds (well, first Three) from Agile Leadership by B. Joiner
      2. Managing Others: at its base is Dave Pink's Drive model: Autonomy, Mastery and Purpose. Authors then go to explain some ways of achieving each of previous.
  25. Apr 2020
    1. Spikes Spikes are a type of exploration Enabler Story in SAFe. Defined initially in Extreme Programming (XP), they represent activities such as research, design, investigation, exploration, and prototyping. Their purpose is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate. Like other stories, spikes are estimated and then demonstrated at the end of the Iteration. They also provide an agreed upon protocol and workflow that Agile Release Trains (ARTs) use to help determine the viability of Epics. Details Agile and Lean value facts over speculation. When faced with a question, risk, or uncertainty, Agile Teams conduct small experiments before moving to implementation, rather than speculate about the outcome or jump to a Solution. Teams may use spikes in a variety of situations: Estimate new Features and Capabilities to analyze the implied behavior, providing insight about the approach for splitting them into smaller, quantifiable pieces Perform feasibility analysis and other activities that help determine the viability of epics Conduct basic research to familiarize them with a new technology or domain Gain confidence in a technical or functional approach, reducing risk and uncertainty Spikes involve creating a small program, research activity, or test that demonstrates some aspect of new functionality. Technical and Functional Spikes Spikes primarily come in two forms: technical and functional. Functional spikes – They are used to analyze overall solution behavior and determine: How to break it down How to organize the work Where risk and complexity exist How to use insights to influence implementation decisions Technical spikes – They are used to research various approaches in the solution domain. For example: Determine a build-versus-buy decision Evaluate the potential performance or load impact of a new user story Evaluate specific technical implementation approaches Develop confidence about the desired solution path Some features and user stories may require both types of spikes. Here’s an example: “As a consumer, I want to see my daily energy use in a histogram so that I can quickly understand my past, current, and projected energy consumption.” In this case, a team might create both types of spikes: A technical spike to research how long it takes to update a customer display to current usage, determining communication requirements, bandwidth, and whether to push or pull the data A functional spike – Prototype a histogram in the web portal and get some user feedback on presentation size, style, and charting Guidelines for Spikes Since spikes do not directly deliver user value, use them sparingly. The following guidelines apply. Quantifiable, Demonstrable, and Acceptable Like other stories, spikes are put in the Team Backlog, estimated, and sized to fit in an iteration. Spike results are different from a story because spikes typically produce information rather than working code. They should develop only the necessary data to identify and size the stories that drive it confidently. The output of a spike is demonstrable, both to the team and to any other stakeholders, which brings visibility to the research and architectural efforts, and also helps build collective ownership and shared responsibility for decision-making. The Product Owner accepts spikes that have been demoed and meet its acceptance criteria. Timing of Spikes Since they represent uncertainty in one or more potential stories, planning for both the spike and the resulting stories in the same iteration is sometimes risky. However, if it’s small and straightforward, and a quick solution is likely to be found, then it can be quite efficient to do both in the same iteration. The Exception, Not the Rule Every user story has uncertainty and risk; that’s the nature of Agile development. The team discovers the right solution through discussion, collaboration, experimentation, and negotiation. Thus, in one sense, every user story contains spike-like activities to identify the technical and functional risks. The goal of an Agile team is to learn how to address uncertainty in each iteration. Spikes are critical when high uncertainty exist, or there are many unknowns.  
  26. Mar 2020
    1. Agile Procurement Alter procurement methodologies to favour agile approaches over “spec and deliver”. Specifically, current methodologies follow a “spec and deliver” model in which government attempts to define a full spec up front and then seeks solutions that deliver against this. The spec and deliver approach greatly diminishes the value of open source - which allows for rapid iteration in the open, and more rapid switching of provider - and implicitly builds lock-in to the selected provider whose solution is a black-box to the buyer. In addition, whilst theoretically shifting risk to the supplier of the software, given the difficulty of specifying software up front, it really just inflates upfront costs (since the supplier has to price in risk) and sets the scene for complex and cumbersome later negotiations about under-specified elements. Instead, create an agile procurement stream in which, rather than detailed requirements being set up front, you secure estimated budget for an initial phase and seeks bids on X number of sprints (with ability to end after any sprint). This model requires acceptance of some budget uncertainty: the total cost of delivery of software may not be fully known in advance. However, one can, alternatively, fix a budget and accept some uncertainty over features delivered. We emphasize that this limitation is not a limitation of open source but of software in general. As the maxim goes: in software development you can have any two of features, time and budget – but not all three. Traditional tendering with its fixed requirements, fixed timeframes – and implicitly fixed costs – exists in an illusory world where one can have all three and implicitly imagines that buying software is like buying traditional goods like chairs whose features, usage and cost are all well-known up front.
  27. Nov 2019
  28. Sep 2019
    1. A generalizing specialist is someone with one or more technical specialties who actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas.

      "actively seeks"

    1. The Agile Software Development Process – How We Do It

      To get your tech startup going you have to deal with a lot of challenges, and come through it unscathed. Otherwise, the failure to deal with those challenges may directly lead to mistakes and problems during the actual software development process- hampering your chances of scaling your development process.

  29. Apr 2019
    1. People-centric means that you will allocate specific people to focus primarily on the maintenance tasks,

      approach 1

  30. Feb 2019
    1. INVEST

      According to this checklist, a User Story should be:

      Indepedent (of all others)

      Negociable (not a specific contract for features)

      Valuable (or vertical)

      Estimable (to a good approximation)

      Small (so as to fit within an iteration)

      Testable (in principle, even if there isn't a test for it yet)


      1. Glossary: INVEST - Agile Alliance
      2. INVEST at XP 1-2-3 by Bill Wake
  31. Oct 2018
  32. Jun 2018
  33. inst-fs-iad-prod.inscloudgate.net inst-fs-iad-prod.inscloudgate.net
    1. AN EQUITABLE ITERATION PROCESS“Fail faster” is a maxim of application developers these days. It means putting something out into the world quickly and responding to user feedback in future iterations. This is a great way to optimize the value of your application to your users, by starting with something simple and experimenting until you get the right features.Unfortunately while this process can increase positive impacts, it does nothing to diminish negatives impacts. The fail faster approach experiments not only with features but also with the lives of people using those features. Consider the release of the Alexa app for Amazon Echo, which did not allow for blocking calls or texts. This raises immediate red flags for anyone who has been doxed or stalked, and may have directly lead to harm for Alexa users. It isn’t enough to iterate features in response to harm — we must also iterate the process that lead to those features being released. What would that process look like if it was centered around the privacy and security of survivors of violence? Of people from communities that are regularly subject to state surveillance?
  34. Nov 2017
    1. Individuals and interactions over processes and tools

      Do not give up personal interaction in favor of a tool-supported process. "Když tomu nerozumím, tak se jdu zeptat."

  35. Aug 2017
    1. To get low-touch, high-return in your content quality and accuracy, you and your team need to rely on the 5 values of Scrum: openness, courage, respect, focus, and commitment.
    1. Agile relies on communication between individuals during the overall process of development; working software is considered the best measure of team activities, and changes in customer's requirements are always welcome. Software is produced in iterative way: it is released once in a small period of time and every release includes new features.
  36. Jul 2017
    1. This third research question led to the formulation of agile text mining, a new methodologyagile textminingto support the development of efficient TMAs. Agile text mining copes with the unpredictablerealities of creating text-mining applications.
    1. In Agile development we actually conjoin these two tactics. During a development “iteration” where we build several user stories some may be adding new functionality incrementally, others may be iterating to improve, change, or remove existing functionality.

      Con l'approccio incrementale aggiungiamo un pezzo alla volta, per incrementi successivi, le funzionalità che compongono il sistema. Scegliamo prima le funzionalità a maggior valore.

      Con l'approccio iterativo adottiamo una strategia esplorativa, con lo scopo di avere feedback su quello che abbiamo costruito, e cambiarlo in base a quello che apprendiamo nel validarlo, per successive iterazioni.

      Nel caso del sw, l'iterazione serve per migliorare (raffinare), cambiare o rimuovere le funzionalità esistenti.

  37. May 2017
    1. Every time a customer service assistant shrugs and says “computer says no” or an organization acts in crazy, inflexible ways, odds-are there’s a database underneath which has a limited, rigid view of reality and it’s simply too expensive to fix the software to make the organization more intelligent. We live in these boxes, as pervasive as oxygen, and as inflexible as punched cards.

      Isn't it interesting how the rigidity of institutionalised "old economy"-businesses and their management structure as well as their work ethics is, in a way, mimicked by their IT-architecture? Efficiency over effectiveness, stability over flexibility, repetition over creative destruction and innovation. And then came Agile...

  38. Jul 2016
    1. Pages 7-8

      Rockwell and Sinclair talk here about developing an “agile hermeneutics” by which they mean an approach to fast/extreme writing. An example of this is that they tried to write a short essay in one day from the initial research but they also do things such as working in pairs with one person typing and the others talking things through.

  39. Jun 2016
    1. Also, the more complex a software project becomes, the more work you have to put into and it grows exponentially. So, keep it simple and make it fast. It's much easier to write software, throw it away and start over again quickly, than having this huge generic system that tries to do everything. It doesn't make sense. It's just too much work. You'd get this huge software system with thousand dependencies and, in the end, it's really hard to innovate, get new stuff in there, or, the worst case, to change the concept. Almost every software that we have published is not generic but is used only for one case. So, keep it simple and get a prototype in under three days.

      Agile visualization its a worthy exception to this trend. It is generic while being flexible and moldable. My first projects start with an easy prototype in a week and became full projects in a couple of months average. Then I can reuse the visual components by using abstraction and making visual builders.

      The couple of months average included the learning of the programming language and environment, the data cleaning and completion. With the builders the time has started to decrease exponentially.

  40. May 2016
  41. Jun 2015
    1. You should suspect motivated stopping when you close off search, after coming to a comfortable conclusion, and yet there's a lot of fast cheap evidence you haven't gathered yet—Web sites you could visit, counter-counter arguments you could consider, or you haven't closed your eyes for five minutes by the clock trying to think of a better option. You should suspect motivated continuation when some evidence is leaning in a way you don't like, but you decide that more evidence is needed—expensive evidence that you know you can't gather anytime soon, as opposed to something you're going to look up on Google in 30 minutes—before you'll have to do anything uncomfortable.

      Keeping these suspicions in mind, how should we improve agile decision making?