Come faccio a sapere se un'azienda è seriamente preoccupata per Agile e Scrum? [duplicare]

Considererei queste domande per il lato Scrum:

• Quanto durano i tuoi sprint?
• Quanto durano le riunioni di pianificazione, le dimostrazioni e le retrospettive?
• Chi è Scrum Master e Product Owner? Quanto è grande il team?
• Quanto è grande il registro posteriore?
• Quanti sprint ha fatto il team? Quanti progetti sono stati completati usando Scrum?
• Qual è la velocità della squadra per uno sprint?

Dal lato Agile, probabilmente farei un passo indietro per chiedere:

• Delle pratiche che usi, che consideri essere parte di Agile? (Paio di programmazione, XP, TDD, Prototyping sarebbero alcuni esempi qui.)
• In che modo queste pratiche si adattano al Manifesto Agile?
• In che modo la tua azienda ha definito Agile? È solo il manifesto o c'è dell'altro?

La chiave è trovare quelle domande che non sono una domanda si / no in cui qualcuno potrebbe semplicemente dare una risposta che ritengono corretta ma piuttosto cercare di approfondire le cose.

Chiedi a qualcuno di spiegare il loro processo di sviluppo.

• Hanno in realtà un processo e non solo un'etichetta popolare che viene schiaffeggiata sulle loro pratiche a casaccio.
• Possono spiegarlo in modo scorrevole e preciso? Questo è quello che fanno tutto il giorno per vivere quindi dovrebbero saperlo in dettaglio. L'intera squadra dovrebbe essere a conoscenza. È un'indicazione di avere un processo e di realizzarlo. Non è il momento di iniziare, "Dipende ..."
• Possono darti qualche informazione su questo processo di adozione e su come si adatta alle loro esigenze? Come funziona per loro e perché?
• Che cosa odiano di più e pensano di poter risolvere il problema? Vuoi vendermi qualcosa, dimmi cosa odiano di più i tuoi clienti. Non voglio vedere solo il lato buono del manzo.
• Come tengono traccia di tutto? Codice, bug, documentazione, carico di lavoro, comunicazioni, ecc.

Questo è meglio di qualcuno che sostiene di seguire Scrum fino alla morte, ma lo fa male. Sapere come lo usano perché, "Se hai visto un'implementazione dello sviluppo agile, hai visto un'implementazione dello sviluppo agile."

Una cosa è certa, ogni azienda che ho accettato in quella posizione mi ha detto durante l'intervista che mi ha detto qualcosa sull'effetto di "STIAMO CERCANDO di trasferirci in Agile" che si è rivelata un casino caldo e grottescamente mal gestito. Se ottieni una risposta simile, mi girerei e CORRE.

È una buona idea chiedere loro informazioni sulle loro pratiche di build, implementazione e configurazione. Non prestare attenzione così tanto a quello che dicono, ma come lo dicono. Se noti nervosismo, agitazione, incredulità o paura, allora anche quelli sono enormi segnali di allarme.

Per esempio, cerca segni di sudorazione insolita, rapidi occhi svolazzanti, deglutizione (movimento della mela adams, ecc ...). Se ti danno una risposta e i loro occhi si spostano a sinistra mentre parlano, questo può essere un segno di inganno o di informazioni che si ritirano. Se guardano a destra o in alto o direttamente nei tuoi occhi, probabilmente sono veritieri.

So che sembra assurdo, ma un mio amico del Servizio segreto mi ha insegnato a notare molte di queste cose quando intervistavo le persone. Mi è stato mentito più volte di quanto possa contare sulle interviste e sono certo di aver evitato alcuni posti brutti impiegando queste tecniche.

Vorrei andare con domande a risposta aperta piuttosto che sì / no domande. È come quando ti intervistano. Non volevano chiedere: "Sei un gran lavoratore?" o "Sei intelligente?" oppure "Puoi consegnare?" Ti chiederebbero di illustrare in che modo incarnare queste qualità.

Quindi, piuttosto che le vostre domande esemplificative, chiederei al consulente di descrivere il processo di compilazione e il processo di rilascio, per esempio.

Inoltre, sono incline a pensare che non ci sia un unico modo di fare le cose, quindi fare domande aperte dà loro l'opportunità di descrivere i loro processi piuttosto che vedere se superano lo Scrum Test. Quindi puoi giudicare se è qualcosa su cui puoi lavorare piuttosto che se hanno controllato tutte le caselle di mischia.

• Chi modera / guida la mischia?
• Quanto è grande il team di sviluppo e in che modo vengono suddivisi i team?
• Il team aderisce allo standard di sprint in 2 settimane?

Poche domande a cui potrei pensare ... sulla base degli argomenti discussi con una società con cui ho recentemente intervistato. In questo caso, la scrum lead è un architetto di software; il team è molto grande ma suddiviso in team più piccoli con focus specifico basato sui progetti; è stato espresso esplicitamente che la squadra, nel complesso, aderisce al formato sprint di 2 settimane.

Inoltre, puoi provare un tatto per la dedizione dell'azienda ad Agile di quante persone ti hanno intervistato. Nel mio caso, ho avuto 5 persone diverse condurre interviste di 45 minuti. Questo è fatto per determinare quale squadra potrei meglio adattarmi ... in quale squadra potrei fornire qualche esperienza mancante, ecc. Questo particolare punto non è un dato ... ma mi ha anche dato l'opportunità di chiedere ad ognuno il proprio Agile formato.

Non iniziare con fare domande. Lascia che il consulente spieghi in dettaglio come funzionano, quali ruoli hanno, quali sono le responsabilità dei ruoli, come viene pianificato, spedito il prodotto ecc. Quindi fai domande complementari basate sulla spiegazione del consulente.

Se hai bisogno di aiuto con domande esatte non devi assolutamente chiederlo. Se vuoi giudicare se l'approccio Scrum / Agile in altre società è abbastanza buono dovresti essere in grado di definire queste domande tu stesso. Se non sei in grado, come puoi sapere che la risposta è corretta?

Se vuoi veramente testare il consulente puoi anche fare domande "sbagliate" in modo che lui si debba opporre a te per dimostrare che stanno andando agilmente. Ma tieni presente che questo può davvero andare contro di te e possono perdere interesse per te.