Sitta tillsammans på olika sätt

juli 6, 2009 at 20:08 (People, Process)

Sedan jag först började läsa om agila metoder har jag uppskattat tanken att sitta tillsammans som något självklart och ovedersägligt.

Efter ett par försök på olika håll tycker jag mig se ett par återkommande mönster för vad som får tekniken att fungera bättre.

Gemensamma intressen

För att det ska löna sig för en grupp människor att sitta tillsammans krävs att de har något gemensamt. De bör arbeta i samma projekt, mot samma deadline och samma kodbas.

Därför

Forma team som arbetar i grupp mot gemensamma mål, och placera dem tillsammans.

Men

Tänk på att inte forma för ensidiga team — Gemensamma intressen betyder inte att alla gillar att knacka Ruby, utan att alla strävar mot samma mål och hjälps åt att komma dit. Tvärfunktionella team innehåller alla kompetenser som behövs för att leverera en färdig produkt.


Lagarbete

Ola Ellnestam beskriver ett anti-mönster som han kallar för The Graveyard:

Föreställ dig ett rum, ganska stort. Ungefär 100 kvadrat. Du kan knappt höra surrandet från ett halvdussin datorer. Det är varmt, inte hett, bara lite över normal rumstemperatur. Någon hostar. Sedan blir det tyst igen, förutom det svaga surrande datorljudet. Du lyssnar lite noggrannare och märker ett svagt, oregelbundet klickande. Du får en känsla av att den som är källa till ljudet inte vill störa för mycket. Ljuset i taket flimrar till.

Du sveper snabbt med blicken över rummet, räknar till 1, 2, 3 … 7 sittande personer. De verkar stirra ut i tomma rymden, och det hade de också gjort om det inte vore för datorskärmarna framför dem. Det är som om det stod glasväggar mellan personerna i rummet. En dator står längst ner i rummet. Skärmsläckaren snurrar förbi lite text.

Förutom Gemensamma intressen blir det mycket mer värdefullt att sitta tillsammans om man faktiskt jobbar som ett lag istället för som en grupp individer. Man blir mindre beroende av nyckelpersoner, eftersom alla har hygglig inblick i vad som händer.

Därför

Som Ola säger, uppmuntra Lagarbete och kommunikation genom att hitta rutiner som får flera personer att jobba på olika aspekter av samma uppgift.

Men

Ett väl fungerande Lagarbete är svårt att skapa på syntetisk väg. Var försiktig så att eventuella knuffar för att stimulera lagarbete inte hindrar teamets naturliga sätt att arbeta.


Storleken har betydelse

Kommunikationen sägs bli bättre av att sätta gruppmedlemmar fysiskt nära varandra, så att de kan använda högeffektiva kommunikationsmedier — tal och ansiktsuttryck — och uppnå osmotisk kommunikation.

Det är dock svårt att skala det här — större grupper kommunicerar mindre effektivt och det blir svårare för medlemmarna att socialt knyta an till hela gruppen.

Därför

Ge dina team Gemensamma intressen, så att de har något att kommunicera kring, men inte så stora mål att de behöver vara fler än 5-9 personer.

Men

Om ditt team av någon anledning måste vara stort, försök introducera tekniker och regler för att minimera störningar (både inifrån och utifrån), maximera kommunikationsmöjligheterna och stimulera social interaktion.


Privat sfär

Jag har vid ett par tillfällen suttit i jättebra grupper, med Gemensamma intressen och lagom storlek, men två meter ifrån vår arbetsyta har ett annat, mycket mer högljutt team (med tråkig humor) suttit och förpestat lugnet. Som jag minns det var vi väldigt tysta och skötsamma, men något säger mig att de tänkte samma sak om oss.

Därför

Isolera team från varandra genom att ge varje team ett eget rum där de inte störs av buller från utomstående. Alternativt, möblera med skärmar och whiteboards så att teamet får vara någorlunda ifred från störmoment.

Men

Att team är fysiskt avskilda från varandra till vardags betyder inte att de ska sluta kommunicera, bara att de ska undvika att störa varandra med slumpmässigt oljud.


Telefonrum

Om jag delar rum med fem personer och min fru ringer för att fråga om deklarationen vill jag helst inte prata inför mina kolleger. Eller om jag behöver ringa för att boka en läkartid eller bara snacka med en kompis. Dessutom finns det få saker som är så störande för omgivningen som någon annans mobiltelefonsamtal.

Därför

