Ismerd meg a holland BENU gyógyszeripari vállalat sikeres átalakulását, a Scrum esettanulmány ismerteti, hogy hogyan sikerült, több mint 50%-kal növelni a vevőelégedettséget. Részletek a scrum.org esettanulmányában, ahol bemutatják, hogyan fejlesztették innovációs folyamataikat és csapataikat. Fedezd fel, hogyan érhet el a te vállalkozásod is hasonló eredményeket! 
Tanuljunk egymástól! 

A vállalat

A hollandiai BENU egy ismert gyógyszeripari és egészségügyi vállalat. Gyógyszertár hálózat, amely egészségügyi szolgáltatások és termékek széles skáláját nyújtja. Vényköteles és vény nélkül kapható gyógyszereket, valamint különféle egészségügyi termékeket és egészségügyi szolgáltatásokat kínál.
A BENU kiváló minőségű gyógyszerészeti ellátást és személyre szabott egészségügyi tanácsadást nyújt ügyfeleinek, célja az általános egészség és jólét javítása. A fő fókuszuk: az egészségügyi ágazatban egy ügyfélközpontú és az innovációra törekvő vállalat működtetése.

A Scrum esettanulmány kihívása

A BENU-nál egy 15 fős csapat dolgozik az ügyfelekkel való kapcsolattartás fejlesztésén, ők állak a Mijn BENU alkalmazás mögött is. Az alkalmazáson keresztül ügyfeleik többek között megnézhetik a gyógyszertörténetüket, recepteket tölthetnek fel, nyomon követhetik rendeléseiket, felvehetik a kapcsolatot a gyógyszertárral. Szerették volna még felhasználóbarátabbá tenni az alkalmazást a több mint 400.000 Mijn BENU feliratkozó számára.
Bár az alapvető – az ügyfelek számára elengedhetetlen – funkciókat megvalósították, és a Mijn BENU-fiókok száma napról napra nőtt, a csapat a felhasználóbarátabb, ügyfélközpontú részletekre is szeretett volna hangsúlyt fektetni. Viszont erre nem volt lehetőségük, mivel lefoglalta őket a hibák javítása és az optimalizálás. A funkciók bővítése sokáig tartott, és nem építették be az ügyfelek visszajelzéseit. A frissítések nagyon kiszámíthatatlanok voltak, és hónapokba telt, mire a csapat valami újdonságot fejlesztett.

Noha használták a Scrum-ot, nem élték a Scrum értékeit, csak a folyamatokat hajtották végre. A Sprint Retrospektívek során alig azonosítottak fejlődési lehetőségeket, javarészt panaszkodtak. A Stakeholder-ek pedig türelmetlenek voltak a csapattal szemben az új funkciók lassú megvalósítása miatt. Az ügyfél interakció és a fókusz hiánya negatívan hatott a termékinnovációs folyamatra, ahogyan az is, hogy belső Stakeholder-ek határozták meg a Product Backlog-ot. Sok volt a folyamatban lévő feladat (Work in Progress, WIP) és korlátozott volt a munka átláthatósága, mert a csapattagok elszigetelten dolgoztak egymástól.
A szervezetnek szándékában állt növekedni, a vezetés tudta, hogy változásra van szükség.

A megoldás

A BENU egy partneréhez, a Prowareness-hez fordult, aki segített a szükséges változtatásokban, és támogatta az agilis folyamatok jobb beépülését is.
Ivar Rameijs, a Prowareness agilis tanácsadója kezdett dolgozni a Scrum csapattal a Scrum részletesebb bevezetésén, néhány Kanban-gyakorlattal kiegészítve. Azért választotta ezt, mert bizonyos Kanban gyakorlatok segítenek jobban megérteni a munkafolyamatokat és feltárni, hogy hol nem működtek zökkenőmentesen a dolgok. Ennek köszönhetően segíthet rendezni a függőségi viszonyokat, valamint kezelni a nehézségeket nem csak a csapatnak, hanem a Stakeholder-ek számára is.

Kezdésképpen 2 kérdést tett fel a csapatnak:
– 1. Mi a legnagyobb frusztrációtok?
– 2. Mikor vagytok sikeresek?

