Why Task Assignment Sucks

You may be like me. Some things at work suck the life out of me. I can’t always explain why. Most of the time I can learn to live with it, and therein lies the crux. I accommodate things that I really should refuse outright. Here’s one such thing: task assignment. See if you agree.

Assigning tasks. Also known as the age old habit of telling others what to do. Try to go a day without doing it. It’s pretty hard, especially if you have kids. Probably also hard if your title includes the word manager.

SO what’s so bad about assigning someone a task? After all, it can’t be that bad – there’s even support built in for doing it our planning software. Assign to person X, that’s what the buttons say.

Here’s why this bothers me. I’d much rather pick my own tasks. After all, I was hired to do what I do. Or at least I haven’t been fired yet. However it is: I’ve come to trust myself (at least some of the time) to choose which tasks will best take me towards the goals we’ve agreed upon. If we haven’t agreed on goals yet, I definitely can’t see why you would tell what to do. We should talk about goals before we do anything else.

Being assigned or picking. It might seem like a meaningless play with words, but I believe that the words we choose reveal something about our world view.

In one world view, people are resources to which we assign tasks. Worker threads that waste cycles when idling.

In another world view, people are people. Fully capable of filling their own work day with the right stuff, given a little bit of wise guidance.

You might think: ”sure, letting people pick their tasks would work with an experienced and motivated team – but you haven’t met my team. If I don’t tell them what to do, nothing at all gets done”.

To this I could reply: ”OK, your team sounds like it’s struggling. Have you tried giving them a juicy goal, and then letting them figure out how to reach it?”.

You in turn might just reply that you have indeed tried that, and that it didn’t work at all. Nothing did get done, as you knew it wouldn’t. Or maybe the wrong things were done.

Then I’ll ask you what you did next. If you now say that you stepped in and assigned tasks to people, then you might be able to see where the problem is.

Assigning tasks robs people of the ability to learn how to figure out the way to the goal themselves. It’s a learning stopper, and if there’s something we need more of in today’s organizations it’s learning.

In the end I don’t care if your buttons in JIRA still say ”Assign”. JIRA is a tool. You’re not. You know better.

Late Again, Thinking About the Cost of Delays

It’s Wednesday morning, and I’m on the train heading to Stockholm. The train is late, and it’s not the first time.

One reason delays annoy me so much is that they break my expectations. I’ve made my plans to fit with the train company’s timetable, and now they are not upholding their part of the commitment.

Then again, when it comes to riding the train from my hometown Uppsala to Sweden’s capital – Stockholm – delays are such an integral part of the experience that I’m no longer surprised when they happen. Curiously, they still annoy me. Maybe it’s because the company running the trains couldn’t seem to care less about the problems the delays are causing me. Somehow, they still manage to act like every single delay is a big surprise to them. I take comfort in the fact that I get some extra time to read and write, as long as I’ve found a place to sit on the train – but that’s another story.

Anyway, while a train delay may not seem a huge thing to fret about, consider its less obvious effects. When I don’t make it on time to my networking meeting, I miss out on information and networking that would be valuable to me.

Intuitively, we know that being late costs us, but we easily focus on only one narrow part of that cost: the increased cost of working on something for a longer time. We forget that we also push the rewards into the future, and that might be costing us even more.

In general, I find that a concrete cost today is easier to grasp than a probable loss in the future. Maybe it’s because we find it hard to think about loosing something we never really had in the first place. I guess this is one of the reasons we make short-sighted decisions.

If you want to learn more about understanding your cost of delay, Donald Reinertsen’s books are a good investment: Developing Products in Half the Time, Managing the Design Factory and The Principles of Product Development Flow.

Sketchnoting the Concept of Flow

I like to take stuff and try to express it in as simple language as possible. That’s my way of checking my own understanding of a concept. One concept that comes up often when we talk about lean software development, kanban and agile is that of “flow”. A couple of days ago, I decided to process that a bit.

One technique I use to process stuff is to sketchnote in Brushes on the iPad. Here’s the video output from my sketchnoting a basic explanation of the concept of flow in development.

What techniques do you employ to process stuff you want to learn well?

Visuell styrning med kanban (2): Enkla, kraftfulla verktyg

I det förra inlägget skrev jag om bakgrunden till att jag börjat arbeta med visuell styrning med kanban. Det här inlägget ger en första titt på verktygen vi kan använda.