Se till att varje team har ett dedikerat rum med dörr som är avsett för privata telefonsamtal. Om lokalerna tryter, låt flera team dela på ett telefonrum. Vi har ett litet konferensrum som man inte kan boka, men som ockuperas för mindre möten. När det är ledigt används det flitigt som telefonrum, annars hänger folk ganska oblygt i korridoren.

Det viktigaste är att folk inte känner sig utsatta när de sköter sina personliga förehavanden, och att deras kolleger inte störs om de saknar normala telefonspärrar.


Samfälliga avbrott

När någon utomstående kommer in i gruppens rum för att prata med en enskild medlem avbryts och störs alla medlemmars arbete. Ofta tror den som frågar att den har korn på vem som vet mest, men lika ofta visar det sig att gruppen tillsammans vet mer än någon enskild medlem, särskilt om gruppen ägnar sig åt Lagarbete

Därför

Arbeta för att utomstående inte ska tilltala enskilda medlemmar om arbetsrelaterade saker, utan hela gruppen — alla är ändå inblandade konversationen, från det att någon säger ”Hörru, Kim, jag undrar…”.

Men

Om det rör privata angelägenheter, lämna gruppens arbetsyta, för att störa så lite som möjligt.


Slutsats

Som alla tekniker fungerar samsittning olika bra i olika sammanhang. Efter ett gäng bra och några dåliga erfarenheter vill jag driva tesen att fokuserat lagarbete i en mindre grupp i alla fall är en bra start.

Ständigt återkommande teman ovan är Gemensamma intressen, Lagarbete och kommunikation.

Kommunikationen ses ofta som den stora fördelen med att placera grupper tillsammans, men jag tror inte förbättrad kommunikation kommer gratis, den är avhängig flera andra aspekter av teamets samarbete.

Permalänk 1 kommentar

Projektberoenden måste kanske inte göra ont

april 27, 2009 at 21:52 (People, Process)

Beroenden mellan projektgrupper verkar svårt att hantera (det kan vara ett lokalt problem, men jag väljer att låtsas att det är mer allmängiltigt).

Även om små, sammanhållna och seriella projekt verkar vara en ganska populär strategi kan jag ganska sällan i min roll som tjurig utvecklare styra hur projektportföljen ska förvaltas. Däremot har jag en del chanser att påverka hur arbetet fortlider när projekten väl är igång.

Fowler presenterar en intressant modell där SOA-tjänster utvecklas i open source-stil, så att team i beroendeställning kan agera patch-bidragsgivare till en tjänst de är beroende av.

Jag tror inte det här behöver vara specifikt för SOA-sfären, utan snarare att  projekt som använder tjänsteorienterade arkitekturer kanske karakteriseras av en viss storlek och flera parallellt aktiva team. Det vill säga; alla projekt över en viss storlek (mer än ett team) skulle kunna koka ihop något i den här stilen oavsett vilken arkitekturstil de råkar använda.

Fowlers vårdnadshavarmodell har mekanismer för att provocera fram kommunikation mellan två team i ett beroendeförhållande och det skulle man kunna spinna vidare på.

Exempelvis, genom att så länge det finns ett beroende i någon riktning kräva en aktiv representant på varandras dagliga stå-möten. Det borde stimulera teamen att hålla varandra uppdaterade på sina respektive behov och planer.

Eller genom att arrangera utbyte mellan teamen så att teamet i beroendeställning får en representant som kan arbeta med deras behov i deras kontext. På så sätt ökar man chanserna dramatiskt att rätt problem löses på rätt sätt.

Ett fokus på kommunikation och samarbete torde kunna mildra problembilden väsentligt.

Permalänk 2 kommentarer

Introspection makes perfect

mars 25, 2008 at 20:19 (Process)

I’m currently the coach of an ‘Agile’ team at work.

I say ‘Agile’ because we haven’t managed to adopt the full set of practices recommended by XP, which I was originally striving for. I use the scare-quotes also because we aren’t really aiming for agility; none of the involved parties have any particular desire to be able to adapt to change.

Rather, we are just trying to find a dignified way of running our software projects, and many of the ideas associated with Agile Software Development seem to make life easier for us.

The team is not exactly fired up and burning on the gasoline of Agile. We’ve had our fair share of discussions around things like short iterations, done-done and test-driven development. But I’ve done my best to explain why I think the practices will help us, what problem they are meant to solve, and I think the team agrees with me for the most part.

It strikes me as this is progressing — we’ve been doing it rigorously for about 6 months — that what makes the improvement isn’t so much what we do, but the fact that we’re hyperaware of what we do.

