Índex de continguts
Introducció a Kanban
1603: inicis de Kanban
El 1603, després dels conflictes militars gairebé constants del segle XIV i l’agitació social del Japó, el país va entrar en un període d’estabilitat i creixement econòmic. A mesura que prosperava l’economia japonesa, els carrers de les ciutats s’omplien de botigues i negocis locals, que buscaven l’atenció i la consciència dels clients. És en aquests carrers, on neix el terme Kanban .
Kanban prové de dues paraules japoneses, “Kan”, que significa senyal , i “Ban”, que significa tauler . A mesura que els carrers i locals es tornaven cada cop més concorreguts, els propietaris de les botigues van començar a fer rètols personalitzats per atraure l’atenció dels transeünts i explicar-los els serveis que cadascú oferia.
De mica en mica, els japonesos van anar utilitzant aquestes targetes amb diferents dissenys, per la qual cosa és molt freqüent trobar targetes de Kanban amb forma de peix per a botigues de pescadors, o en forma de pipa de fusta, per a botigues de pipes.
Totes aquestes targetes tenien una cosa en comú entre elles i respecte a les targetes Kanban que coneixem avui dia i visualitzem a les nostres eines de treball com Jira, comuniquen un missatge de manera clara i concisa . El missatge en aquest cas era saber quantes persones hi havia dins de les botigues, o el que és el mateix, controlar l?aforament d?espais públics o comerços.
1940: Lean Manufacturing a Toyota
Produir només allò que es necessita, quan es necessita i en la quantitat necessària (Taiichi Ōno).
A la dècada dels 40, Toyota no s’imaginava que acabaria sent el gegant industrial que és avui dia. Després de la II Guerra Mundial, la indústria automobilística es trobava estancada. Toyota es veia incapaç de competir amb els fabricants automobilístics nord-americans com Ford, l’empresa només tenia pèrdues. Com que no tenia beneficis, tampoc podia contractar més personal. És llavors quan el CEO de Toyota, Kiichiro Toyoda, es va adonar que la diferència de la seva empresa amb les nord-americanes (les americanes produïen deu vegades més) no s’arreglaria contractant més personal, la solució era una mica més complexa.
Toyota va apostar per la innovació i l’optimització de l’organització de la feina. Aquest canvi de cultura empresarial va aplanar el camí a Taiichi Ōno, un jove enginyer industrial. Ōno tenia un caràcter estricte, cosa que definiríem com a “suau però ferma”, cosa que li va permetre ascendir ràpidament a la jerarquia de l’empresa. El 1949, es va convertir en gerent de botiga de màquines, on va començar a experimentar amb noves eines i principis de l’organització del treball. L’any 1954 va ser ascendit a un lloc de director.
Ōno identifico i categoritzo 7 tipus de deixalles, o el que a Toyota es coneix com Muda :
De les 7 deixalles identificades per Ōno, la sobreproducció i l’ inventari que tenien de matèries primeres, eren les que més el preocupaven. Què va fer Ōno després d’aquesta anàlisi? Produir el que es necessitava quan es necessitava . Una resposta lògica per al món actual en què vivim, però revolucionària a la dècada dels cinquanta.
Això volia mantenir els estocs al mínim mentre s’assegurava un flux de treball suau a través de tot el procés. Però com identificarien quan caldria un nou producte? I el més important encara, com avisarien la línia de producció i els proveïdors de matèries primeres? Inspirat pels comerços detallistes i les seves targetes Kanban, Ōno va decidir visitar les cadenes de supermercat Piggly Wiggly el 1956 i va quedar impressionat en com mantenien els prestatges amb la quantitat justa de producte. Quan va tornar al Japó, va començar a utilitzar les targetes Kanban en paper per senyalitzar i rastrejar la demanda a la fàbrica de Toyota. Així neix el sistema Kanban.
Toyota feia servir les targetes Kanban a cada cotxe acabat, de manera que quan el cotxe s’entregava al client, la targeta tornava a la línia de producció. Els treballadors només podien treballar en un cotxe quan la targeta que identificava una demanda hi tornava en el flux de treball, i només quan el nombre de targetes Kanban pendents arribava a un llindar definit. De la mateixa manera, cada material utilitzat a la cadena de producció, tenia la seva pròpia targeta, de manera que el senyal de demanda fluís cap avall a través de tota la cadena de producció, acabant en proveïdors externs.
Aquest sistema va reduir els inventaris , va millorar el rendiment i va proporcionar una alta visibilitat del procés . El seu ús es va estendre com la pólvora a tota la divisió de mecanitzat. El 1963, es va desenvolupar un pla per propagar-lo a tota l’empresa, i poc després va adoptar gairebé tots els processos de Toyota.
Toyota va passar d?operar amb pèrdues, a ser el competidor global que és avui. Ōno va ascendir per tots els rangs superiors de la companyia, convertint-se en vicepresident executiu el 1975. El seu treball va donar lloc al nou significat de Kanban i va establir les bases tècniques modernes de gestió, conegudes com a Sistema de Producció Toyota .
2003 – 2008: Kanban a la indústria del Programari
A mesura que el sistema de producció Toyota guanyava popularitat, els gerents de projectes de diferents tipus d’indústria intentaven aplicar el sistema als seus treballs.
En aquest moment, la gestió de projectes al món del programari s’anava allunyant gradualment de processos molestos i ineficients cap a un enfocament més lleuger i àgil . Va ser l’any 2001, que es publica el Manifest Àgil , on es promouen, entre d’altres, acceptar els canvis en els requisits i lliurar programari funcional amb freqüència . Tot i així, el Manifest no especifica com aconseguir-ho. És aquí quan diversos sistemes de gestió comencen a omplir aquest buit, els més coneguts actualment són Scrum, eXtreme Programming (XP), i el Desenvolupament de Programari Lean.
Els tres mètodes de treball van tenir un impacte significatiu en allò que estava a punt de convertir-se com el mètode Kanban.
- Scrum : molts equips de Scrum feien servir taulers amb targetes d’històries d’usuari (US) per mostrar i visualitzar la informació. Durant la planificació de l’Sprint, cada US o feature s’escrivia en una targeta separada. Juntes, aquestes targetes formaven allò que coneixem com el backlog de l’esprint i es col·locaven en un tauler gran en un espai de l’oficina on tot l’equip el pogués veure. Cada membre de l’equip podia acostar-se al tauler, mirar les US i triar la targeta amb què treballaria. Quan completaven la feina, tornaven la targeta al tauler, amb les paraules ratllades. Aquest sistema era simple però eficaç. Proporcionava una alta visibilitat del progrés, permetent la sincronització del treball entre els programadors i millorava el flux del treball ja que cada desenvolupador podia triar el tipus de feature en què se sentia millor treballant.
- Desenvolupament de Programari Lean : el 2003, Mary i Tom Poppendieck van publicar el llibre Lean Software Development: An Agile Toolkit , on van traduir els principis de la fabricació Lean del Sistema de Producció Toyota al desenvolupament del programari i el treball del coneixement. El llibre se centra en l’eliminació de deixalles, el mapeig del flux de valor i els sistemes pull. El 2007, els mateixos autors van publicar el llibre Implementing Lean Software Development: From Concept to Cash , que explora més l’ús de la teoria de cues per reduir els temps de lliurament del programari i els taulers Kanban com a element de l’espai de treball visual. El 2005, Jim Sutton i Peter Middleton van publicar Estratègies de Programari Lean , on identificaven els 5 principis de la producció llegeixin en el desenvolupament de programari:
- Definir el valor
- Mapejar el flux de valor
- Implementar el flux
- Mantenir un procés pull
- Buscar oportunitats de millora
- Gestió Àgil: a banda de Scrum i de Lean, també es van explorar altres conceptes sobre com els equips es podien tornar més àgils. El 2004, David Anderson va publicar el llibre Gestió Àgil per a Enginyeria de Programari: Aplicant la Teoria de Restriccions per a Resultats Empresarials , on es cobreixen conceptes com flux, coll d’ampolla, control visual i diagrama de flux acumulatiu, tots els quals s’incorporen posteriorment al mètode Kanban. En aquest moment, equips que feien servir taulers de Scrum, van adoptar aquestes noves tècniques i van reorganitzar els seus taulers introduint columnes que representaven les diferents etapes del treball, donant origen així als taulers Kanban.
Els taulers Kanban, combinats amb:
- Els Mètodes de Desenvolupament de Programari Lean i Gestió Àgil;
- La Programació Pull;
- La Limitació del Treball a la Capacitat; i
- El mesurament del flux
…van donar lloc al desenvolupament de programari estil Kanban. Aquest Kanban primerenc va ser acceptat com a sistema propi, ja que ajudava amb totes aquelles coses en què Scrum no era particularment bo, com escurçar el temps de cicle des de la sol·licitud del client fins al lliurament, assegurant un flux constant de treball.
A mesura que l’adopció del desenvolupament de programari amb Kanban creixia lentament, alguns pioners van ajudar a difondre el coneixement sobre això i donar forma al futur definitiu.
Microsoft va ser dels primers a introduir els principis de Kanban. Per augmentar la productivitat, van afegir elements de Scrum i Kanban com a extensió del model existent de Feature Crew i el mètode de Bug Jail . Això va donar com a resultat el primer projecte Scrumban el 2004.
David Anderson, Dominica DeGrandis, Corey Ladas i Daniel Vacanti van introduir el sistema Kanban a Corbis el 2007, on van introduir el concepte de carrils de natació per mantenir els elements de treball relacionats, junts. La implementació i la difusió de l’èxit a Corbis va despertar l’interès en altres empreses sobre el mètode Kanban.
Karl Scotland va escoltar sobre el mètode Kanban en una conferència d’Agile el 2007, de la mà de David Anderson, de manera que va decidir introduir-lo al seu equip de Yahoo! ja que tenien un problema de durada de l’esprint amb Scrum. La implementació va ser tan reeixida, que Karl es va convertir en un dels primers i més prominents defensors del mètode Kanban.
2009: l’any daurat per a Kanban
Al gener de 2009, Corey Ladas publica el llibre Scrumban: Essays on Kanban.
A l’abril del mateix any, Henrik Kniberg publica Kanban vs. Scrum: A Practical Guide , un article on es cobreixen els principis de Kanban de manera fàcil d’entendre.
Al maig, a la conferència Lean Kanban 2009 organitzada per Anderson a Miami, es van presentar els últims desenvolupaments en l’aplicació del Pensament Lean al desenvolupament de programari. Després d’aquesta conferència, es va formar la Societat Informal del WIP Limitado , amb la missió d’unificar i difondre el coneixement sobre el mètode Kanban. Aquesta societat va proporcionar una plataforma per a l’agregació d’articles sobre Kanban, que va ajudar a augmentar encara més la consciència del mètode.
També el 2009 es van llançar les primeres aplicacions web per gestionar projectes i processos empresarials amb el mètode Kanban: Agile Zen , Kanban Tool i LeanKit Kanban .
2010 en endavant: Kanban per a tots
A mesura que el coneixement i l’ús de Kanban es popularitzava, va quedar clar que Kanban funciona en el desenvolupament de programari i també en qualsevol procés que contingui repeticions (fabricació, vendes, màrqueting, reclutament, etc.). Fins i tot l’ exèrcit dels Estats Units va començar a adoptar els principis.
Al març de 2010, Henrik Kniberg i Mattias Skarin van publicar Kanban i Scrum – Making the Most of Both . A l’abril del mateix any, David Anderson va publicar Kanban: Successful Evolutionary Change for Your Technology Business . El 2011, Jim Benson i Tonianne DeMaria Barry van publicar Personal Kanban . De mica en mica, van començar a aparèixer nombrosos altres llibres i articles en línia sobre Kanban, documentant experiències individuals i les seves diverses aplicacions.
El 2016, es va publicar Essential Kanban Condensed , on es destil·len les 5 pràctiques d’aquest mètode que explicarem més endavant.
Kanban per què?
Com hem vist a l’apartat anterior, el mètode Kanban el podem fer servir en una varietat de contextos per millorar la gestió i el flux de treball.
Determina si Kanban és adequat per al teu equip
A la metodologia Scrum, després de l’Sprint Planning, el backlog queda congelat, de manera que no s’hi poden fer canvis. Aquest estat sol durar uns 15 dies en general, cosa que pot arribar a generar frustració tant per als desenvolupadors com per als clients finals.
Què fem si hi ha una emergència i una funció específica ha de ser implementada ASAP?
Què fem amb tots els bugs descoberts al producte en viu: els clients finals necessiten esperar entre dues setmanes i un mes perquè els arreglin?
Com fem servir processos que són més dinàmics per naturalesa, com el màrqueting de llocs web o l’administració de servidors?
El mètode Kanban, amb els seus taulers Kanban i enfocament al flux, es converteix en una resposta a aquests dubtes, proporcionant una forma altament estructurada, visible i flexible de gestionar el treball.
Altres preguntes que et pots fer al teu equip per veure si Kanban és el model que més s’ajusta a les teves necessitats són:
- Des d’una perspectiva d’Agile Màster, Agile Coach o Product Owner:
- L’equip sap identificar i plasmar visualment el flux de treball?
- Tenen colls d’ampolla? Estan identificats?
- Són conscients de la feina que fan entre ells?
- Demanen flexibilitat per adaptar-se a la demanda impredictible que els atropella constantment?
- Quin nivell destructura busquen en la gestió de projectes i processos?
- Preguntes per fer a l’equip:
- Teniu dificultat per gestionar les tasques de l’Sprint?
- Quin mètode d’estimació feu servir? Creieu que us funciona?
- Teniu visible i compartit algun tauler de treball? Ho enteneu?
- Considereu que hi ha transparència i comunicació a l’equip?
- Estem disposats a comprometre’ns amb la millora contínua ia començar a experimentar canvis?
- Us agradaria tenir més autonomia i responsabilitat en la gestió pròpia de la feina?
- Quins aspectes del procés actual milloraríeu o optimitzaríeu?
- Hi ha acords d’equip?
- Compartiu la mateixa visió i enteneu el mateix per a cada estat de treball?
Kanban és molt més que un tauler bonic amb Pòsits de colors movent-se cada dia. És una eina que ens permet optimitzar un procés mitjançant la visualització. Ens ajuda a millorar els fluxos de feina en qualsevol procés productiu.
Les 5 practiques del llibre Essential Kanban Condensed són:
- Visualitzar el flux de treball
- Limitar el treball en curs
- Mesurar i gestionar el flux
- Definir polítiques explícites
- Implementar cicles de feedback
- Evolució experimental per a la millora col·laborativa
1-Visualitzar el flux de treball
Visualitzar el flux de treball és crucial, i un dels principis essencials del mètode Kanban. Amb la visualització, obtenim transparència . En tenir un mateix tauler amb tots els elements de treball visibles per a l’equip i l’organització, tots tenen clar què cal fer, en què estic o estan els meus companys treballant, quan s’espera que es completi el treball i què hem lliurat .
La visualització us ajudarà a entendre bé com està treballant actualment l’equip, cosa que alhora us permetrà descobrir per què es fan les coses d’aquesta manera descobrir per què es fan les coses d’aquesta manera i posteriorment podreu prendre decisions concretes i objectives per millorar .
Com visualitzem el flux de treball?
El flux de treball és la seqüència de passos que les tasques o el producte travessa des de l’inici fins a la finalització o el lliurament. A Kanban, la visualització del flux significa mapejar passos distintius del treball a les columnes del tauler Kanban i seguir els elements de treball mentre s’avança a través d’aquests estats. El simple fet d’anomenar aquests estats pot revelar fets sobre el flux que no coneixies, fins i tot detectar colls d’ampolla.
Els passos per identificar el flux de valor són:
- Identificar el flux : el mapeig del flux és el procés mitjançant el qual posem un nom als estats pels quals passa la tasca, estats que afegeixen valor. Pots ajudar-te a verbalitzar les activitats (analitzar, desenvolupar, testejar, etc.). El flux ha de proporcionar claredat, facilitant saber en quines accions ens hem de centrar i quines hem de minimitzar perquè no tenen sentit per al client final, cosa que anomenaríem com a “malbaratament”.
- Identifica l’abast del treball : un cop s’hagi dibuixat el flux de valor, l’equip ha de decidir quines parts controlem, en què volem centrar-nos i com el visualitzarem en un tauler Kanban. Si considerem el flux com un mapa, hem de marcar el camí per on passen les tasques. Com més estret i uniforme sigui l’equip que treballa al flux, més simple serà la gestió del treball. Tracta de no incloure cap pas del procés sobre el qual l’equip no tingui veu ni impacte, ja que crearà incertesa i confusió.
- Associa les etapes del flux de treball a columnes en un tauler : pots recolzar-te en un tauler físic i visible a l’oficina o bé utilitzar una eina digital com Jira. Dividiu el tauler en columnes, cadascuna de les quals serà una etapa del flux, de dreta a esquerra. Si tens diferents classes de servei, pots ajudar-te de swimnlanes per dividir-los en files horitzontals.
- Defineix els tipus de treball i què significa el concepte de “Done” o lliurat per a l’equip : el primer pas és definir els tipus de tasques en què treballa l’equip i diferenciar-los amb icones o colors. Assegureu-vos que l’equip coneix el significat de cada color o icona i quines són les definicions que heu acordat per a cada element de treball.
- Defineix sobre una plantilla de targeta cada element de treball : per a cada element de treball, defineix amb l’equip quina informació essencial cal veure i què s’espera a cada targeta. Es poden definir diferents plantilles de targetes en funció dels tipus de treball o lliurables que tinguem, on es ressaltin i facilitin lintercanvi dinformació mínima imprescindible.
- Comença a treballar!: ara que has definit colors, formats, icones, columnes i swimlanes, i el templat de les targetes, ja pots començar a col·locar-les a les columnes rellevants del tauler, segons l’estat de treball que es trobin actualment. Dins les columnes individuals, ordena les targetes segons prioritat. La targeta més urgent ha d’anar a la part superior seguida de la segona més urgent i així successivament. Amb això, solucionem el clàssic problema de si tot és urgent, llavors res no ho és .
- Realitza un seguiment del flux i revisa el procés periòdicament: seguir el flux d’estats us permetrà veure els colls d’ampolla, els bloquejos i els estats on l’equip es troba sobrecarregat. És crucial que el tauler es visiti diàriament i que les targetes estiguin actualitzades per visibilitzar.
2-Limitar el treball en curs (WIP)
Limitar el WIP (Work in Progress) és una característica fonamental de Kanban. Pot semblar contraintuïtiu de primeres.
Estem dient als equips que treballi menys?
No. Limitar el treball en curs significa limitar totes les tasques que es poden dur a terme simultàniament, no limitar el treball a realitzar. Amb això reduïm els temps d’espera com els cicles.
Per què limitar el treball en curs?
- Fomenta una cultura de finalització del treball : comença a acabar, deixa de començar. Què prefereixes tenir 40 productes a mig camí de ser llançats o 25 llançats i generant ingressos? Limitar el treball significa centrar-se en aquests 25. La limitació ajuda a concentrar-se en les tasques, cosa que promou acabar abans i monetitzar. Com ens ajuda això amb els blockers? Imagina’t que el teu equip està treballant als 40 productes alhora, si hi ha un incident greu, haurà de paralitzar la feina d’aquests 40 productes. No és millor paralitzar-ne 25?
- Minimitza la multitasca i el caos : si limitem el treball en progrés, reduïm el soroll i gestionem millor el caos. Si et llanço una pilota de tennis, l’agafaràs fàcilment amb les dues mans. Si et llanço dues pilotes al mateix temps, pots agafar-ne una amb cada mà, agafar-ne només una, o no agafar-ne cap. I si et llanço 10 pilotes de cop? Probablement no n’agafaries cap: caos. Passa el mateix si treballem en moltes tasques alhora. Mantenir lenfocament constant en una tasca millora la qualitat del treball.
Com començo?
- Observa el procés i identifica colls d’ampolla : observa el tauler, fixa’t si l’equip està sobrecarregat, així podràs identificar colls d’ampolla.
- Ajusta el límit del WIP : limita el treball en curs a la capacitat de l’estat del flux més lent. Parla amb l’equip, analitza per què es crea un coll d’ampolla en aquest pas (falten recursos? Són permisos? Potser dependències externes?).
- Analitza i revisita els límits : a mesura que el procés canviï, l’equip creixi, disminueix o canviï, és possible que necessitis ajustar el límit.
3-Mesurar i gestionar el flux
Però què és el flux?
El flux és el camí pel qual passa la feina per diversos departaments o diversos nivells de producció. És lexperiència única de cada treball que viatja a través del procés.
Una tasca es pot moure pels estats sense problemes, o pot tenir alguna interrupció en un estat?
Segurament en algun moment t’haurà frustrat començar una tasca i haver de pausar-la una o més vegades perquè necessites que algú et confirmi algun detall, que et donin permisos, o fins i tot que hagi sortit una altra tasca més urgent que has de resoldre immediatament. En aquests casos, el flux s’interromp.
A la primera pràctica hem vist com visualitzar el flux, a la segona, com es mouen les tasques mitjançant el flux. Mesurant i gestionant el flux analitzem com aquestes dues rutines impacten en el flux i ho millorem.
Com ho mesurem?
Amb reunions diàries o Daily Kanban. En aquestes reunions que se solen fer a primera hora del matí entre 30 i 45 minuts, s’analitza com la feina es va movent d’un estat a un altre. Pots ajudar l’equip a identificar quant de temps els fa que una tasca es mogui d’una columna a una altra. Quan les tasques es bloquegen o s’embussen a les columnes, ens hem de preguntar per què. A partir d’aquí, podrem començar a pensar quines accions farem per posar-hi remei.
El que és important no és que les tasques es moguin ràpid, sinó la suavitat amb què es mouen de principi a fi, és a dir, sense bloquejos.
Et proposo algunes preguntes per fer a la Daily Kanban:
- Algú està bloquejat?
- Amb què et puc/podem ajudar per desbloquejar-te?
Quines mètriques puc fer servir?
- Diagrama de flux acumulatiu : amb aquesta mètrica podràs veure la quantitat de treball en progrés que hi ha a cada estat. La uniformitat d’aquest diagrama et dirà què tan uniforme i predictible és el teu equip.
- Lead Time i Cicle Time : el Lead Time mesura el temps de lliurament, és a dir, fa una mitjana de temps entre que es comença a treballar en una tasca ( In progress ) fins que es lliura ( Done ). El Cicle Time mesura el temps des que la tasca entra com a petició al backlog ( To Do ) fins que es lliura ( Done ). Amb aquestes dues mètriques podreu saber i predir el temps que triga l’equip a produir.
Gestionar i mesurar el flux us ajudarà a:
- millorar el procés en general i deixar d’apagar incendis;
- millorar la previsibilitat del procés;
- Madurar el procés i us ajudarà a entendre que és menys important; i
- Preveure de manera objectiva els temps.
4-Definir polítiques explícites
Les persones solem fer suposicions sobre tot allò que ens envolta. Algunes vegades de manera inconsistent, d’altres conflictives. Això sol provocar malentesos i que el treball en equip sigui ineficaç. El procés repetitiu i la qualitat de lexecució de cada pas és el que acaba lèxit del treball realitzat. També orienta l’equip sobre com prendre decisions, de manera que els permet avançar en el procés de la millor manera possible.
Què entenem per política a Kanban?
Una política a Kanban es refereix a un coneixement comú sobre què s’ha de fer a cada estat de treball per poder passar al següent. L?objectiu final és que es converteixi en una rutina de l?equip, de manera que els ajudi a mantenir el flux.
Tingues en compte el següent:
- Nosaltres som els amos del procés, no al revés. Els processos no ens pertanyen.
- Sigues pragmàtic en definir les polítiques.
- Crea un control visual que et permeti veure quina feina s’està executant i quins passos segueixen a cada estat.
- Les polítiques han d’ajudar els equips a ser autoorganitzats i desenvolupar relacions.
Imagina les polítiques del teu equip com el Pont Golden Gate, han de ser fortes perquè la feina flueixi sense problemes ni futurs incidents. Quan vegis que les tasques solen embussar-se en algun estat, aprofita per fer preguntes sobre què podem millorar o introduir perquè això no passi.
Les polítiques han de definir què necessitem que estigui fet de cada estat de manera simple i visual. Les preguntes següents poden ajudar-te a establir polítiques amb el teu equip:
- ¿L’equip té clar el flux de treball, on comença una tasca i on s’acaba?
- L’equip sap quins són els passos de control de qualitat?
- L’equip entén el mateix per “acabat” a cada etapa del flux?
- L’equip sap com prioritzar una tasca urgent i la implicació que tenen per a ells i el flux?
- L’equip té clar com tractar les tasques no planificades i com encaixar-les al flux?
- Com es tracten els incidents que es troben al procés? Detenen el que fan tots i solucionen l’error? Torneu a posar la tasca de l’incident al backlog?
5-Implementar cicles de feedback
“Kanban hauria de conduir a la millora diària, la millora de tots i la millora a tot arreu.” (Masaaki Imai)
Kanban és una metodologia que pren cada iteració com una nova oportunitat de millora. Amb Kanban no necessites canviar immediatament, sinó començar exactament des d’on ets, simplement observant, a partir d’aquí, pots treballar en els 5 passos d’enfocament de la Teoria de les Restriccions:
- Identifica els colls d’ampolla : observa el tauler i com flueix el treball per identificar on el flux de treball canvia dràsticament i s’estanca.
- Explota els colls d’ampolla : els colls d’ampolla no coincideixen amb la capacitat d’altres estats de treball. Sabent que la velocitat a què el coll d’ampolla completa el treball és la velocitat de finalització del treball de tot el sistema, decideix com subministraràs millors recursos a aquest estat més lent. Fes-ho a un ritme que no aclapari el flux ni l’equip.
- Subordineu-ho tot als colls d’ampolla : el flux de treball i les polítiques establertes han d’estar sincronitzades amb el pas del procés més lent, de manera que s’evitin o minimitzin els impediments.
- Elevar els colls d’ampolla : necessitaràs enfortir l’estat invertint en millores com són els recursos, el límit d’estats o altres alternatives que consideris.
- Observar on ocorren els colls d’ampolla : és important monitoritzar el procés. És comú que hi hagi colls d’ampolla, de manera que haureu de repetir els passos 2 a 5 per resoldre’ls.
L’eliminació de deixalles o Muda us ajudarà a analitzar les tasques actuals en el flux de valor ia identificar aquelles que no afegeixen valor directe al vostre producte o projecte. Si el teu equip respon sempre s’ha fet així quan els preguntes per algun pas, és hora de qüestionar el propòsit i canviar-lo.
És important que com a líder identifiquis les deixalles i les distingisques entre les necessàries i les innecessàries. Reduir les activitats que no estan directament relacionades amb el valor del producte us permetrà millorar.
La confiança en el client es guanya quan un servei és fiable i predictible. (W. Edwards Deming)
6-Evolució experimental per a la millora col·laborativa
Per estar alineats amb la millora contínua de Kanban, podem utilitzar els cicles PDCA .
Els cicles curts de PDA es basen en:
- Pla : s’identifica una activitat a millorar i es comunica a l’equip. Idealment, tots els involucrats haurien d’estar inclosos al procés de millora.
- Do : en aquest moment s’executa el pla del pas anterior. Aquest ha d’estar en línia amb la implementació de polítiques i procediments explícits. Pren mesures tangibles que hagin sortit del pas anterior.
- Check : avalua les accions dutes a terme al pas anterior. Vincula-les amb la gestió i el mesurament del flux de Kanban del teu equip.
- Act : entenem actuar com avaluar si els canvis que hem fet a l’etapa anterior han donat resultats positius o esperats. Si no ho han estat, vol dir que es poden eliminar, ajustar o millorar. En aquest cas, tornaríem a començar des del primer pas.
Com començar
Si vols que t’ajudem a començar amb Kanban, pots contactar-nos , o pots seguir aquesta guia simple.
A la primera fase, la d’ aixecament , és important que, com Agile Master, et reuneixis com més aviat millor amb l’equip i el Product Owner per entendre la demanda .
Anàlisi de la Demanda
Com Agile Màster, fer l’anàlisi de la demanda com a primer pas us ajudarà a:
- Comprendre el context : en aterrar en un equip és important que entenguis l’entorn en què opera l’equip, les expectatives dels seus stakeholders i les necessitats de negoci respecte a l’equip. Això us ajudarà a tenir una primera imatge i idea que us ajudarà, posteriorment, a planificar i executar les activitats de millora i la implementació de Kanban.
- Identificació de prioritats : analitzant la demanda, podràs identificar les prioritats de l’equip. Alhora, veuràs si l’equip comparteix les mateixes prioritats, si estan establertes o si hi has de posar èmfasi. Amb les prioritats clares i compartides, podràs ajudar l’equip a fer una assignació efectiva de recursos i esforços per abordar els reptes que tenen.
- Abast de millores : quan facis l’anàlisi de la demanda, tant tu com Agile Màster com l’equip mateix identificareu oportunitats de millora en àrees on es poden implementar canvis. És molt probable que l’equip ja tingui clares aquestes àrees de millora. Deixa’ls parlar, escolta’ls i anota les seves preocupacions, inquietuds i idees.
- Alineació amb els objectius de Negoci : un cop analitzada la demanda, podreu veure si l’equip està alineat amb els objectius i les prioritats de Negoci. Veuràs també si lliuren valor real, i en cas que no sigui així, els podràs ajudar a canviar els fluxos perquè així sigui.
Reuneix l’equip complet, preferiblement in situ a les oficines. Si no el pots reunir presencialment, fes-ho online i recolza’t d’eines visuals com Miro.
L’objectiu d’analitzar la demanda de l’equip és entendre:
- Qui demana a l’equip
- Què els demanen
- Com els arriben aquestes sol·licituds (xat de Teams, correu, petició de Jira, xerrada informal, etc.)
- Quin percentatge de la demanda total representa cada sol·licitud
- Com prioritzen cada tipus de sol·licitud, sigui per classe de servei o per sol·licitant
Et pots donar suport a les següents preguntes a fer-los:
- Qui és el vostre Business Owner? Centralitza totes les peticions que rebeu de negoci?
- Com us fa arribar el vostre Business Owner les peticions?
- Us prioritza el Business Owner les diferents peticions de negoci que us fa arribar?
- En cas que no tingueu un sol Business Owner, quines persones de Negoci us fan sol·licituds?
- A quins departaments o productes pertanyen aquests Business Owners o sol·licitants de Negoci?
- Per quin canal us fan les sol·licituds?
- Teniu reunions periòdiques amb ells o un espai on fer les peticions i fer seguiment de les iniciatives?
- Us arriben sol·licituds del vostre Head of Product? Quin tipus de sol·licituds són? Per quin canal us arriben? Solen ser urgents?
- Altres equips us realcen sol·licituds?
- Quina mena de sol·licituds són (cross, dependències, etc.)?
- Per quin canal us arriben les sol·licituds d’altres equips?
- Quin percentatge de cada sol·licitant representa la càrrega habitual de treball per a l’equip?
- Com prioritzeu aquesta demanda?
- Com gestioneu les demandes urgents dels diferents sol·licitants? Teniu una matriu o acords d’equip sobre la priorització de la demanda?
- Us sincronitzeu amb altres equips amb què teniu projectes o iniciatives conjuntes?
- Totes les sol·licituds són a Jira? Qui crea els tiquets?
- Els tiquets de Jira estan detallats amb tota la informació? Qui detalla aquesta informació? I quan (Planning, replenishment, dailies, etc.)?
- Si l’equip no té clar què es demana en un tiquet, amb qui el gestiona (amb el Product Owner, amb el Business Owner, sol, etc.)?
- Teniu una plantilla als tiquets de Jira amb la informació necessària (què cal, per què, passos a seguir, etc.)?
- Teniu Definition of Done i Definition of Ready compartits i visibles a Jira per a l’equip?
Amb l’ajuda d’aquestes preguntes, anireu anotant a diferents Pòsits l’anàlisi de la demanda. És recomanable que s’utilitzin diferents colors de Pòsits per tipus d’informació (sol·licitant, percentatge, urgència, categoria de la sol·licitud, etc.). D’aquesta manera, serà més visual.
Incentiva que siguin ells també els qui moguin els Pòsits o les fletxes si cal, fes-los partícips del procés, han d’entendre que l’exercici també és important perquè ells comparteixin com veuen la demanda i com l’entenen.
Mapa Producte, Negoci, Equip
Ara que tenim la demanda dibuixada de manera visual i compartida amb l’equip, és hora de detallar una mica més com es relaciona respecte a les tecnologies, la predictibilitat i l’equip.
Amb aquest exercici, podràs fer:
- Alineació estratègica : relacionant la demanda amb els productes, el negoci, la tecnologia i l’equip us proporcionarà una visió clara de si l’equip es troba alineat amb l’estratègia general de l’organització. D’aquesta manera, us podem ajudar a evitar les deixalles de temps i recursos que no contribueixen directament als objectius de l’organització.
- Identificar oportunitats : podràs analitzar les tecnologies utilitzades per l’equip actualment i veure si es poden millorar. D’aquesta manera, es podran resoldre incidències, millorar l’eficiència i proporcionar un entorn segur on s’emmagatzemen i des d’on es treballen les dades de l’equip.
- Predicció i planificació : en entendre com es relacionen els productes amb les tecnologies, podem predir millor els terminis de lliurament. D’aquesta manera podrem reduir la incertesa i ajudar a garantir el lliurament ràpid i sense incidències.
Part del dibuix de la demanda per reunir-te amb el Product Owner i fer-li les preguntes següents per a cada classe de sol·licitud :
- Quin tipus de lliurable representa aquesta sol·licitud? És un .csv, un Excel, un producte, un SQL, etc.?
- Quantes persones treballen en aquesta sol·licitud?
- A qui arriba aquesta sol·licitud? Per què canal? Com els ho transmets a l’equip?
- Quines tecnologies es veuen implicades per donar resposta a aquesta sol·licitud (Tableau, Redshift, OnPrem, etc.)?
- Quina predictibilitat té aquesta mena de sol·licitud? És estàndard? És expedit? Hi ha deadline? És planificable? Es queda al backlog per quan tinguem més capacitat?
- Amb quina urgència categoritzaríeu aquesta sol·licitud? T’és fàcil planificar-la per al següent esprint o les dues setmanes següents? Ho categoritzes com Blocker i paralisses tot perquè ho lliurin com més aviat millor? Es queda al backlog?
És important identificar les tendències i els patrons a les sol·licituds per entendre millor les necessitats de Negoci.
Anàlisi Productes o Serveis de l’equip
En aquest pas, un cop hem fet l’anàlisi de la demanda, i hem identificat com aquesta demanda es relaciona amb el Negoci i l’Equip, analitzarem els Productes que té l’equip juntament amb el Product Owner.
Analitzar els productes o serveis que proporciona l’equip us ajudarà a:
- Optimitzar el flux de treball : de manera que identifiquem possibles àrees de millora en el flux. En entendre millor com gestionem i com lliurem els productes, podem identificar els colls d’ampolla, les ineficiències en els processos i començar a treballar a resoldre aquests problemes o millores.
- Identificar oportunitats de millora : l’equip serà conscient de com treballen i podran detectar oportunitats per millorar l’eficiència, la qualitat i la satisfacció de negoci. En aquest punt, podrem incloure l’optimització de processos amb automatismes, o redissenyant el flux que tenim actualment, introduir o apostar per noves tecnologies com ara Cloud, adoptar noves practiques o establir o revisar les prioritats de l’equip.
- Alineació amb les necessitats de Negoci : en entendre i posar de manifest els productes de l’equip existents i la seva prioritat i impacte al Negoci, alinearem millor el treball de l’equip amb aquestes necessitats i objectius. D’aquesta manera, garantim que l’equip treballi a les àrees de més impacte i valor per a l’organització.
Per això, et pots donar suport a les preguntes següents:
- Quins són els productes que entra lequip?
- Quin és lobjectiu i la visió del producte?
- Amb quina tecnologia es relaciona el producte a la creació i el lliurament del producte?
- Qui és el principal client del Producte? Qui ho utilitzarà?
- Quina és la freqüència de lliurament del Producte?
- Què tan predictible és el procés de lliurament del Producte?
- Quin feedback rebem dels lliuraments de Producte?
- Com gestionem aquest feedback i com arriba a l’equip?
- L’equip és conscient de les oportunitats de millora dels processos dels productes?
- Com reps com PO aquestes oportunitats de millora des de l’equip?
- Com les prioritzes?
- Com arriba al backlog?
- Com es comuniquen aquestes millores a Negoci?
Passem a Kanban?
Si l’equip està treballant a Scrum i no funciona perquè la demanda no és planificable, els atropella els esprints, no tenen clar el flux de treball, els rols estan molt especialitzats, i no hi ha visibilitat ni transparència sobre el treball que estan fent l’equip, adoptar la metodologia Kanban t’ajudarà a:
- Millorar la flexibilitat en la gestió del treball : amb Kanban obtenim més flexibilitat en la gestió de les tasques i projectes. Mentre que, a Scrum, les iteracions són fixes i no permet flexibilitat per a la demanda no planificada, amb Kanban podem tenir un flux continu de treball, de manera que millorarem la gestió de canvis de requisits o prioritats.
- Enfocament al flux de valor : amb Kanban ens centrem a optimitzar el flux de treball de l’equip ia eliminar o reduir els colls d’ampolla. Si Scrum us està generant colls d’ampolla i un flux de treball ineficient, amb Kanban pots millorar la velocitat de lliurament.
- Visibilitat : amb Kanban pots donar més visibilitat a la feina que s’està realitzant entre l’equip. De la mateixa manera, els stakeholders com a Negoci o VPO poden veure des del tauler de Jira l’estat de les iniciatives, com aquestes s’estan prioritzant i com avancen. Amb la visibilitat podrem identificar i atacar problemes que sorgeixin de manera més ràpida.
- Eliminació de sobre compromís : a Scrum, l’equip es compromet a lliurar una quantitat fixa de tasques en un temps determinat. No vol dir que amb Kanban el compromís se’n vagi, però a diferència de Scrum, no genera frustració si l’equip no arriba perquè l’abast de tasques era més complex. De la mateixa manera, es fomenta la col·laboració entre membres de l’equip per lliurar les tasques conjuntament i amb més velocitat.
- Menys cerimònies Scrum té cinc cerimònies, moltes de les quals resulten ineficients per als equips o ho veuen com una “pèrdua de temps”. Kanban, té set cerimònies, però a diferència de Scrum, són més lleugeres i adaptables. Pots adoptar aquelles que realment et generin valor i t’ajudin (per exemple, la gestió dels riscos sol ser la menys utilitzada pels equips). Recordeu, la metodologia ha d’estar al servei de l’equip, no al revés.
- Reducció de deixalles : amb Kanban podràs identificar i eliminar, sempre que es pugui, aquells passos del procés que no tinguin sentit i constitueixen un problema per lliurar valor. D’aquesta manera, milloraràs l’eficiència i la productivitat de l’equip.
- Millora del temps de lliurament : quan ens enfoquem a l’“stop starting, start finishing” lliurem contínuament, minimitzem el treball en curs, i mantenim el focus en les tasques que estem fent, la qual cosa porta a una acceleració dels lliuraments de producte.