Ivar a visszajelzések alapján elemzést végzett, és rájött, hogy nincsenek összehangolt folyamatok, hiányzik az ügyfélközpontúság. Így azon dolgoztak együtt, hogy következetessé és kiszámíthatóvá tegyék a folyamataikat. Ivar volt a Scrum Master, kijelöltek egy Product Owner-t, és 13 fejlesztő volt a csapatban.

Szimulációs játék, ami a Scrum esettanulmány alapját adta

Futtattak egy szimulációs játékot, hogy megértsék a vizualizáció és a sok, folyamatban lévő feladatok (WIP) hatását. Ennek köszönhetően rájöttek, hogy el kell kezdeniük sokkal láthatóbbá és átláthatóbbá tenni a munkájukat. Korábban a táblájukon csak >>Elvégzendő<<, »Finomítandó«, »Folyamatban« és »Kész« oszlopok voltak, valamint egy külön oszlop az elakadt/akadályba ütközött feladatoknak.

Javították a csapat számára a munkafolyamat megértését azzal, hogy minden fontos állapothoz amelyen a munka keresztül megy (pl. „fejlesztés”, „kódellenőrzés”, „tesztelés”) új oszlopot rendeltek. Gondoskodtak arról is, hogy az elakadt elemek láthatóvá váljanak a táblán a megfelelő munkaállapotban (és nem egy külön oszlopban), így biztosítva az átláthatóságot mindenki számára. Emellett láthatóvá tették a függőségeket, hogy azokat is kezelhesse a csapat.
A szimulációs játék (FeatureBan) egy másik tanulságot is hozott: összpontosítsanak a feladatok befejezésére, mielőtt új munkába kezdenének.

Megértették, hogy fontos befejezni a munkát, ami azzal jár, hogy az elakadt pontokat a lehető leggyorsabban meg kell oldani. Egyértelmű meghatározásra volt szükség, hogy tudják mikor kezdődött és mikor fejeződött be egy projekt. Ehhez egyértelmű definíciókat fogalmaztak meg például arról, mit jelent az, hogy „kész”. Ha a Sprint Backlog-hoz a Sprint során új feladatot akartak hozzáadni, azt az egész csapattal meg kellett vitatni, mert a Sprint végére be kellett fejezni. A napi Scrum során jobbról balra haladtak a táblán, hogy ez is segítsen a munka befejezésére összpontosítani.

A játék után a kísérlet következett

A szimulációs játék során megtapasztalták a folyamatban lévő feladatok korlátozásának néhány pozitív hatását (nagyobb fokú összpontosítás, a munka jobb átláthatósága, nagyobb kiszámíthatóság és több együttműködési lehetőség). Ezt a tapasztalást Ivar szerette volna, ha a való életben is átérzik, ezért kihívás elé állította őket: egy Sprint során csak 1 elemen dolgozott az egész csapat (szemben a korábbi 10-12 elemmel). Ezt „kísérletnek” nevezték el. Sokat tanultak ebben a Sprintben. Ez a kísérlet lehetővé tette a csapaton belüli jobb együttműködést, mivel az egész csapat ugyanarra összpontosított. Így jobban megismerték egymás adottságait és készségeit.

A Sprint során befejezték a feladatot, ami korábban szokatlan volt számukra. Általában több Sprintre lett volna szükség, mert a Business Analyst-ek (BA-k), akik elsősorban a következő Sprint elemeinek „előkészítéséért” voltak felelősek, nem ugyanazon az elemen dolgoztak, mint a fejlesztők. A kísérlet során ugyanazon az elemen dolgoztak. Ennek következtében a BA-k jobban bevonódtak és a Scrum csapat részének érezték magukat, ugyanannak a Sprint célnak a megvalósításán dolgoztak, mint a csapat többi tagja. Rájöttek, hogy nem szükséges „mindent” tudni, mielőtt elkezdenének dolgozni egy feladaton.

Néha egy-egy embereknek éppen nem volt teendője. Ilyenkor korábban a Sprint Backlog-ra húzták a teendőket, de most nem tehették meg, mivel a megállapodás szerint egy elemre kell koncentrálniuk. Ez eleinte zavaró volt, majd rájöttek, hogy kihasználhatják ezt az időt arra, hogy együtt írjanak kódot, tanuljanak valami újat, dolgozzanak a technikai hiányosságokon vagy a fejlesztések becsatornázásán. Ez is javította az együttműködést.