Utöver ett uppdrag att slutföra och kunskap om hur kanban fungerar behövs följande för att komma igång med en egen kanbantavla:

  • En rymlig whiteboard med tillhörande pennor
  • Post-its i olika färger
  • Pennor som det går att skriva tydligt på post-its med (vanliga bläck eller blyertspennor ger så tunn skrift att det blir svårt att läsa vad det står när man står en bit från whiteboarden)

Att jobba med en kanbantavla (för till exempel sitt drifts- eller supportteam) handlar om att synliggöra sitt arbete så att man istället för överbelastning kan ha rätt mängd arbete igång, och därmed få fler saker klara snabbt och med rätt kvalitet.

Vi använder post-its (eller något annat flyttbart) för att dokumentera vad vi jobbar med – en sak per lapp. Målet är inte att dokumentera varenda liten sak som görs. Tvärtom funkar det hela bäst om man på lapparna skriver ned små nyttiga delresultat, snarare än aktiviteter.

Arbetets aktuella status visar vi genom att placera våra lappar på rätt ställe på whiteboarden. På den har vi nämligen ritat upp vår grupps arbetsprocess, så att lapparna kan sättas i kolumner som visar de olika steg arbetet går igenom, från ax till limpa.

Vi vet att kanbantavlan börjar fungera när vi med en snabb blick kan se vilket arbete som väntar, vad som pågår, och vad som gjorts klart. Från dag till dag kan vi lapparna röra sig över tavlan, från en kort prioriterad lista, genom de olika stegen i arbetsprocessen, på väg mot leveransklara resultat.

En whiteboard och post-its kanske verkar vara primitiva vertyg? Det stämmer, och det är helt avsiktligt. De är nämligen också mycket kraftfulla.

Genom att använda dessa enkla verktyg gör vi det lätt att anpassa vår process när vi märker att det behövs – det kostar bara lite suddande, omritande och lappflyttande. Med andra ord hindras inte våra förbättringsambitioner av att verktyget inte hänger med i svängarna (något som i min erfarenhet händer oftare än vad som är önskvärt). Med andra ord: Ingen hittar den optimala arbetsprocessen på första försöket. Verktygen finns till för att stötta processen. Därför måste det vara lätt att justera verktygen.

När synligheten är stor är det också lättare för var och en att veta var man kan hjälpa till. Gruppen får tydliga signaler när den behöver samarbeta för att lösa problem. Hur klyschigt det än kan låta så är ett team mer än summan av sina medlemmar. En grupp som lär sig samarbeta effektivt, till exempel med hjälp av en kanban-tavla, har tagit ett steg på vägen mot att bli ett effektivt team. Ett team låter inte sina medlemmar kämpa ensamma, det kliver in och hjälper individen att komma vidare och växa. Alla verktyg som kan hjälpa oss att komma närmare det idealet är värda en andra titt.

Använder du visuell styrning med enkla verktyg? Vad är dina bästa tips?

Visuell styrning med kanban (1)

De senaste åren har jag jobbat med att hjälpa team och organisationer att förstå och använda Scrum. Jag har jobbat en hel del med produktutvecklande företag, och det är i utvecklingsarbete Scrum verkligen kommer till sin fulla rätt. Samtidigt består arbetet med att lansera mjukvaruprodukter av så mycket mer än bara själva utvecklingen. Drift, support och marknadsföring är några exempel på aktiviteter som är avgörande för framgång.

Förra hösten åt jag lunch med en branschkollega på en restaurang i Uppsala och vi pratade om hur det gick för deras utvecklingsteam, som nyligen börjat använda Scrum. Det gick utmärkt. Arbetet var fokuserat och tydligt, och man hade lyckats genomföra ett komplext projekt framgångsrikt.

Samtidigt kände man på driftssidan att man ville ha ett lika engagerande och tydligt sätt att styra och följa upp sitt arbete. Jag berättade om något jag studerade just då – visuell styrning med kanban. Så vitt jag kunde se var de bakomliggande principerna sådana vi känner igen från Scrum, även om de praktiska handgreppen ibland ser lite annorlunda ut. Vi kom överens om att försöka få till ett kort och fokuserat samarbete för att få till en kanbanlösning för deras driftsgrupp. På så vis skulle även de kunna dra nytta av tankarna bakom Scrum.

