Jako konzultant mám tu výhodu, že se můžu poučit nejen z chyb svých ale i cizích. Na následujících řádcích bych chtěl ukázat problémy a chyby, se kterými jsem se setkal a které by vyřešil Scrum a agilní metodiky obecně…
(for English scroll down)
Co je Scrum se dočtete na wiki, ale pro pochopení tohoto článku o Scrumu vlastně nepotřebujete téměř nic vědět.
Závazek týmu
Ve Scrumu se za výsledky práce zavazuje tým (v anglické literatuře commitment). Pokud vám někdo zadá práci, určí nerealistický termín a trvá na něm, co se stane? Rezignujete na výsledek. Ve Scrumu odhady tvoří tým a jako tým jdete s kůží na trh. (Tedy vlastně se šunkou podle bajky The Chicken and the Pig).
Decentralizace
Překvapuje mě, že v době distribuovaných systému je projektové řízení stále spíše centralizované. Formální hierarchie je důležitá, ale nesmí být na obtíž. Můžete se inspirovat tím, jak to dělají mariňáci viz kniha Corps Business: The 30 Management Principles of the U.S. Marines, které se možná budu podrobněji věnovat v některém z dalším příspěvků.
Poměrně často vídám tým-leadera zavaleného dotazováním, co má ten či onen právě teď dělat. Nejednou končí ve spirále micromanagementu. Scrum tým žádného dispečera nepotřebuje.
Levá ruka ví co dělá pravá
Obzvláště v korporátních firmách, ale nejen tam, váznou informace o tom, co kdo dělá (propracovanému systémy reportování navzdory). Navíc se můžete setkat s lidmi, kteří nic nedělají, ale přesto působí důležitě, zaneprázdněně a nepostradatelně (šašky si z toho tropí kniha Lenosti, buď pozdravena!).
Scrum předepisuje tzv. Stand-up meeting (česky jsem to ještě neslyšel, ale snad schůzka na stojáka). Jedná se o pravidelné jednodenní schůzky nikoliv mítinky. Trvají nanejvýš 15 minut a stojí se při nich (zabraňuje to rozkecávání). Každý řekne, co dělal včera, jestli má nějaký problém a co bude dělat dnes. Nezachází se při tom do detailů. To ovšem neznamená, že se problémy zametají pod koberec. Jen se nastolená témata následně probírají pouze s těmi, kteří si na stand-upu uvědomili, že se jich týkají.
Osobní jednání
Agilní metodiky nenabádají k anarchii a k pálení dokumentace. Nicméně dostali jste někdy desítky stran dlouhou analýzu s ač možná nevyřčeným sdělením: „Programuj a neobtěžuj mě s otázkami!“? Než se tým zaváže k práci, musí rozumět tomu, co je její náplní. Včetně toho, kdy bude výsledek považován za hotový (v anglické literatuře level of done).
Už to skoro bude
Zajímá vašeho projektového manažera, na kolik procent je úkol splněn? A všimli jste si, že posledních 20% funkcionality trvá 80% procent času (syndrom už to skoro bude)? Ve Scrumu je důležité, zda je user story hotová, ne na kolik procent. Scrum dodává jen plně funkční, otestované a akceptované řešení (nikoliv polovičatě zpracované user story).
Časový rámec
Scrum časově ohraničuje (v anglické literatuře timeboxing) jednotlivé cykly vývoje (sprinty, iterace) na přibližně jeden až čtyři týdny. Žádné několikaměsíční rozplizlé období. Na průšvihy se musí přijít včas a ne je tutlat (v anlické literatuře je pro to pěkný termín fail early). Pevně daný rozsah práce v iteraci je rovněž účinné nárazníkové pásmo již zmiňovaného micromanagementu.
Zpětná vazba
Kdekdo se zaklíná zpětnou vazbou, ale praktické využití obvykle vázne. V armádě je briefing a debriefing běžnou záležitostí. Softwarové inženýrství je mladý obor a tak znovuobjevuje kolo. Scrum zpětnou vazbu systematicky zařazuje do procesu jako Sprint Review a Sprint Retrospective.
Závěr
Scrum není zázračné, bezstarostné a bezúdržbové řešení pro každou situaci, firmu a projekt. Nicméně nabízí recept k léčbě bolestí, které byly v článku zmíněny. Podělte se v komentářích o své zkušenosti se Scrumem a dalšími agilními metodikami. Všem, kteří se Scrumem začínají ale i těm kteří ho již používají, držím palce!
Working as a consultant, I have learnt lessons not just by my mistakes but also by our customers’ mistakes. I would like to share problems and lapses I have met. These troubles could be solved by Scrum or by Agile methodologies in general. You do not need to know Scrum for the purpose of this article. Anyway you may read for example at Wikipedia for more details.
Commitment
The team commits to the result of its work. What will happen if an unrealistic term is imposed and is fixed? You resign, right? Speaking about Scrum, it is the team who estimates and it is its ham. See The Chicken and the Pig fable.
Decentralization
It surprises me, that today, in the age of distributed computing, the management is still centralized. Indeed, formal hierarchy is important, but it must not stand in the way. U.S. Marines are very inspiring, see the book Corps Business: The 30 Management Principles of the U.S. Marines.
Quite often I see team-leader overwhelmed by programmers asking what to do. It is the road to the death by micromanagement. Scrum needs no dispatcher.
No secrets
In big companies especially, and not only there, information are missing (despite of super reporting systems). Moreover you may met people doing nothing but look important. Corinne Maier makes fun of it in the book Bonjour Laziness.
Scrum prescribes daily Stand-up meetings, not longer than 15 minutes, everybody standing, speaking what did she do yesterday, whether she has any problem and what is she going to do today. Do not discuss details. If needed, discuss it later with only involved people.
Individuals and interactions
Agile methodologies does not mean anarchy and burning UML or documentation. Anyway have you ever got requirements – tens pages of documentation with no time for questions? Before commitment, you need to understand the problem and know the level of done.
It is almost done
Is your project manager interested in progress of each task? Have you noticed that last 20% takes 80% of time? For Scrum it is important whether the user story is done or not. Scrum deliver entirely working, fully tested and accepted solution (not somehow completed user stories that might be functional).
Timeboxing
Scrum timeboxes development cycles (sprints, iterations) for approximately one to four weeks. No more never-ending cycles. It helps to fail early. Last but not least fixed scope is a great weapon against micromanagement.
Feedback
Feedback is such a buzzword today. Too many people speak about it but not many are doing it. Briefing and debriefing is common in army. Software engineering is young branch so we reinvent a wheel. Sprint Review a Sprint Retrospective are the way of feedback in Scrum.
Conclusion
Scrum is no silver bullet. Scrum is not suitable for every company and every project. Scrum is not maintenance-free and trouble free. Anyway Scrum may help just you. Please share you experience with Scrum and agile methodologies. I cross my fingers for those you who start with Scrum!
About author: Luboš Račanský, AspectWorks Blog