Rájöttek arra is, hogy meglehetősen nagy csapatuk van, a legtöbb szakterületet két ember képviseli. Az, hogy 15 emberrel dolgozzanak egy feladaton, nem volt hatékony, ezért úgy döntöttek, hogy két al-csapatra oszlanak, és Sprintenként két nagyobb feladaton dolgoznak, ezt „tosti” -nak (grillezett sajtos szendvics) nevezték el.

Minden „tosti”-nak megvolt a saját multidiszciplináris al-csapata, akik elkötelezték magukat a „tosti”-juk mellett. Ez a megközelítés lényegében két Sprint célt hozott létre, és segített a csapatoknak abban, hogy befejezzenek egy elemet, mielőtt egy új elem létrehozásába kezdtek. A fókuszált munkának köszönhetően egymás után háromszor is elérték a Sprint célokat, ami nagy előrelépés volt számukra. Nemrégiben a csapat két külön Scrum csapatra oszlott, az al-csapatokra építve. Ez még nagyobb fókuszt és hatékonyabb szerepvállalást eredményezett.

Sprint célok

Egy másik kezdeményezés volt a Sprint Célok meghatározása a Sprint Tervezés előtt. Ennek célja egy következetes és kiszámítható folyamat létrehozása volt. Korábban ez úgy történt, hogy a csapat a Product Backlog-ból a Sprint Backlog-ba húzta a munkaelemeket. Ez biztosította, hogy mindenkinek legyen valami tennivalója, majd ezek alapján létrehoztak egy Sprint Célt, amelynek azonban gyakran nem volt jelentősége az ügyfél, a termék vagy a Stakeholder-ek számára. Ehelyett most a Sprint Tervezés egy olyan Sprint Céllal kezdték, amely az ügyfélélményhez, az üzleti értékekhez vagy az elérendő eredményhez kapcsolódott. A Daily Scrum a Sprint Célra összpontosított ahelyett, hogy a feladatok sokaságán haladtak volna végig.

Az egyik legjelentősebb tanulság az volt, hogy nem kellett az összes feltételt leírniuk és a megoldást kitalálni, mielőtt egy Sprint keretében kidolgoznák azt. Rájöttek, hogy a jelenlegi funkciók optimalizálása más megközelítést igényel, mint az új funkciók kiépítése. Míg az optimalizálás esetében mindent el lehet dönteni a fejlesztés előtt, addig egy új funkció esetében szinte lehetetlen mindent előre tudni, és a feltételezésekre alapozott találgatás nagyon sok időt vett volna igénybe. Az új funkciók bonyolultsága abban rejlett, hogy el kellett fogadniuk, hogy nem lehet mindent előre tudni, és a fejlesztés megkezdésével tanulni és alkalmazkodni fognak. Jobban megértették, hogy szakítaniuk kell azzal a szokással, hogy az új funkciók és technikai fejlesztések esetében a Sprintek során vízesésszerű megközelítést alkalmazzanak. Ezután kevesebb időt fordítottak a túlelemzésre, szimulációkra, a követelmények részletes listázására, többszörös pontosítási ülésekre egy-egy elemhez. Ez az új megközelítés rövidebb átfutási időt eredményezett.

Áttérés az optimalizálásról az ügyfélfunkciókra

A Scrum csapatnak át kellett térnie az alkalmazás optimalizálásáról a tényleges ügyfélfunkciók létrehozására. A következő meglátások segítettek nekik ebben a váltásban, amelyeket a Scrum esettanulmány ismertet:

Product Backlog ownership: Korábban a Stakeholder-ek határozták meg a Product Backlog-ot, melynek következtében a csapattagok kevésbé tudtak összpontosítani és nem értették meg, hogy miért dolgoznak bizonyos elemeken. A Product Owner és a Scrum csapat átvette a Product Backlog-ot, a Product-, és Sprint Célokat, míg a Stakeholder-ek visszajelző szerepet kaptak.

A termék célok (Product goal) tisztázása: A Product Owner-t felkérték, hogy ismertesse, miért létezik a termék, és mikor tekinthető sikeresnek. Ennek eredményeképpen két ügyfélcsoportot azonosítottak: gyógyszertárak és gyógyszertári ügyfelek. Célkitűzésnek pedig a szervezeti növekedést és az ügyfélélmény növelését tekintették, valamint azt, hogy a gyógyszertárak is támogassák a Mijn BENU környezetet a vásárlóik felé.