I can’t help but wonder whether we’ve found a nugget of gold: process and practices may not matter so much, compared to a team taking an active interest in their way of working, with the self-awareness and authority to say: ”This shit is not working. Let’s try this other thing instead”.

This element of self-improvement is often listed as a practice in Agile methods (Retrospectives), but I don’t think it needs to be exclusive to Agile methods.

If a ‘traditional’ project was composed of team members hell-bent on self-improvement, I believe the process could be tuned to some kind of optimum, toward a pragmatic, well-oiled code of conduct. I don’t think the result would be Agile, but I’m pretty sure it would help the team deliver.

Permalänk Kommentera

Reading on circumstance

juni 2, 2007 at 18:02 (Process, Reading)

It’s been a quiet spring from me, at least as for this medium. Busy and overwhelming year, this one. I’ve had some time to read, however, and I thought I’d post something on the two latest titles.

First out is Extreme Programming Installed, which takes a practical look at Extreme Programming. I’ve been looking for a book like this ever since I read its older sibling Extreme Programming Explained, the original work on XP.

Jeffries, Anderson and Hendrickson do a great job of explaining the practices in detail, supporting the reader and offering tips for how to make XP work. It’s much more fleshed out than what I’ve read so far, with good examples of planning, automated tests and steering. I sometimes think Ron Jeffries’ zen-style of writing can become tiresome, but I thoroughly appreciate his experience and his ability to share it.

I expect Jim Shore’s and Shane Warden’s Art of Agile Development (beautiful cover image, by the way!) to grow into something like this, and I’m looking forward to reading it in paper form.

Second, I finally took the time to read Fred Brooks’ classic: The Mythical Man-Month. It’s fascinating to learn of his experiences in 70’s OS development, and that the hurdles in project management are still mostly the same. I got my hands on an anniversary edition with four new chapters from 20 years later than the original texts — this was also really interesting to see Brooks look back on his earlier work.

I think what captured me the most was that so much of the ideas founded around managing software projects were so tightly bound by the technology. In fact, I would argue that’s still the case. Brooks comments in a section that the microcomputer revolution has antiquated many of his previous ideas, and I think that many truths around software project management then, as today, may be based on assumptions of context that may not necessarily hold forever.

As an example, Brooks at one point argued for a project workbook to be maintained, that is, a complete set of all relevant documentation for the project collected in a single set of binders. The idea was to increase the availability of information, so that every project member had the whole view at their hands at any one time. In order to make it easier to follow recent changes, a change log would be maintained. That way, you could pick up what was changed in the potentially massive body of work, and see if it had any effect on what you were currently doing.

In 1975, this was probably as good a way as there was to share information. 15-20 years later, an intranet or project web would be the modus operandi, and these days, agile proponents argue you should just Sit Together. I think it makes sense to always revise what you’re doing and why, and whether it still makes sense for the type of work you’re doing in the context you’re doing it and with the tools available.

Good books, both of them.

Permalänk Kommentera

The worst estimates are the ones you never made

februari 11, 2007 at 15:54 (Process)

I’ve become really interested in estimate techniques lately, partly because of my infatuation with XP but also because I’ve noticed that no matter how much time you spend estimating, it’s still exceptionally hard to predict a done-date with any certainty.

We’re currently trying out task planning with a point-based system for estimates.

Every task is jotted down on a sticky note, and given an estimate of either

  • 1 – trivial,
  • 2 – some work but manageable, or
  • 4 – lots of work, partly unknown.

Estimating size or difficulty rather than time makes it much easier to produce estimates with proper relative sizes.

We’ve noticed that our work rate of points/week (XP calls this velocity) is pretty constant, at around 24 points.

From the velocity, total number of estimated points and enough history, we can predict a done-date by projecting a trend that follows our extended velocity. We don’t even need that much history, in our case we’ve been predictable enough that two-three weeks has been enough.

There’s one catch I’ve noticed, though: The rate of points/week remains reasonably consistent, but the finish line — the sum of all estimated points — keeps moving.

I believe this is the primary reason why agile planning doesn’t use task estimates for long-term planning, but rather bases forecasts on feature estimates.

With task estimates, the finish line changes constantly as we discover new things we need to do to meet the scope or things that aren’t strictly necessary to get there.

If features are estimated relative to each other using a point-based system, the only way the finish line would move would be if the customer changed their mind on the scope of the project (barring a bus incident or some other unexpected event.)

After this insight, my ambition for future projects is to try and focus on breaking down requirements into valuable chunks — features — and estimating them in relative sizes.

No doubt that will prove to be difficult in other ways, but it should not cause the finish line to chase the sky, unless more features are added to the project.

Permalänk Kommentera