Много често в практиката ми се сблъсквам с необходимостта от дефинирането на ключови индикатори на представянето (или т.нар. Key Performance Indicators - KPIs) на отделните роли в Scrum. И това не е случайно. Питър Дракър, американският гуру на мениджмънта, е казал "Ако не можеш да го измериш - не можеш да го контролираш; ако не можеш да го контролираш - не можеш да го подобриш. Ако не можеш да го подобриш си изгубен.". И аз напълно споделям негово виждане.
Тук няма да обсъждам добри практики в дефиниране на KPI-и по принцип (ще го оставя за друга статия или при интерес, ще го обсъдим в някое от моите сертифициращи обучения по Scrum), а по-скоро ще споделя конкретна система от индикатори, която отразява спецификата на всяка от ролите в Scrum. Тази система съм използвал успешно в различни организации и вярвам, че тя би могла да бъде полезна и на теб.
Знаете, че основната и най-важна цел на Product Owner-а в Scrum е да максимизира доставената стойност (или добаванета стойност, ползата) за клиента. Съответно всички KPI, свързани с тази роля, са свързани имено с т.нар. business value.
Голяма част от тези показатели могат лесно да бъдат измерени (при това автоматично), докато друга (като напр. technical debt и feature creep) са малко по-трудни и изискват повече усилия. В друга статия ще споделя конкретни добри практики за тяхното количествено или качествено измерване.
Най-важните характеристики на Development Team-a в Scrum са той да бъде самоорганизиращ, крос-функционален и самоактуализиращ се. Имено тези характеристики стоят в основата на KPI-ите, които съм дефинирал по-долу.
За разлика от индикаторите на Product Owner-a, тези за Development екипа са доста по-трудни за измерване и разчитат на външни качествени оценки (от страна на Product Owner-а, Scrum Master-a, мениджмънт екипа, различни заинтересувани страни и т.н.). Но не е невъзможно - просто е нужна повече креативност! :)
Scrum Master-ът е този, който се грижи за това всички да разбират правилно Scrum и емпиричната разработка на продукти (Empirical Product Development или ESD), както и да ги прилагат ефективно. Разбира се има още много други важни неща, за които той отговаря и всички те са отразени в KPI, посочени по-долу.
И при Scrum Master-a, подобно на Development Team-а, повечето показатели са качествени, което ги прави трудни за измерване и не съвсем надеждни. Но с времето и опита, екипите се научават как да измерват тези показатели правилно и стават все по-добри и по-добри в това. Ето защо започнете от нещо и го усъвършенствайте в движение. Нали това е и философията зад Agile? :)
Научи чрез функционалното домино!