Céltudatos priorizálás: Azokat az elemeket és Stakeholder kéréseket kivették a Product Backlog-ból, amelyek nem voltak összhangban az ügyfélcsoportokkal és a termékcéllal, így könnyítve a döntéshozást és a Stakeholder managementet.

Versenyelőny: Felismerték, hogy a versenytársaknál elérhető funkciók biztosítása alapvető, míg a megkülönböztető funkciók létrehozása kulcsfontosságú a versenyképességhez.

Ügyfélkérések vizualizálása: Az ügyfelek kéréseinek megjelenítése a Scrum táblán biztosította, hogy minden egyes Sprint tervezés során legalább egy ügyféllel kapcsolatos elem szerepet kapjon, így láthatóvá vált az ügyfelek ötleteinek és kéréseinek becsatornázása a folyamatba.

Ügyfél-együttműködés: Kezdeményezték az ügyfél-együttműködés javítását, elsősorban a gyógyszertárak manuális feladatainak csökkentését, ügyfelekkel való kommunikáció, és az ügyfélélmény javítását.

A vevői visszajelzések fontossága: Kiemelték, hogy a termékek sikeréhez elengedhetetlen az ügyféligényeinek jobb megértése, valamint az ügyfél-együttműködésre irányuló kezdeményezések

Az ügyfél-együttműködéssel kapcsolatos jelenlegi kezdeményezések

A Mijn BENU új menüszerkezetének prototípusait nemrégiben tesztelték az ügyfelek. Ennek keretében két különböző ügyféllel készült interjú, ahol a felhasználói benyomásokat gyűjtötték. Az ügyfeleknek három különböző fiktív feladatot kellett végrehajtani. Ezek például: vényköteles gyógyszer mennyiségének módosítása az automatikus utánrendelési rendszerben, allergiák utáni kutatás, valamint dohányzásról leszokást segítő tartalmak keresése. A feladatokon túl kikérték az ügyfelek véleményét az oldalak elrendezéséről, és szóhasználatáról. Megkérdezték őket az elvárásaikról, mint például arról, hogy mit várnak a „beállítások” gomb mögött?

Az interjú során arra kérték az ügyfeleket, hogy hangosan gondolkodjanak, ez érdekes és mulatságos pillanatokhoz, és ami a legfontosabb, az ügyfél jobb megértéséhez vezetett. A csapat egy felugró ablakot is készített, hogy visszajelzéseket gyűjtsön az ügyfelektől egy adott funkció használata után. Ezeket jelenleg is gyűjtik, majd elemezve beépítik a munkamódszerükbe, így zárva a visszacsatolási hurkot.

Sprint Vélemények

A kísérleti Sprint részeként a Scrum esettanulmány csapata egy új funkción dolgozott, amelyet a Stakeholder-ek a Sprint Review során tesztelhettek. Korábban általában a PO képernyőképeket mutatott be egy PowerPoint előadásban a teljesítettekről. Ezúttal azonban okostelefonokat és táblagépeket készítettek elő, amelyeket a Stakeholder-ek használhattak.

Az Stakeholder-ek lelkesek voltak, saját tapasztalataik alapján tudtak visszajelzést adni, és sokkal inkább bevonódtak.

Ettől a Sprinttől kezdve a Sprint Review bemutatóból közös munkamenetté változott a Stakeholder-ekkel. Végül is mindkettőjük alapvető célja, hogy valamilyen módon bevonzzák az ügyfeleket.

Flow Metrics használata

A csapat a Flow Metrics-et használta és használja a szolgáltatásuk javítására, a kimutatásokhoz pedig az ActionableAgile™ szoftvert. A Mijn BENU csapat saját meghatározásai szerinti paraméterekkel dolgoztak, és az alábbi változásokat érték el:

Ciklusidő: Egy munkaelem kitűzése és elkészítése közt eltelt idő.
A ciklusidő csökkent: 2023. januárjában 93 nap volt az az idő, ami alatt egy elem 85%-os valószínűséggel elkészült. Ez 89 napra (2023. szeptember), majd 80 napra (2024. február) változott.
Csökkent a szórás, így az eredmények kiszámíthatósága nőtt.

Áteresztőképesség: A két hét alatt leszállított PBI-k mennyisége.
A 95%-os eséllyel bekövetkező teljesítési képesség 3 tétel/ 2 hétről (2023. szeptember) 5 tétel/2 hétre (2024. február) javult. (A hibajavítások nem szerepelnek az áteresztőképesség mérésében).

