Запиши се за следващото ми сертифициращо обучение за Scrum Master-и и Product Owner-и към Scrum.org на 24-25.02.2022.
KPI в
Scrum
Kлючови индикатори на представянето (KPI) на ролите в Scrum
Много често в практиката ми се сблъсквам с необходимостта от дефинирането на ключови индикатори на представянето (или т.нар. Key Performance Indicators - KPIs) на отделните роли в Scrum. И това не е случайно. Питър Дракър, американският гуру на мениджмънта, е казал 'Ако не можеш да го измериш - не можеш да го контролираш; ако не можеш да го контролираш - не можеш да го подобриш. Ако не можеш да го подобриш си изгубен.'. И аз напълно споделям негово виждане. Тук няма да обсъждам добри практики в дефиниране на KPI-и по принцип (ще го оставя за друга статия или при интерес, ще го обсъдим в някое от моите сертифициращи обучения по Scrum), а по-скоро ще споделя конкретна система от индикатори, която отразява спецификата на всяка от ролите в Scrum. Тази система съм използвал успешно в различни организации и вярвам, че тя би могла да бъде полезна и на теб.
15 мин.
Индикатори за оценка на представянето на Product Owner-а
Знаете, че основната и най-важна цел на Product Owner-а в Scrum е да максимизира доставената стойност (или добаванета стойност, ползата) за клиента. Съответно всички KPI, свързани с тази роля, са свързани имено с т.нар. business value.
Speed of Delivery (Time to Market)
Lead time на бизнес изискванията (нормализирани по сложност и групирани по service level agreement).
Честота на нови версии или т.нар. release frequency (напр. брой нови версии на месец).
Средно време за финализиране на нова версия (или finalization / stabilization / synchronization / hardering phase) спрямо общото време за създаване на новата версия.
Return on Investment (ROI)
Среден (или общ) бизнес обхват на промените в даден период от време (напр. очакван брой на засегнатите потребители; очакван ефект върху conversion rate; очакван ефект върху визията на продукта; очакван ефект върху NPS / удовлетвореността на клиента / лоялността на клиента; и др.).
Среден приход / чиста печалба (от доставените функционалности за даден период от време).
Средна оценка на важността на постигнатите бизнес цели и удовлетворените бизнес нужди (за даден период от време).
Спестени разходи / намалена алтернативна цена (в резултат от дейността на Scrum екипа).
Намалено време, прекарано по "waste" (или всичко онова, което не носи добавена стойност за клиента).
Total Cost of Ownership (TOC)
Среден разход по създаването на нови функционалности (нормализирани по сложност и групирани по service level agreement).
Време, прекарано по бъгове и дефекти спрямо общото време, прекарано по нови функционалности (за даден период от време).
Технически дълг (или т.нар. technical debt).
Качество на кода (напр. code coverage, coupling and cohesion, cyclomatic complexity, code duplication, etc.).
Feature creep.
Голяма част от тези показатели могат лесно да бъдат измерени (при това автоматично), докато друга (като напр. technical debt и feature creep) са малко по-трудни и изискват повече усилия. В друга статия ще споделя конкретни добри практики за тяхното количествено или качествено измерване.
Индикатори за оценка на представянето на Development Team-а
Най-важните характеристики на Development Team-a в Scrum са той да бъде самоорганизиращ, крос-функционален и самоактуализиращ се. Имено тези характеристики стоят в основата на KPI-ите, които съм дефинирал по-долу.
Доверие на другите (trust) към екипа и степен на овластеност (empowerment)
Ангажираност или commitment (напр. възприетата от другите готовност и желание на екипа да поема ангажименти).
Надежност / отговорност или dependability / reliability (напр. увереността на другите, че екипът ще разработи това, което казва и, че ще бъде последователен и надежден в действията си).
Включеност или еngagement (напр. загриженост от страна на екипа към всички аспекти от доставянето на добавена стойност за клиента, а не само към фазата по имплементация).
Автономност (напр. средното време, което мениджмънт екипа или хора извън Scrum екипа прекарва с екипа по време на спринт).
Проактивност и самоинициативност (напр. доколко ефективно се справя с неочаквани предизвикателства; дали повдига навременно проблеми и т.н.).
Увереност на другите в способностите на екипа (confidence)
Увереност в техническите компетенции на екипа (напр. увереността на другите, че екипът е достатъчно технически компетентен, за да свърши работата, която е нужна с достатъчно високо качество).
Увереност в уменията на екипа да решава проблеми (напр. увереността на другите, че екипът може да решава уникални проблеми по креативен и ефективен начин).
Увереност в способността на екипа да учи (напр. увереността на другите, че увереност, че екипът може ефективно да придобие знания и умения, когато е необходимо).
Нагласи за "разтеж" (growth attitudes)
Нагласи към усъвършенстване на вече съществуващи решения или exploit attitudes(напр. екпиът възприема бизнес изискванията като възможности и търси начин да ги развие максимално и всестранно спрямо желанията на клиента).
Нагласи към допълване и разширяване на вече съществуващите решения или explore attitudes (напр. екипът търси активно какво може да се направи още, за да се достави допълнителна добавена стойност за клиента).
Нагласи за само-актуализация или self-development / continuous improvement (или екипът търси начини да подобри своите знания, умения, опит, нагласи, инструменти и т.н.).
За разлика от индикаторите на Product Owner-a, тези за Development екипа са доста по-трудни за измерване и разчитат на външни качествени оценки (от страна на Product Owner-а, Scrum Master-a, мениджмънт екипа, различни заинтересувани страни и т.н.). Но не е невъзможно - просто е нужна повече креативност! :)
Индикатори за оценка на представянето на Scrum Master-а
Scrum Master-ът е този, който се грижи за това всички да разбират правилно Scrum и емпиричната разработка на продукти (Empirical Product Development или ESD), както и да ги прилагат ефективно. Разбира се има още много други важни неща, за които той отговаря и всички те са отразени в KPI, посочени по-долу.
Scrum и EPD
Стриктност в прилагането на Scrum (напр. измервани чрез т.нар. Scrum scores, Scrum maturity levels и др.).
Степен на приемане на Scrum и EPD (напр. измервани чрез т.нар. perceived usefulness, perceived ease of use, attitude toward using, behavior intention to use и др.).
Правилно разбиране на Scrum и EPD (напр. чрез индъкшън програма и сертифициране, оценка чрез въпросници или чрез решаване на казуси и т.н.).
Въшни пречки и разсейващи фактори за екипа
Lead time за премахване на пречки (т.нар. impediment lead time).
Повторяемост на пречките (напр. чрез измерване на impediments reoccurrence ratio).
Ефективно време на Development Team-а (напр. value added time съотнесено към cycle / lead time).
Синхронизация и премахване на зависимости
Средно време, прекарано в синхронизация между Scrum екипите (напр. за интеграция; разрешаване на конфликти; и др.) за даден период от време.
Lead time за премахване на зависимости (т.нар. dependencies lead time) за даден период от време.
Повторяемост на зависимостите (чрез измерване на т.нар. dependencies reoccurrence ratio).
Процесни иновации
Средно време, прекарано по експериментиране с процеса на работа (за даден период от време).
Сред брой промени в начина на провеждане и начина на организиране на работата в спринта.
Дял на успешните експерименти спрямо всички проведени експерименти от екипа (т.нар. process experimentation success ratio).
Индивидуален и екипен коучинг
Ефективност при управлението на продукта (вкл. качесто на Product Backlog-а; прозрачност по отношение на бизнес нуждите и бизнес целите; време за отговор от страна на клиента; следване на just-in-time и just-enough принципите и т.н.).
Способност на Development Team-а да се самоорганизира (напр. измерени чрез оценка зрялостта на екипа; доверието на другите към екипа; овластеност на екипа; и т.н.).
Крос-функционалност на екипа (напр. степен на зависимост на екипа от външни хора; степен на взаимозаменяемост между отделните членове на екипа и др.)
Прилагане на Scrum в организацията
Участие в изграждане на общност (вкл. време, прекарано в споделяне на опит и добри практики с други Scrum Master-и и членове на организацията).
Участие в различни инициативи за подобряване на прилагането на Scrum в организацията (напр. измерено чрез средното време, прекарано в инициативи извън Scrum екипите, с които работи).
Участие в конференции и събития на общността.
И при Scrum Master-a, подобно на Development Team-а, повечето показатели са качествени, което ги прави трудни за измерване и не съвсем надеждни. Но с времето и опита, екипите се научават как да измерват тези показатели правилно и стават все по-добри и по-добри в това. Ето защо започнете от нещо и го усъвършенствайте в движение. Нали това е и философията зад Agile? :)
Чудиш се коя роля е най-подяща за теб?
Научи чрез функционалното домино!
Намери правилната позиция и роля, в която да влезеш.
Свързани обучения?
Свържи се с мен
Хареса ти това, което прочете? Научи още повече със сертифициращото обучениe към Scrum.org, както и с програмата за лична ефективност и програмата за екипна ефективност на agify.me! :)