Sopiga processer

“Vad vi än gör så måste vi undvika att detta blir till en change request.” Den repliken mötte mig när jag ringt upp en “arkitekt”  – nej, han kunde ingenting om husbyggen – för att påpeka att den specifikation som han så mödosamt, och i all ensamhet lappat ihop, inte var begriplig. Orsaken till hans rädsla för en change request var att den då skulle behöva tas upp i ett Change Control Board och där kunde det ta månader att få igenom den och då hade möjligheten att sedan hinna testa funktionen före deadline passerat. Hans lösning blev istället att prata med mig, och testaren för att komma överens om hur vi gemensamt skulle missförstå specifikationen för att det skulle bli ett önskvärt resultat.

Godartat myteri i miniatyr

Det var en form av kontrollerat, godartat myteri i miniatyr. Ett myteri mot den fundamentala rädsla för att någon ska ta sig friheter och införa förändringar som inte är sanktionerade. Frågan är om det inte hade varit ett allvarligare myteri att faktiskt använda sig av den förändringsprocess som han var ålagd att använda? Det finns historier som pekar på det.

I februari 2010, en ovanligt kall och snörik vinter, drabbades de stockholmsbaserade sopåkarna av ytterligare kyla från arbetsdomstolen. De fastslog att deras arbetsgivare Liselotte Lööv hade rätt att införa månadslön vilket innebar sänkt ersättning med ca. 6000:-/mån. Motdraget var minst sagt intressant. De anställda aviserade att de hade för avsikt att börja följa miljölagstiftningen till punkt och pricka. Inga fler forcerade snövallar, inte hämta sopor där det inte är skottat eller sandat, inga 30-kilossäckar kommer att hämtas och efter 8 timmar går vi hem, oavsett om arbetet är klart eller ej. Det var vad man sa. Uppskattningen gjorde gällande att en tredjedel av alla soprum skulle förbli otömda om man följde arbetsmiljölagstiftningen.

Det var en protest som bygger på att följa alla absurda regler och processer som, mer eller mindre utomstående, aktörer definierat. Arbetsmiljölagstiftningen är viktig och ska givetvis helatiden uppdateras för att vi alla ska kunna kräva en drägligare arbetsmiljö. Men när den rör sig för långt ifrån verkligheten blir den inte bara verkningslös, den öppnar även för svårhanterade protester.

Tillbaka till min kära “arkitekt” och hans rädsla för change requests. Nog kan väl hävda att hans tilltag att försöka ducka för den formella processen var i all välmening? Ett användande av en formell förändringsprocess kan rentav ska ses som en tyst protest och en resignation inför det övergripande målet med arbetet.

Organisationer som efterfrågar min hjälp uppvisar vanligen tendenser åt samma håll. Jag ser förändringsråd (Change Control Board) som ska godkänna alla förändringar innan de genomförs. Jag ser ärendehanteringssystem där alla utökningar av mjukvaran måste motiveras av ett öppet ärende. Det blir absurt när utvecklare vill förbättra kodkommentarer, göra omstruktureringar för ökad förvaltningsbarhet, nya testfall för att visa på egenskaper hos de befintliga funktionerna, samt stabiliserande åtgärder som ännu inte motiverats av att något gått fel. Resultatet blir istället utnyttjandet av kryphål och minskad transparens.

Lyckas först i liten skala

Rädslan för att misslyckas driver oss in i defensiva vanor av det här slaget. Att vara rädd för att misslyckas är ingen bra utgångspunkt, men om du nu är rädd för att misslyckas och du känner dig lockad av att hämma produktiviteten med någon av ovanstående vanor – våga istället att satsa smått, så smått att du själv kan engagera dig i resultatet. Lär personligen känna de som arbetar med utvecklingen av ditt kritiska system och fundera på hur ni ska bygga en process baserad på tillit och respekt. Försök ge er möjligheten att göra ett så bra jobb som möjligt utan att göra för mycket avkall på framfarten (utvecklingen av nya funktioner). Denna offensiva ansats leder till hög transparens, produktivitet och till motiverade medarbetare. Med den defensiva attityden löper du risken att definiera regler och processer som kan användas emot dig när dina medarbetare tappar respekten för dig.

About Måns Sandström

Måns Sandström
Förändringskonsult
Grundare av Adaptiv

Familjefar med intressen inom musik, sport och systemutveckling. Har sedan 2001 varit förespråkare för agila arbetssätt. Från att ha arbetat som teknisk projektledare, programmerare och DBA är jag nu främst förändringskonsult, utbildare och systemutvecklare. Allt genom bolaget Adaptiv Sthlm AB som grundades av Joakim Holm, Johan Lind och mig själv i april 2009.