Obiettivo 2018: meno agili e Scrum Talk

Ciao e benvenuto su Scrum Tawk, sono il tuo ospite John ...

Uno dei miei obiettivi per il 2018 è di dedicare meno tempo a svelare #agile e #scrum. La disambiguazione è una tana di coniglio e le parole sono troppo molli. Nel 2017 ho trascorso un sacco di tempo a ripassare vari dibattiti. Dubito fortemente che stavo aggiungendo qualcosa di significativo al corpo della conoscenza, quindi la mia ipotesi è che il mio tempo (e il tuo tempo) sia meglio speso altrove.

Quindi, con questo, minimizzerò il discorso su Agile e Scrum. Ecco perché…

Innanzitutto, è noioso e ripetitivo ...

E…

  1. Menzionare Agile raramente porta avanti la conversazione, specialmente con persone al di fuori della bolla del nerd Agile.
  2. Qualsiasi ricerca su Google porta al fatto che molti dei dibattiti su Agile e Scrum hanno quasi un decennio. Non si stanno risolvendo ... la confusione permane. Direi che stanno peggiorando quando "Agile" invecchia, viene commercializzato / venduto e diventa il default. La probabilità che io abbia intenzione di svelare questa confusione è molto bassa. Alcune anime utili hanno contattato per farmi sapere che stavano avendo gli stessi dibattiti con le stesse persone 6+ anni fa.
  3. Almeno per me, Agile comprende una serie di modelli, pratiche e prospettive di valore. Inoltre viene fornito un sacco di bagagli - quasi nessuno con cui lavoro incontra Agile per la prima volta. I team ad alte prestazioni con cui ho lavorato scelgono liberamente da una vasta gamma di modelli (molti al di fuori dell'ombrello Agile), quindi trovo più utile saltare direttamente al corpus completo di modelli. Per coincidenza, queste squadre raramente affermano di "fare Agile" o "fare Scrum".
  4. Mi occupo di tribù, ma in fondo sono una "persona prodotto" (UX, gestione del prodotto, ecc.) E un tipo di pensatore di sistemi irriducibili. Recenti ricerche su Twitter di vari Agile-folk mi hanno convinto che Agile (come esiste oggi) è principalmente per lo "sviluppo di software", con una forte storia di "sviluppo di progetti software". Sebbene ci siano molte richieste per "il business" e "il team" di lavorare insieme, sento un confine implicito (e talvolta esplicito). Il Product Manager dovrebbe avere le risposte e il team deve consegnare debitamente materiale utilizzabile / testato. Preferisco assumere una visione più ampia e più olistica.
  5. I miei amici della community di prodotto / UX hanno investito un sacco di energie per capire come "collegare" le migliori pratiche di quelle comunità alle pratiche Agili. Ancora una volta, penso che ciò sottolinei un pregiudizio nei confronti di Agile come "modo in cui gli sviluppatori di software fanno le loro cose", e mette le altre aree di competenza sul piede posteriore cercando di imparare a "giocare" Agile. La comunità Agile ha abbracciato me (e gli altri) dal mondo del prodotto - "abbiamo davvero bisogno di ottime OP" - ma personalmente non ne ho voglia. Ancora una volta, ho sempre immaginato che ci fosse un "modo" più generale che combina prodotto, UX, progettazione dell'organizzazione, supporto, operazioni, ecc. La mia preoccupazione è che i confini alimentino la Feature Factory e la centralità dell'output.
  6. Circa un anno fa ho incontrato Joshua Kerievsky e Modern Agile. Quando ho bisogno di un'istantanea "generativa" di Agile (qualcosa che catturi l'essenza e possa generare / filtrare "modi" appropriati), torno su Modern Agile in quanto è intenzionalmente privo di pratiche specifiche e ha applicabilità per l'intera organizzazione ... una caratteristica importante dato che la maggior parte dei "problemi" non sono esclusivamente problemi di sviluppo del software. Trovo che MA sia un complimento perfetto per molti principi / pratiche Lean che adottano una prospettiva di sistemi più ampia. L'argomento è in genere "ma MA non spiega il come" a cui sostengo che stiamo nuotando nel come. Loro perché sono ugualmente importanti e principi come "Rendere la sicurezza un prerequisito" sembrano risuonare profondamente con i team.
  7. Anche tra gli "agilisti" che si identificano da soli ci sono interpretazioni molto diverse di ciò che Agile è, non è, dovrebbe essere, non dovrebbe essere, ecc. Non c'è nulla di intrinsecamente sbagliato in questo (è un po 'freddo, in realtà), ma rende molto difficile parlare di Agile.
  8. Allo stesso modo, alcune persone si identificano così profondamente con alcuni aspetti di Agile - auto-organizzazione, lavoro a un ritmo sostenibile, "fiducia [team] per portare a termine il lavoro" - che qualsiasi discussione sui benefici relativi delle diverse pratiche, o la progettazione di diversi "modelli", diventa difficile a causa del profondo investimento personale. Agilisti ardenti trasferiscono gran parte della loro identificazione personale in Agile. A dire il vero, io sono uno di questi. Mi rende difficile parlarne.
  9. Tutto ciò che viene commercializzato e venduto (e certificato) sarà difficile da svelare. Questa è una costante con qualsiasi cosa "utile" (vedi DevOps, per esempio), dove c'è la richiesta di "comprarlo". Il dialogo intorno ad Agile è fortemente influenzato dall'esperienza di insegnarlo per denaro, cercando di introdurlo in ambienti potenzialmente ostili e soddisfacendo le esigenze delle persone (e delle aziende) che acquistano / tentano di installare framework (a questo punto ... adozione successiva ).
  10. Nella mia mente, i modelli / le pratiche Agile sono strumenti utilizzati - di concerto con molti modelli adiacenti ad Agile - per ottenere risultati di business preziosi. Come recentemente sottolineato da Neil Killick, parlare troppo di Agile dà l'impressione che "fare Agile" sia l'obiettivo finale. Non credo che ... ma è dannatamente facile uscire così.
  11. Può essere impossibile (per la maggior parte dei non metodologi che operano nel mondo reale) separare Agile da Scrum. Scrum è 1) controllato da due persone, 2) ha una prospettiva, 3) manifesta che la prospettiva - comprese le varie paure - nella sua progettazione, e 4) è uno dei tanti approcci validi. Ancora una volta, niente di sbagliato in questo - hey, complimenti a Jeff e Ken, e ai rabbiosi fan di Scrum - ma rende la discussione molto più difficile nel mio mondo.
  12. La comunità Agile è assolutamente meravigliosa e mi sento meraviglioso (e onorato) di farne parte. Questo non è in alcun modo un ripudio di Agile, ma solo un riconoscimento da parte mia che parlarne esplicitamente non mi aiuta - n = 1 - a me molto.

Speriamo che Agile-folk troverà il contenuto interessante. Parlerò di più su pratiche specifiche e meno su nebuloso "Agile" e molto meno su Scrum.

Migliore

John