Att hantera teknisk skuld

Tyvärr är nog sanningen att alla mjukvaruprojekt över en viss storlek har teknisk skuld. Kanske är det omöjligt att eliminera teknisk skuld helt och hållet – men vi kan sträva efter att hålla den på en så låg nivå att vi inte lider av det.

Efter driftsättning av Systemet – som innebär mycket intensivt jobb mot en snäv deadline – fanns det tyvärr inbyggt en stor mängd teknisk skuld. Efter driftsättning skiftade produktägarnas fokus från att hålla deadline, till att öka Systemets stabilitet och minska antalet ärenden som krävde manuell hantering. Samtidigt fanns det ytterligare funktionalitet som skulle implementeras, även om det inte längre var lika bråttom.

Vi valde en tämligen oortodox lösning för detta. Vi delade upp oss i två grupper. Hela teamet hade fortfarande ansvar för att hantera ärenden och rätta buggar, men den ena gruppen kunde koncentrera sig på nya funktioner, medan den andra gruppen hade fokus på att minska teknisk skuld. Det här har fungerat väldigt bra för oss, och man kan identifiera några framgångsfaktorer:

  • Arbetet med den tekniska skulden har prioriterats av produktägarna
  • Gruppen har själva fått föreslå och i viss mån prioritera vad som ska göras
    • Teknisk skuld som leder till manuella ärenden har fått företräde
    • Teknisk skuld som har varit enkel att åtgärda men gett stor effekt har fått företräde
  • Gruppen har sett till att produktägarna förstår vad som ska göras och varför
    • Man har jobbat mycket visuellt med att visa och förklara på vilket sätt en förändring påverkar och faktiskt hur det i längden gagnar system och kund

Men den allra viktigaste förutsättningen för att detta skulle fungera överhuvudtaget, är att vi har haft en grupp där alla var intresserade av att reducera teknisk skuld.

 

 

Ett positivt retrospektiv

Om man varje sprint kör samma typ av retrospektiv med teamet, och dessutom har en förändringsvillig grupp, leder det till två saker:

  1. Teamet blir väldigt duktiga på att delta i retrospektiv
  2. ”De lågt hängande frukterna” blir snabbt plockade, och man sitter efter ett tag och diskuterar småsaker

Det sistnämnda kan uppfattas som gnäll; man glömmer allt man åstadkommit för att fokusera på de mindre detaljer som inte fungerar.

Det kan i det läget vara en bra idé att bryta upp rutinen med en övning som ger energi och som fokuserar på allt man uppnått hittills. Vi kallar det för det ”positiva retrospektivet”.

Denna övning kan gå till på olika sätt, men när vårt Team har provat detta, har det typiskt fungerat såhär:

  • Genomgång:
    • Titta tillbaka sex månader, och gör en kort beskrivning av hur arbetet gick till då
    • Kontrastera detta med hur arbetet fortlöper idag
    • Summera ihop de senaste sex månadernas bedrifter för teamet
  • Retrospektiv:
    • Alla i Teamet – inklusive produktägare – får skriva obegränsat antal lappar med positiva saker om arbetet
    • Be Teamet sätta upp lapparna på en tavla, indelad i tre delar: ”Teamets styrkor”, ”Vad vi är bra på”, ”Saker vi lyckats med”
    • När alla satt upp sina lappar, reflektera kort över lapparna på tavlan.
    • Sortera upp lapparna i namngivna kategorier. Kategorierna bestäms efter innehållet på lapparna, men typiskt är det kategorier som ”Teamkänsla”, ”Kompetens”, ”Buggfixar”, osv.
  • Diskussion:
    • Välj ut en eller två kategorier och använd rubriken för öppen diskussion i teamet, kanske 20 minuter. För att starta diskussionen, kan man ställa frågan vilka som skrev en lapp som hamnade i den kategorin, och om de vill utveckla varför de skrev den.
    • Man behöver inte ta några action points från denna typ av retrospektiv.
  • Avslutning:
    • Låt var och en kort summera sin känsla av retrospektivet.

När vi har använt den här formen av retrospektiv, har det uppfattats som väldigt energigivande och positivt för gruppen. Flera deltagare i teamet har till och med sagt att det var det bästa retrospektivet nånsin!

 

Visualising your backlog

Far too often the backlog is housed in a tool somewhere, often in purely text form, with no way of knowing at a glance the status of each item. This makes it difficult to manage in many ways, and generally hard to work with. I have found that taking the time to visualise your backlog will not only increase the quality of the output, but make it a lot easier and less time consuming to work with. This is an example from my current project of how that works.

Your backlog as a process:

backlogMost people don’t take the time to see their backlog as an actual flow, but it is. Items usually have a sort of process that they flow through to arrive in a state where they can actually be worked on, and being aware of what that flow is can help a lot in creating stability.

This ”refinement process” is, in my opinion, one of the easiest wins in most teams. Our team went from having 1-2 day Sprint Planning meetings, to usually getting through them in a just a few hours, with a much higher quality of output.

The backlog on its side:

The first step in creating a refinement process, is to visualise it. In the simplest sense this can be accomplished by simply turning the backlog on its side and seeing each section of the backlog as a column in your flow.

backlog_side

The tool we use for this is KanbanFlow. The images you see here are simplified slightly for the sake of clarity, they only show one teams flow, when in reality we have multiple teams working in this flow.

Below you see the complete flow, and we examine each section in turn.

flow_noinfo

The bottom:

bottomHere sit the totally unrefined items. Some of them may be too big to work on, most are too unclear, and all are only ”lightly prioritised”. We like to visualise the different flows in to the backlog separately. This makes it easier to balance priorities against one another when planning upcoming work.

  • Backlog
    • Full of large, unclear stories.
    • Many of these may never reach the top, we try to clean this out every so often and remove things we are certain will never be top priority.
    • Most of these items come from our Product Owners / Customers.
  • Teknik
    • Holds much of our technical debt.
    • These generally tend to be concise, but somewhat large.
    • These items primarily come from the teams working on the product.
  • Bug list
    • A list of bugs that were not quite important enough to be a priority right away.
    • We try to keep this list as small as possible, but some things do need to wait until they are worth the investment to fix.
    • These items usually come from users who find them in production.

The middle:

middleThis is where the bulk of planning and discussions happen. There is a column where action from the customer is needed, and one for when action is required on our side. Most of what takes place here comes down to regular discussions which bring up question that need to be answered before development can start. Very often, large stories are split into smaller items here, and some of the lesser priority things go back to the bottom of the backlog, and the prioritised items continue forward.

Items do not leave this area without a clear priority.

The top:

topThis consists of items that are ”Ready” to be worked on, and items on which work has begun. Many teams choose to have a formal definition of ready, our team keeps it fairly simple: ”Everyone in the team agrees these items can be worked on now”.

Items which are pulled into the Sprint column are being worked on by the team. At this point, these items are made into smaller and more specific tasks, and are visualised using the physical tool for the team. This is important, because it is the main points where details are obfuscated. Our customer does not need to know exactly what is being done on an item, what matters to them is that the feature or functionality is started, and when it has been completed. This setup allows them the appropriate amount of detail.

The output:

deployAt the moment we have a slightly heavy deployment process, which involves handovers to the customers organisation and wait times. Visualising this helps our customers to understand when things are ”done”, but they still don’t have them due to internal processes. This has aided in our customer driving many initiatives to simplify and streamline this process. While we still feel it could be improved further, it is definitely an easier process today than it was before we started visualising this part of the process.

Summary:

Being aware of how items flow in your backlog from the initial request to the actual delivery can help significantly in many ways:

  • Clear status of items in process for both you and your customer.
  • A shared understanding by all involved what is in the pipeline.
  • Easier planning session because everyone has more insight when items arrive.
  • Higher quality to items arriving at the ”ready for development” stage.

But be careful not to present unneeded information as it only serves to make the needed information harder to find.

And most importantly, the tools used in the process are much less important than the process itself. Having the discussions regularly and openly, creating the feedback loop as quickly as possible, are the keys to success not the tools being used to present the information.

This process can be tricky at first, but as with all things, the more often you do it the better you will get at it!

Massor av kolumner

1280px-Schema_Saeulenordnungen

Att visualisera backloggen och hur arbetet fortskrider är viktigt (läs också Jeffs post om detta här ovanför). Vi använde förut TFS, men i jakten efter någonting som var enklare att använda och visuellt mer slående, fastnade vi för ett annat verktyg: KanbanFlow.

Vi hade fram till dess haft tre stadier för en punkt i backloggen: ”Todo”, ”In progress”, ”Done”. Vid övergången till vårt nya verktyg, fullkomligt exploderade Teamet i kreativa förslag på hur visualiseringen borde ordnas för bästa överblick. Så här ser våra kolumner ut idag:

Namn Innehåll Prioriteras av
Backlog Utvecklingspunkter på längre sikt Produktägarna
Teknik Tekniska förbättringar, rensning av teknisk skuld Teamet
Buggar Mindre buggar eller ärenden Produktägarna och teamet gemensamt.
Produktägare – refinement Punkter där produktägaren behöver göra en insats för att arbetet ska komma framåt. Typiskt innebär detta en workshop, en utredning eller kunskap från tredje part.
Team – refinement Punkter där teamet behöver göra en insats för att arbetet ska komma framåt. Typiskt innebär detta diskussion, nedbrytning och tidsuppskattning. Alla eventuella frågetecken ska rätas ut innan punkten får flyttas.
Ready Punkter som är redo att implementeras. Produktägare och team, gemensamt.
Sprint Punkter som teamet åtagit sig att implementera under denna sprint.  Teamet
Väntar på test Punkter som är färdigimplementerade enligt vår definition-of-done.
Väntar på produktionssättning Punkter som är testade i produktionstestmiljön och väntar på driftsättning.
Färdigt. Punkter som är… tja, färdiga.

Man kan fråga sig hur prioritering sker mellan backlog, teknik och buggar-kolumnerna. Mer om det i en senare post.