Agile съсипва вашия продукт

Стремежът към малки, бързи и автономни екипи е създаване на фрагментирани, объркващи и разединени преживявания.

Илюстрация от Джоан Лемай

Проблем в Рая

В моята работа като продуктов треньор и консултант, първият въпрос, който обикновено ми се задава, е: „Как можем да бъдем по-прилични [известната технологична компания X]?“ На този въпрос са отговорили безброй пъти в добре публикувани казуси, като напр. Моделът на „две пици на Amazon“, моделът „отряд, племена, глави и гилдии“ на Spotify и мантрата на „Facebook се движат бързо и разбиват нещата“ от Facebook. Разгледани като цяло, тези истории нарисуват убедителна картина как изглежда развитието на продуктите в най-добрите в класа дигитални компании: малки, автономни екипи, работещи със светкавична скорост.

Идеята за малки, автономни екипи - основна част от много методологии на Agile, използвани от съвременните технологични компании - предлага привлекателна алтернатива на бюрократичните структури за управление и управление, които все още доминират в корпоративния свят. И все пак, този подход също носи съществен риск: продуктите, създадени от малки, автономни екипи, ще се чувстват като разединен набор от малки, автономни функции.

Разделът „Проучване“ на основната навигация на Facebook (отляво) и един от многото неразбираеми списъци с функции, достъпни за администраторите на продукта на Google G-Suite (преди Google Apps) (вдясно).

За реални примери за този анти-модел не е необходимо да изглеждате по-далеч от водещите продукти, направени от някои от тези много „най-добри в класацията“ цифрови компании. (Вижте раздела „Проучване“ на началната страница на Facebook за особено блестящ пример или се опитайте да се движите безпроблемно между продуктите, известни някога като „Google Apps.“) Тъй като цифровите продукти стават все по-големи и сложни, е по-важно от всякога ние разглеждаме отвъд отделните характеристики и мислим как тези функции се комбинират, за да създадат безпроблемни, сплотени преживявания. И това ще изисква да се признае, че самите зависимости, които забавят работата на малки, автономни екипи, понякога могат да бъдат полезни за клиентите, които тези екипи в крайна сметка обслужват.

Работна скорост спрямо нуждите на клиента

Принципите и практиките на движението Agile се оказаха особено привлекателни за организациите, които искат да вървят в крак с бързо променящия се свят. И без съмнение, разделянето на големи и взаимозависими отбори в малки автономни отбори вероятно ще увеличи скоростта, с която всеки отбор може да пусне подобрения на конкретното парче от продукта, за което отговаря.

Оказва се, че проблемът е, че вътрешното триене, отстранено от малки автономни екипи, все още често се усеща от външни клиенти. Статия в Harvard Business Review от 2013 г., наречена „Истината за опита на клиентите“, прави критична точка, която често се губи в разговора за малки, автономни екипи: от гледна точка на клиента най-важната част от продукта често не е индивидуалните му характеристики, а по-скоро как тези функции се събират, за да създадат безпроблемно и сплотено изживяване.

Обхватът, определянето на приоритетите и изпълнението на такава работа задължително включва висока степен на координация между и между екипите - и тази координация изисква време и усилия. За организациите, измерващи успеха на всеки екип по оперативната скорост на тяхната работа, това може да създаде ярко прекъсване между работата, която е най-важна за клиентите, и работата, която всеки малък автономен екип вероятно ще даде приоритет. Това в крайна сметка задава въпроса: наистина ли автономията е целта, към която искаме да работим?

Да го върнем заедно

Разбиването на големи продукти на малки, управляеми парчета не е лесна задача - но оказването на тези парчета заедно се оказва, че е много по-трудно. Много мащабирани рамки Agile са създадени отчасти за балансиране на автономността в малки мащаби с координиране на големи картини. Но най-важната стъпка към поддържане на малки екипи свързани и координирани, както открих, докато изследвах най-новата си книга Agile for Everybody, е по-малко въпрос на организми и рамки, отколкото на сътрудничество и култура. Както сподели VPI на Spotify за растеж и маркетинг, Mayur Gupta ми каза:

Когато хората се позовават на модела Spotify, обикновено говорят за гилдии, племена и глави. Но това са просто ритуали. Не вярвам, че разрушавате бариерите, променяйки отчетни редове. Когато имате наистина многофункционален екип, репортажните редове стават без значение ... Докато продължавате през живота и кариерата си, осъзнавате, че това, което наистина движи тези промени, е културата.

С други думи, просто преначертаването на вашите org графи, за да следвате „The Spotify Model“ (или който и да е модел по този въпрос) всъщност няма да пресъздаде културата, която е довела Spotify - или която и да е от тези „най-добри в класа“ компании - да постигнат най-големите му печалби. Вместо да следва един-единствен готов за приемане оперативен модел, почти всяка история на успеха, която чух при изследването на Agile for Everybody, следваше три ръководни принципа на високо ниво:

  • Започвайки от клиентите и техните нужди, а не с цел, ориентирана към компанията
  • Сътрудничество рано и често в множество екипи (независимо от това как тези екипи са формално организирани), за да се идентифицират големи възможности, както и тактически зависимости
  • Планиране на несигурността в действителност, включване на нова информация с напредването на проекта

Екипи и организации, които наистина са възприели тези принципи, успяха не само да разбият големите предизвикателства на по-малки парчета, но и динамично да преосмислят как тези парчета се връщат заедно. Тяхната цел не беше да постигнат оперативна скорост или чиста автономност, а по-скоро да работят заедно за решаването на най-големите и най-важни проблеми, пред които са изправени клиентите им.

Път напред: От сребърни куршуми до еластични организации

Заглавието на тази статия е предназначено да бъде провокативно, но също така говори важна истина: всяка организация, която е твърде фокусирана върху оперативни, насочени към компанията цели като бързина, автономия или „следване на правилата на Agile рамка“, работи рискът да се дърпа по-далеч от клиентите си. Въпреки че стремежът за премахване на вътрешното триене е достоен, трябва да започнем с разбирането на външното триене, изпитван от нашите клиенти, и да работим неуморно (и съвместно), за да сведем до минимум това триене.

Ето няколко стъпки, които вашата организация може да предприеме, за да избегне бързината и автономността за сметка на клиентското изживяване:

  • Съпротивлявайте се на желанието да се измерва прогреса строго по оперативна скорост (т.е. честота на освобождаване или редове от код). Вместо това помислете за скоростта от гледна точка на вашия клиент - помагате ли им да постигнат целите си бързо и лесно? Или ги забавяте със сложни, фрагментирани преживявания?
  • Уверете се, че индивидуалните и екипните стимули не са толкова локализирани, че те косвено обезкуражават да отделят време и усилия за работа в екипи.
  • Ясно разграничете „добрите зависимости“ (т.е. възможностите за комбиниране на усилията или функциите в безпроблемно изживяване за клиентите) от „лошите зависимости“ (т.е. зависимости, които ненужно забавят способността на организацията да задоволява нуждите на клиентите). Бъдете особено бдителни в търсенето на ситуации, когато множество екипи вършат дублираща или излишна работа, често срещан проблем сред организациите, които се стремят да премахнат зависимостите и да насърчават самостоятелността.
  • Внимавайте за всички менюта и списъци за улов (като например „Изследване“ на Facebook), които могат да станат основание за отхвърляне на функции. Не забравяйте, че всеки нов артикул, който поставяте пред клиентите си, струва тяхното време и внимание.
  • Отвъд „ловкостта“, най-успешните организации са наистина еластични; тоест, те могат бързо да въртят нови организационни модели и структури без мащабна формална реорганизация. Един от непосредствените начини за изграждане на тази еластичност е формирането на временни „SWAT екипи“ с представители от множество нива, функции и екипи, базирани на функции, които да поставят изрично въпроса как работата на тези отделни екипи може да се комбинира, за да създаде по-добро клиентско изживяване. Като допълнителен бонус, опитайте да зададете на такъв екип задачата да изобретите изцяло целия продукт от нулата, независимо от съществуващия му набор от функции. (Ще пиша повече за еластичните организации и подхода на „SWAT Team“ в следваща статия.)

За повече информация по тази тема, надявам се, че ще разгледате новата ми книга Agile for Everybody. Както винаги, не се колебайте да се свържете с мен директно на matt@mattlemay.com, ако имате някакви мисли, съвети или предложения!