Kanban är japanska, och betyder till vardags helt enkelt skylt eller tavla. Inom tillverkningsindustrin har begreppet däremot fått en mer specifik betydelse. Där betyder kanban ett signalsystem som styr flödet i produktionen. Jag är absolut ingen expert på industriell produktion, men jag kan göra ett försök att förklara systemet som jag förstått det.

Här är ett konkret exempel. En person som arbetar med att montera en komponent för en viss maskin behöver en mängd olika delar för att kunna göra sitt jobb. Hur många av varje? Det skulle man kunna försöka styra med ett avancerat datorsystem som prognosticerar behoven framöver. Eller så använder man kanban.

I ett kanbansystem signalerar varje del i en produktionskedja sitt behov av nytt material från ett föregående steg genom att tydligt flagga upp behovet. Rent praktiskt kan signaleringen ske genom att en låda med delar tömts, och därför skickas för påfyllning tillsammans med ett litet instruktionskort – en kanban – till den som kan fylla på lådan. Lådan fylls, och skickas tillbaks till beställaren. På samma sätt fortsätter beställningarna “bakåt” i produktionsledet. Fördelen? Processen styrs efter behov istället för efter spekulativa prognoser. Kanban blir därför en nyckelteknik i Just-in-Time-processer.

Så vad har kanban att göra med till exempel drift av mjukvara? Vi kan inspireras av metoden för att styra och följa upp arbetet i till exempel en driftsgrupp på ett sätt som är både tydligt och enkelt.

Våra kanban blir helt vanliga post-it-lappar som vi flyttar på en whiteboard. Whiteboarden designar vi för att ge en helikopterbild av arbetsprocessen. Resultatet: ungefär samma som när vi sätter upp sprintbackloggen på väggen och får en visuell sprintbacklogg, men anpassat för den typ av situation som till exempel ett drifts- eller supportteam befinner sig i. En vanlig invändning mot Scrum från denna typ av grupper är att det är svårt att få till iterationer, eftersom man arbetar så reaktivt med plötsligt inkommande saker. Mot det kan man förstås invända att man då borde fokusera på att eliminera så många oväntade saker som möjligt, och det är väl rätt i teorin. I praktiken måste man förstås ända styra arbetet under tiden, och varje sätt att få mer fokus och lite lugn och ro kanske gör det lite lättare att faktiskt börja eliminera rotorsaker till problem. Kanban kan vara ett sådant verktyg.

Med kanbantavlan blir det lättare för samtliga i arbetsgruppen att se vilket arbete som väntar, vad som pågår, och vad som är på väg att göras klart. Gruppen får också lättare att ta på sig rätt mängd arbete vid varje givet tillfälle, något som är viktigt inte bara för att undvika utbrändhet, utan också av mer kortsiktigt ekonomiska skäl. Man får helt enkelt mer klart om man undviker att överbelasta sig, och kvaliteten på arbetet blir högre.

För gruppens intressenter (t.ex. mottagare av de arbetsresultat gruppen levererar) finns också fördelar, som att det blir lättare att se status på arbetet. När synligheten ökar minskar ofta stressen. Det är helt enkelt svårare att bli stressad när man känner att man har koll på läget. När stressen minskar ökar lugnet, och vi fattar som regel bättre beslut när vi är lugna än när vi är uppjagade.

I nästa bloggpost tänkte jag skriva lite om hur det kan se ut rent praktiskt.

Känner du till en arbetsgrupp som skulle vilja dra nytta av fördelarna med att jobba lättrörligt, men som inte riktigt känner att Scrum passar perfekt? Hur gör de för att få bästa möjliga delaktighet och tydlighet?

Use, Adapt, Transcend

This article by Dave West on InfoQ might be an interesting read if you’re interested in theories of software development.

“Both Lean and Agile must stop applying, in a literal and rote manner, the tools and practices. Tools and practices are nothing more than expressions of values, principles and philosophy. They are not the only possible expressions and may not even be the best expressions. Neither side will be able to realize their respective founders’ admonition to “use, adapt, and transcend” until and unless they come to understand why the practices and tools are what they are.”

Theory of Software Development

Ivar Jacobsson rails at the prevalance of practices but, at least in this article, doesn’t even come close to touching on any relevant theories. Instead, it seems to me that he promotes even more practices. I’m sure things will clear up for me once I get my hands on his latest toolbox. Unless, of course, I have to pay a lot of cash to get it, in which case I probably won’t get my hands on it.

