Webtown blog

Gondolataink cikkekbe rendszerezve

null SCRUM Sprint sikeressége

Vrana Zoltán

Mi befolyásolja a SCRUM Sprint sikerességét?

Egészen elképesztő, hogy mennyi minden befolyásolja egy Scrum sprint sikerességét... Vannak dolgok, amelyekre hathatunk és vannak, amelyekre kevésbé. De most nem filozofálni szeretnék, kicsit inkább analitikus megközelítéssel íródott ez a cikk.

Sprint cél teljesülése

Kvalitatív KPI

A sprint elindításakor meghatározott sprint cél teljesülése egy kvalitatív KPI a scrum sprint esetén. Fontos, hogy ennek nincs köze a kvantitatív KPI-okhoz, azaz a gyakorlatban, akkor is lehet sikeres egy scrum sprint, ha nem készül el minden backlog elem a sprint végére.

Fontos: SCRUM TEAM közösen fogadja el a sprint célt, nem erőltethető rá a DEV Team-re!

Nehezítő körülmény az, ha nagyon magas az egy sprintben szállított projektek számossága, mivel ebben a helyzetben akár több célja is lehet a sprintnek, amely viszont projekt alapú silósodáshoz vezet.

 

Potenciálisan élesíthető kimenet szállítása

Kvalitatív KPI

Szintén kvalitatív mutató, mely a scrum team értékteremtési képességét mutatja. Ez a mutató a működő szoftver szállításáról szól.

Amennyiben egy scrum team nem képes potenciálisan élesíthető kimenetet (azaz működő szoftvert) szállítani, akkor készletezésről beszélünk, amely az egyik legkritikusabb veszteség-termelés egy projektben.

A készletezés csökkenthető, sőt törekedni kell rá.

Eszközei:

  • húzó elv alkalmazása, egydarabos áramlás megközelítése (elérni nagyon ritkán lehet – nem csak DEV Team munkaszervezésétől függ, hanem a backlog állapotától is)

  • WIP korlát bevezetés: tudja segíteni, de ez iteratív finomhangolás a Cumulative Flow chart segítségével

 

Lead Time, Cycle time

Kvalitatív KPI

Egy szervezet, egy SCRUM team munkafolyamatainak mérőszáma, mely megmutatja, hogy a backlog és az éles környezet között mennyi idő telik el (Lead Time), illetve az end-to-end folyamatban lévő részfolyamat (Cycle Time) mennyi ideig tart.

Szoros kapcsolatban vannak ezek a KPI-ok a Go To Market Time értékkel.

Minél alacsonyabbak az értékek annál gyorsabban tud változást kiadni egy szervezet. A magas értékek a kapcsolódó folyamat(ok) nem optimális állapotát mutatják.

Nehezítő körülmény, hogy a Lead Time drasztikus csökkentése sok esetben vállalati kultúrát, szervezeti egységeken átívelő folyamatokat érintenek, amelyeket nehéz megváltoztatni.

Nagyvállalati környezetben a Cycle Time mérésével szétválaszthatók az end-to-end folyamat részfolyamatai.

 

Sprint Review-n visszanyitott backlog elemek száma

Kvalitatív KPI

A Sprint Review-n visszanyitott backlog elemek száma rámutat a SCRUM Team sprinten belüli munkafolyamatának minőségére, a sprinten belüli fejlesztés és tesztelés sikerességére, illetve a review-ra való felkészülés szintjére, a backlog elemekben leírt elfogadási kritériumokra való fókuszáltságra.

 

Várható eredmények

A sikeres csapatok 70-80%-ban produkálnak „sikeres” sprinteket. A 100%-os mutató nem cél, mivel a csapat egészséges fejlődéséhez kockázatvállalási kedv is szükséges, mely magában hordozza az esetleges sikertelen sprintek kockázatát.

Ha egy scrum team minden sprintje sikeres, akkor szinte biztosan kijelenthető, hogy a scrum team-ben tartalékok vannak, amelyek mozgósíthatók a kockázatvállalási kedv facilitálásával.

 

Anti-pattern-ek, amelyek akadályozzák a KPI-ok alkalmazását

  • 3-4 vagy annál több projekt-hez / product-hoz kapcsolódó backlog elemek a sprintekben megnehezítik a sprint cél meghatározását. Ilyen esetekben jellemzően a kvantitatív szempontok kerülnek előtérbe.

  • Nagyszámú és súlyú külső függés a sprintben lévő feladatok kapcsán, vagy akár azon kívül

  • Dedikált DEV team hiánya megakadályozza a felelősség vállalás és az elköteleződés kialakulását, mivel a folyamatosan változó team-ben a tagok fókusza lekorlátozódik a saját feladataik elvégzésére.

  • nem megfelelő backlog elemek, backlog hiánya, sprintready készlet hiánya a backlog tetjén

  • nem transzparens és nem érthető DOD

  • a sprintek szkópja folyton változik, nincs sprint backlog freeze

  • Sprintek nem azonos hosszúak

  • Nem a DEV Team vállal

  • Nagyméretű backlog elemek

  • Nincsenek AC-k a backlog elemeknél, vagy nem érthető