/ha szívesen olvasnál a csapatok eredményességéről, nézd meg cikksorozatunkat/

Munkadarab kora: Az idő guillotine (Time Guillotine) nevű koncepciót használták, eszerint azok a munkaelemek, amelyek X napot töltöttek egy bizonyos oszlopban, automatikusan egy bizonyos színű címkét kaptak. Ezáltal kiemelkedtek, és megbeszélés tárgyát képezték.
Így például az „új” oszlopban szereplő elemek 180 nap után kaptak színt, hogy segítsék a PO-t a Product Backlog-ot naprakészen tartani. A „kész” oszlopban lévő elemek pedig 30 nap után kaptak színt, jelezve ezzel, hogy bár ezeket a tételeket életképes lehetőségként választották ki, de más tételek megelőzték őket. A háttér okok feltárása segített a csapatnak a ciklusidő lerövidítésében és abban, hogy a megfelelő tételeken munkálkodjanak.

Folyamatban lévő feladatok: Folyamatban lévő feladatok (WIP) határértéke (még) nincs kitűzve. De azzal, hogy egyszerre csak néhány elemre koncentrálnak (mint a tosti-k esetében), a csapat korlátozza a párhuzamosan folyamatban lévő elemek mennyiségét. Ezzel befolyásolják a ciklusidőket és az áteresztőképességet.

A visszaesés

Az említett változások többsége a 2023 szeptembere és decembere közötti időszakban zajlott. A csapat 2024 januárjában visszatért több régi szokáshoz és kezdték elveszíteni a fókuszt. Ez az időszak egészen 2024 márciusáig tartott. Tanultak belőle, hogy a későbbiekben elkerülhető legyen:

1. A téli szünet alatt a Sprintet 2 hét helyett 4 hétre hosszabbították meg, mivel a csapattagok és a Stakeholder-ek egy része szabadságon volt. A Sprintet „Mixed Grill”-nek nevezték el. Rengeteg apróság volt, többnyire csak egy-egy szakterületre vonatkozóan, javítandó hibák, kisebb optimalizációk stb. Mindenki dolgozhatott valamin egymástól függetlenül. Ez rendben volt egy olyan időszakban, amikor sokan vannak szabadságon. Viszont ez a következő Sprintekben is folytatódott. A csapatnak nem volt egyértelmű fókusza, elemek felé köteleződtek el (cél(ok) helyett) és minden Sprintben volt befejezetlen feladat.

2. Ebben az időszakban új PO került a csapatba, akivel meg kellett ismerni egymást.

3. Több Sprint során dolgoztak a bejelentkezési problémák csökkentésén, ami jó ügy az ügyfél számára, de ez többnyire Back-end munka volt. Közben dolgoztak egy új bejelentkezési portálon is, ami viszont Front-end munka volt. Ez azt jelentette, hogy a csapat nem ugyanazon a célon dolgozott, ami segítette a csapaton belüli régi szigetek újra megjelenését.

A visszatérés

Nehéz időszak volt Ivar számára Scrum Master-ként, aki észrevette, hogy visszazuhantak a régi szokásokba. Az elvégzendő munka típusa és a PO váltás miatt azonban nehéz volt változtatni.

Annak érdekében, hogy megoldják ezeket a problémákat, és a csapatot visszatereljék a korábban kijelölt ösvényre, Ivar a PO-val egyeztetve gondoskodott arról, hogy a Product Backlog-on legyenek olyan funkciók amelyeket az ügyfelek kértek, és amelyek a csapatot újra össze tudják hozni, hogy ismét a „tosti” megközelítést alkalmazhassák.

Ivar újra megkérdezte a csapattagokat, hogy mi a legnagyobb frusztrációjuk. Egytől egyig azt válaszolták: a koncentráció hiánya és a nem csapatban való munkavégzés.

A próbálkozások a 2024. márciusi utolsó sprintben változáshoz vezettek: ismét a „Tostis”-on dolgoztak. Ebben a Sprintben megállapodtak, hogy egyszerre maximum 2 elemen dolgoznak, vagyis csak akkor lehetett új elemet felvenni a Sprint Backlog-ba, ha az adott elemet a Sprint során be tudták fejezni. 