In today’s Computer Sweden, Ivar Jacobsson plugs his company’s latest offerings and requests a theory of software development. I haven’t tried his latest products, so I won’t comment on them. They might be great. However, one thing that puzzles me about the article is the absence of anything concerning useful theories applicable for software development.

Ivar Jacobsson rails at the prevalance of practices but, at least in this article, doesn’t even come close to touching on any relevant theories. Instead, it seems to me that he promotes even more practices. I’m sure things will clear up for me once I get my hands on his latest toolbox. Unless, of course, I have to pay a lot of cash to get it, in which case I probably won’t get my hands on it.

In that case, I might just spend my time by learning a bit more from those who seem to come closer to a set of working theories useful for understanding software development work. Like Gregory Howell and Lauri Koskela, in their provocatively titled paper “The Theory of Project Management is Obsolete”. Or like Don Reinertsen, who uses queueing theory to understand certain aspects of getting stuff out the door. Or like Mary Poppendieck, who also likes lean thinking and has made her own attempt at translating those thoughts to our world. I’m not sure these three would necessarily agree with each other if they met, but they are trying to find new ways of understanding the theoretical underpinnings of development work.

Thriving Through the Credit Crunch

Clarke Ching has written a nice little piece that’s available as an online read on Slideshare, and embedded below. It’s short and plain enough that it has the potential of becoming widely read. I’m predicting it will spread quite fast. Executive summary: releasing wanted software soon and frequently ties up capital for shorter durations, which is A Good Thing in cash-tight times.

Changes, Then Rules, Then Changes, Then …

David Schmaltz writes:

“Within SEI, there were (probably still are) two factions. I heard (just hearsay) that two principals at SEI approached two of the Agile Manifesto signatories to wish them luck shortly after the manifesto was made public. Apparently they had carried the same intentions in founding the SEI, but were compromised when the suits showed up.”

I have no idea whether this specific story is true or not, but I wouldn’t be the least surprised, because this is something that seems to be happening all the time. It’s probably a part of How Things Are. Something new starts growing, and as attempts are made to describe and spread that new thing, it gradually changes from being new to being something stale and overly simplified. In fact, the very things needed to spread that new thing are the same things that prevent it from staying fresh. So the new things dies – or rather transmutes into a new form. Gradually, the pressure builds for some other new thing to emerge, and eventually it does. When the changes are great, the transitions are painful.

So what can you do? I’ll tell you what I will do. I will keep checking my value compass, and if it shows me running off into the wild as I blindly follow my practice map, I’ll trust my compass over my map.

David concludes, in the comments to the post:

“I’ll serve spaghetti with sourkraut if I’m hungry and that’s what’s in the pantry. This because whenever a method gets embraced ideologically, whatever the method, the result is exactly the same. Mindfulness replaced by certainty. Thoughtfulness replaced by enforcement. Degrees of freedom transformed into degrees of imprisonment.”

– – –

Why not read a little tonight?

Queueing Theory in Practice

I’m back from a course in Stockholm on the topic of lean software development. While it was definitely not a waste of my time, it’s lack of depth and long lectures disappointed and puzzled me. Longing to learn some new stuff, I spent some time tonight googling for articles about, or written by, systems thinker Russell Ackoff. Coincidentally, I found a good article that managed to touch both a lean concept (although the moniker “lean” had yet to be adopted when the article was written) and mention Ackoff. What I found was a funny piece on some of the practical applications of queueing theory from the September 25, 1988, edition of the New York Times.

“One way to take some of the sting out of waiting is to entertain customers. Since 1959, the Manhattan Savings Bank has offered live entertainment during the frenzied noontime hours. In 13 branches, a pianist performs and one branch has an organ player (Willard Denton, the former Chemical chairman who dreamed up the idea, liked organs, though present management thinks they are a trifle loud for a bank). Occasionally, to make line-waiting even more wonderful, Manhattan Savings has scheduled events such as a fancy-cat exhibit, a purebred dog show and a boat show.”

I also came across an elegant article about the differences between push and pull.

“Now reverse the logic. Suppose the customer pulls the product or service required through your system. Because you’re making what someone has actually ordered, you don’t have to guess or predict sales and production. You don’t have to add extra features or colours to tempt people to buy. If you’re not making things on spec, you don’t need the space, computers or people to store and track the inventory. “