”Agile software development methodologies come with a distinct cross-functional team agenda. Kanban does not share this, nor does it need to in order to produce exceptional process improvement results. The Kanban approach is to visualize, improve transparency and understanding, reduce coordination costs through the use of boards. Visualize, Don’t Reorganize!”
Kanban delar inte den agila agendan med korsfunktionella team. Istället löser Kanban detta problem på ett annat sätt vilket denna artikel som handlar mer om enterprise kanban än team kanban visar.
Kanban är inte bara Scrum utan sprintar och scrum master, skillnaderna mellan dem är betydligt djupare än så för de har lite olika filosofier och angreppssätt, och Kanban kommer ursprungligen från lean metodiken och uppfanns av Toyota i Japan.
”Kanban has always been the “start with what you do now” method, and no one gets a “new role, responsibilities, or job titles” at least not initially. However, it is now clear that some roles are emerging in the field with some implementations.”
”What follows is in the context of a service delivery workflow which spans functions or teams and is (most likely) orthogonal to the organizational structure of the enterprise, business or product unit.”
Emerging Roles in Kanban – SDM and SRM
Vad gäller roller i kanban finns inga direkt definierade sådana eller krav på utan man kan anpassa kanban till att fungera med befintliga roller, men kanban university har vissa riktlinjer och råd för det med fast dessa gäller inte i alla fall utan bara i fall då dessa roller lämpar sig.
Enterprise kanban boards kan användas för DevOps
”The upper half shows a simplified functional organizational hierarchy divided into 8 functions labeled A through H. Each of these functions is a functional team – a group of specialists in some skill or professional service.”
”The Kanban Board is said to be “service-oriented” because it models the required service from the customer’s perspective. The board enables members from all 7 teams to collaborate to deliver the service requests to the customer.”
Artikel i länken högst upp där bilden är tagen ifrån visar hur man kan gå till väga när man väljer att implementera Kanban i sin organisation på avdelningsnivå för att ökar samarbetet och integrationen mellan flera olika funktionella team, som även på ett bra sätt visar skillnaderna mellan Kanbans och Scrums angreppssätt avseende hur team kan vara uppbyggda (tvärfunktionella eller specialister), så ni kan avgöra vad som passar er bäst.
Tror även att man på team nivå i ett eller flera specialist team kan jobba enligt scrum om man vill även om man på avdelningsnivå använder kanban för att synkronisera flödet mellan de funktionella teamen på högnivåboarden som visas i bilden i artikeln, men då blir det inte ett konstant flöde av uppgifter utan 2-4 veckors batchar så kanske bättre alla team jobbar enligt Kanban.
Hierarkiska kanban boards kan användas för DevOps
”Your overall value-stream should be tracked on a separate Kanban board where Dev and Ops have their own lanes. (Check our page on portfolio kanban for details on how to set up and use hierarchical boards.)”
”We wouldn’t suggest applying DevOps at the user story level. Whatever you define as your MMF (minimum marketable feature) or Epic, or Release (any unit really) should probably be WIP limited, not individual stories. It’s possibly the only sensible/ easiest way to help map and manage your entire value – stream”
Using Kanban for DevOps and Continuous Delivery
Ibland kanske det inte är möjligt eller för omständligt att t.ex. införa permanenta tvärfunktionella team i en organisation och man vill bibehålla separata funktionella team som team med utvecklare, drift/support team och arkitektteam som alla jobbar enligt kanban och kan ha sina egna team kanban boards som visualiserar arbetet på user story nivå och sen en portfolio kanban bord för en hel it avdelning som som visualiserar arbetsflödet mellan teamen på t.ex. epic nivå.
Jobbar man enligt DevOps och Kanban behövs inga tvärfunktionella team
”DevOps is a software development methodology that aims to bring software development teams and information technology operatives together. It is a concept that fosters a culture of collaboration between these two teams that historically worked in their own separate silos, from the initial design phase right through to product release.”
Agile vs DevOps: What’s the Difference?
För att då få samarbetet att fungera så bra som möjligt kan man även införa DevOps mellan de funktionella teamen och DevOps handlar i hög grad om att med hjälp av diverse olika tekniker automatisera releaser av mjukvara enligt CI/CD så att Ops inte ska fördröja eller bli ett hinder för utvecklarna, och Ops roll är att ta fram och drifta den driftsplattform och tool chain som utvecklarna behöver för att kunna göra det.
”DevOps is a set of practices that works to automate and integrate the processes between software development and IT teams, so they can build, test, and release software faster and more reliably. The term DevOps was formed by combining the words “development” and “operations” and signifies a cultural shift that bridges the gap between development and operation teams, which historically functioned in siloes”
DevOps: Breaking the Development-Operations barrier
Viktigt för att få till DevOps är ett prestigelöst samarbete mellan Dev och Ops där teamen hjälper och tar emot hjälp, och saker inte dras i långbänk varenda gång o.s.v för driften jobb blir att möjliggöra för utvecklarna och för sig själv att jobba så automatiserat och smidigt som möjligt.
Men självklart måste man få diskutera och argumentera kring lösningar och teknologier för den typen av ibland heta diskussioner leder oftast framåt så länge man inte tar det personligt.
Utvecklarna har oftast ett stort intresse kring saker driften gör som direkt påverkar deras arbete och vill ha ett ord med i laget, och driften ska även serva utvecklarna med det de behöver precis som utvecklarna ibland gör saker driften behöver.
Agilt, Kanban och DevOps fungerar tillsammans och kompletterar varandra
”Both DevOps and Agile can work in tandem since they can complement each other. DevOps promotes a fully automated continuous integration and deployment pipeline to enable frequent releases, while Agile provides the ability to rapidly adapt to the changing requirements and better collaboration between different smaller teams.”
Agilt förespråkar att man löser samarbetet mellan Dev och Ops med tvärfunktionella team men DevOps löser det genom att se till att samarbetet mellan de olika funktionella teamen fungerar smidig i stället, så två olika sätt att lösa samma problem på.
Det innebär att man i en organisation som jobbar enligt DevOps inte behöver ha tvärfunktionella utvecklingsteam utan kan ha funktionella team som samarbetar så bra att de nästan är som ett team.
DevOps handlar även mycket om att automatisera flöden via olika verktyg och plattformar som t.ex. build och release piplines för utvecklare i Azure DevOps, Ansible för driften, self-service i en molnplattform o.s.v. så ett av av målen är att utvecklarna ska kunna jobba så självständigt som möjligt.
DevOps är lika mycket en mentalitet som automatiserande verktyg och processer, och syftar till att utvecklarna ska kunna jobba rätt självständigt medans driften tillhandahåller det utvecklarna behöver för det.
”Agile addresses gaps in Customer and Developer communication!”
”DevOps addresses gaps in Developer and IT Operations communication”
Agile Vs. DevOps: What’s the difference?
Ta även Andresens anti-agila tal med en nypa salt för där talar han lite i eget intresse och det agila mindsettet och metodiken kring hur produktägare och utvecklare jobbar med själva utvecklingsbiten är också bra att ha för utvecklingsteam, med skillnaden att utvecklingsteamet inte behöver vara tvärfunktionellt om organisationen är DevOps.
Med kanban börjar du med det du har och tar det så långt som du vill
”The Kanban method accepts what you do now and aims to improve it. Your first step is simply visualizing your current process (regardless if it’s sequential). Then, you should aim at managing flow and uncovering improvement opportunities for faster release of value to the market.”
Alla organisationer har kanske inte intresse av eller möjligheter att bli 100% DevOps och/eller 100% agila inom överskådlig tid för det är en lång resa som ibland kan kräva ett helt ändrat arbetssätt rakt igenom en hel organisation, men däremot kan man försöka blir så agila eller devops som möjligt inom de ramverk man jobbar och med kanban börjar man med det man har.
Med det vill jag ha sagt att man kan ta de bitar som ger störst vinst från kanban, agilt och devops som är möjliga att införa relativt enkelt, och skippar de vattenfallsorienterade bitar som ger mest onödig byråkrati i en organisation vilket ni kan lära er lite mer om i artikeln ovan.
Läs även mina artiklar om kanban för it-support och systemutvecklingsteam som kompletterar denna mer enterprise och devops inriktade kanban artikel.
Robert Forsström's Blogg 