Scrum esettanulmány eredmények

Miután áttértek az új, Kanban gyakorlatokkal továbbfejlesztett a Scrum munkamódszerre, jelentős eredményeket értek el. A Scrum esettanulmány bemutatja, hogy nagy mérföldkő volt, amikor először, egymás után háromszor elérték Sprint céljukat, és újszerű egységet és gördülékenységet tapasztaltak a folyamataikban.
Következetes munkájuknak hála, az ügyfél-elégedettségi mutató 2,1-ről (2023. január) 3,19-re javult az App Store-ban, és 2,1-ről 4,1-re a Google Play Áruházban (2024. június).

A következő fejlesztések történtek:

• Jobban megértették a komplexitást. Felismerték, hogy nem határozható meg minden információ előre, így elfogadták a mantrát, mely szerint: „Részesítsd előnyben a haladást a teljes értékű információra várakozással szemben”.
• A Sprint Review a diasoros prezentációból egy olyan egyeztetéssé nőtte ki magát, ahol a Stakeholder-ek első kézből tapasztalhatták meg az új funkciókat/ az optimalizált működést. Ráadásul valós időben adhattak visszajelzést a fejlesztőknek.
• Az ügyfél visszajelzések közvetlenül a csapathoz is érkeztek, ahelyett, hogy azokat kizárólag az ügyfélszolgálat kezelte volna.
• Stabilabb teljesítés (nagyobb kiszámíthatóság): 93 napról 80 napra csökkentett ciklusidő és 3-ról 5-re az 5 hétre jutó projekt-teljesítés.
• Jelentős előrelépés történt a tesztelés automatizálása szempontjából, és elindultak a Test Driven Development felé.

További eredmények

Egy másik figyelemre méltó változás volt a csapat szorosabb együttműködése az ügyfélszolgálattal. Ennek köszönhetően a lakossági felhasználók körében tapasztalt bejelentkezési problémák 2%-ról kevesebb mint 0,7%-ra csökkentek. A problémák csökkenése miatt kevesebb ügyfélpanasz érkezett, ezért heti 4-6 órára csökkent a támogatással töltött idő (a korábbi a heti 32 órához képest).

• Jobb együttműködés,
• Elkötelezettség egy cél iránt,
• Éberség a Product Goal értelmetlenségére,
• Egymás szakterületeinek és a munkafolyamatainak a jobb megértése,
• Betekintési lehetőség, hogy hol megy zökkenőmentesen a munka, és hol nem,
• A Stakeholder-ek elvárásainak jobb kezelése, mivel rálátásuk van, hogy mit kaphatnak a Sprint végére.

A csapat mélyebben megértette a Scrum-ot, és Kanban-gyakorlatokat is beépített a munkafolyamataiba. Ennek köszönhetően jobban ráláttak és mélyebb betekintést nyertek a folyamataikba, beleértve a gátló tényezőket, a függőségeket és az elvégzendő munka típusának azonosítását. Jobban összpontosítanak a munka befejezésére, és világosabban értik, hogy mit jelent a „kész” fogalma. Ezen túlmenően most már kiemelten ügyelnek a különböző fejlesztési területekre (új funkciók fejlesztése, jelenlegi funkciók optimalizálására és a platform stabilitásának biztosítására) fektetett energia kiegyensúlyozására.

A csapat alkalmazza a Scrum értékeket. Arra ösztönzik a tagokat, hogy vitassák meg nyíltan, ha valami nem működik. Az együttműködésre is nagyobb hangsúly került, erőfeszítéseket tesznek a különböző szakterületek és csapatok közötti szakadékok áthidalására. Az ügyféltudatosság egy másik kulcsfontosságú előrelépés. Mára sokkal inkább tisztában vannak azzal, hogy kinek és miért dolgoznak. Jelenleg az ügyfelek igényeinek megismerésével foglalkoznak azáltal, hogy felkérik őket, osszák meg visszajelzéseiket a fejlesztőkkel és a Stakeholder-ekkel segítve ezzel optimalizálni a termékfejlesztést.

Szeretnél a csapatoddal hasonló transzformatív tapasztalatokat? Megfogott a BENU története, de nem tudod hogyan kezdj hozzá a változtatáshoz? Keress minket, segítünk!

Ha szívesen olvasnál más esettanulmányokat is, agilis blogunkon találsz még!