Cleaning under the stair

Every time I do gardening (in our very little garden area) I get struck by the natural flow of clean-up thinking. I don’t know how other amateur home garderners do, but it’s hard for me to think of doing it without the non-consious thinking of cleaning at the same time as putting new features (plants) on.

The other day I bought some new flowers to put in pots on our stair – our new little beautiful features you could say if you’re in system development business. To be visible for us and visitors (users I guess) as soon as you come to the stair. Also we have some sad plants that severerly needs re-planting or they’ll die or look very ugly.

Before putting them on the stair I need to do some work – that is planting the flowers in some pots with new mould.

I need just to bring out the pots and mould bag from under the stair, and Ouch!! here it looks like a mess! (Ever got that feeling when working on software??)

What to do? Ignoring the mess? Just drag out the (dirty) pots from the spider nets, close my eyes and plant my new features (flowers).

I already know what will be the consequence of that decision..  the stair will have some bad looking dirt under it and next time it will be even worse to put new features or re-plant old features (flowers) in the garden.

I do a quick calculation of risk. What IF I will now do the not so pretty work of cleaning under the stair? What could happen if I do that now?

Worst case scenario is that I start cleaning and get interupted by some unexpected event today that will make me leave the garden for some more important or social event. Will my plants survive another day without getting new pots?

Well, ONE day or maybe two they might survive. Some of them are more sensitive. I take the risk of cleaning, I know it’s worth it.

I start dragging out the stuff from under the stair, and start cleaning. Washing up the pots, brush away the dirt, hunting away a huge spider keeping my head cold since little son is watching (mummy’s not bothered by a little friendly black huge spider at all… right).

Have placed the new plants in a friendly well organized spot so they won’t fall.

And actually, the cleaning did take some work but not as bad as it looked like at the first glance. I made some decisions during the action to NOT clean exactly every garden tool, every little pot plate with water. While cleaning under the stair I could see the bikes connected to it also could need some washing up. But hell no. Stick to the scope here. The mission was to put new features (plants) on the stair and taking care of some old ones, not to fix the bikes.

Be aware of scope and mission.

Now to the plants. Quick risk calculation. I might get interrupted. With two little kids that wouldn’t be a surprise. So which of the plants could die first if they don’t get new mould?

One new one and one old one it seemed. So I start with them of course. And just them.

Start with the high risk items!

If something will happen on the way and I have to stop, at least these two will not die and the other ones will probably survive a few days.

For very harsh interruptions such as urgent long time sickness, I cannot plan. The features (plants) I guess have to die if something really bad would happen.

The first two plants get in their pots.

Next item, hmm.. which one. I’ve promised husband (stakeholder) to re-plant a sad old one with little chance of survival). I have another new one waiting. Hm..

Well, not a very complex environment – in this case it really didn’t matter that much which I chose. I went for the new one and got time to re-plant the old one  – since I already had a nice clean pot to put it in it was quite quick done.

In a complex environment I would have done some calculation, maybe a user test with my husband and son on how important the old sad one was compared to the new flowering one. They would have made the decision.

The message here is just:

In our daily lifes the effect of cleaning and prioritization is so obvious. It’s natural.

How do you think about cleaning your system stuff? Be it code, tests, requirements, documentation, storage..? Do the same natural law of risk calculating, mission focused, cleaning apply?

If you act the same way when working in the garden (or whatever item-cluttered hobby you might have) as when working with systems development how would your garden (fishing equipment, book shelf, diving gear, antique collection, whatever) look like by now?

2 dagars agil coachning av 150+ proffs för 2000 spänn

Tycker du det är dyrt med agil coachning? Missa inte konferensen Agila Sverige nästa år, som just gick av stapeln i Stockholm. Där får du 2 dagars professionell coachning av 150-200 erfarna ledare, utvecklare, designers, testledare, projektledare, verksamhetschefer, IT-ansvariga, filosofer,  pedagoger, samhällsvetare mfl

Insikten kom till mig på vägen hem. Denna återkommande konferens, ordnad i enkelhetens namn, innebär oavsett om du är proffs eller rookie i området att du får 2 dagars personlig coaching av väldigt många agila proffs och möjligheter till att ta del av erfarenheter, nya och gamla kontakter, roliga historier, personliga samtal, rådgivning, underhållning, praktiska tips och filosofiska resonemang om kommunikation, design, system, teknik, politik, religion, verksamhetsutveckling, organisation, teamutveckling och allt annat nödvändigt för att vi ska kunna leverera det våra organisationer är till för – att skapa en kund – må den vara medborgare, medlem eller konsument.

Det är nu 5:e (?) året jag deltar och utbytet ökar. Fiskdammen har mognat till ett event av direkt, praktisk och filosofisk coachning.

Några ämnen som var uppe som jag lyckades fånga

– Form och funktion – är samma sak. Varför skilja på design och utveckling?
– Inkludera människor i ditt team istället för envist försöka assimilera. Bjud in!
– Tänk nästa steg när du funderar på att byta riktning – vad kommer efter ditt val nu?
– Metodöverflöd. Det finns en enorm mängd fantastiskt användbara metoder idag för att leverera nytta – Innovationgames, Lean Startup, Real Options, UX (User Experience Design)-områdets stora skara av metoder, Stop-the-Line, Kanban, A3-förbättringar, Toyota Kator, Enkla checklistor, Programming Anarchy… listan kan göras oändlig. Välj en – prova på i 30 dagar, utvärdera, förbättra och/eller välj en annan nästa 30 dagar.
– Det finns goda exempel på hur verkligt självorganiserande organisationer kan fungera, se t.ex Valves handbok för nyanställda även Länsstyrelsen Karlskrona omnämndes i det sammanhanget. Hade velat höra mer om
– Kommunikationsskuld. Den skuld du bygger upp genom att avstå från nödvändig kommunikation. Ungefär som teknisk skuld. Det du inte gör något åt idag börjar du betala ränta på, skulden växer tills dess du tar i tag och börjar betala av skulden. Hur har du det med kommunikationen med dina leverantörer eller beställare egentligen..?

Agila Sverige är ett smörgåsbord av tillfällen till coachning och lärande.

Nya boktips från pedagogiska mästaren Tobias Fors – The Power of Learning och Thinking fast and slow

Om man upprepar något tillräckligt många gånger blir det sant. Några saker behöver upprepas och påminnas om många gånger, bl.a perceptuell blindness, testa själv på

Awareness Test: Basketball players

Har du verkligen koll på allt?

Och det ständiga upprepandet av mantrat:

”Be inte om tillåtelse, be om ursäkt efteråt”

kommer snart ge resultat i våra organisationer – förväntar mig större turbulens och större förbättringar på arbetsplatserna för kunskapsarbetare närmsta åren..

Och sist men inte minst, den ständigt och självklara upprepandet på denna återkommande konferens – frågan

VARFÖR?

Det resonemanget tror och hoppas jag blir nästa års fördjupning.

Tack till arrangörernas idealistiska och aldrig svikande engagemang för att se till att vi har ett forum som utan att kosta skjortan kan ta oss ytterligare ett litet steg framåt i evolutionen av våra system.

Snygga bilder på några av dessa 150+ coacher finns här…  fotat av.. vem var det? Joakim S?

Foton Agila Sverige Dag 2
Foton Agila Sverige Dag 1

Tests aren’t about testing – Scandev 2012

At Scandinavian Developers Conference April 2012 there were some rememberable messages about testing – what I heard tests aren’t anymore about testing, if it’s ever has been.

Kevlin Henney @KevlinHenney first mentioned the message on testing in his keynote which was really about architecture and good coding – such as economy, visibility, spacing, symmetry and emergence.

About testing he said,  the point of automated tests is NOT how many tests you have,  it is in the meaning of them. To explicitily state rules, to know exactly what we mean in a row of code – that’s the point of testing

Tests turns belief into knowledge.

Gojko Adzic, @gojkoadzic, test and requirement change agent, told us the story of a French team that threw away their automated tests as soon as they’ve passed.  They used automated tests as a

shared understanding of what to do very effectevily

rather than a tool for testing.

He busted a lot about myths of BDD (Behaviour Driven Development) and the challenges on understanding of it from business. He called it

Businessting – the belief business users could write acceptance tests

I’m happy he brought this challenge up. I’ve seen so many teams waiting for business to suddenly show up with very clear, ready to automate, covering test specifications at exactly the right level. Gojko reminded us of the importance of conversation with business people on the rules, on the examples, on the code that’s gonna be written.

The main benefit of Behaviour Driven Development is that is supporting us longterm with information on what the system does – therefore you don’t always need to keep them tightly integrated to the code when they have passed once (!)

We’re obsessed with wrong details.

Jeff Patton,  reminded us also of conversation with business, and of the thing many of us seem to have forgotten about user stories.

User stories, no matter in what written template, was in the beginning there for the purpose of making business people telling stories! Stories about what’s happening in the business, and what could be happening in the future. Now many asks about how to write correct user stories, rather than asking their business person to tell.. their story.

So whatever we do we need to find ways to include business people in our daily conversations 

This seems to be the greatest challenge when it comes to Agile.

Mary Poppendieck, always insightful, brought the subject up of the importance of whole product team. She said we need to let go of ”software development” and talk about what we’re actually doing – product (or service) development to get business on our team so we can do great products and services.

If we believe in whole product teams, which I guess we do if we want to deliver good stuff, software development teams need to start to talk about products (and services)

Go from programming language to design language.

Use movie making as inspirational process for up front design

At Scandinavian Developers Conference Agile UX inspirator Jeff Patton brought up a lot of interesting stuff.

One of the things that sticked was he mentioned we should be inspired by movie makers when doing up front design and making decisions early in the development process.

(I blend some of my own thoughts with Pattons here, since I often use film making as a metaphor for development processes, so not all are exactly citations..)

When movie makers are looking for investors they cannot come with empty hands and say ”we will see what happens when we start making the movie” Some up front job needs to be done.

Movie makers make a lot of sketches, an early unfinished story board, outlines of the whole movie. They present the outlined story, investors make decision based on the idea presented and not the details! Investors know the finished movie will not look exactly as the outlined story board, and a lot of changes will be made during filming.

This we should learn from when making decisions on software development. We don’t need every detail when doing up front design to make good decisions. Of course, as in film production, there are always risks when investing. But specificing every detail up front does not manage risks!

How much UX design is needed up front before starting programming?

Often UX designers want to do everything up front, by old habits. And then leave it to teams to do whatever they want with it, it’s the production teams problems – I’ve unfortunately see and hear stories about this not very productive way of working. Agile teams want in stead to do very little up front and often have a hard time to know how and why integrating UX people in teams. These two communities need to find the balance, and movie making can help.

Search on ”story mapping” and you will find many inspiring ideas from movie makers on how much design needs to be done up front.

Image from Jeff Pattons presentation at Scandev:

Det självklara receptet för framgång i projekt

Under ett flertal kurser har vi bett deltagare (ofta, men inte alltid, erfarna projektledare) att beskriva ett projekt de varit med om, på jobbet eller privat, som varit särskilt framgångsrikt och vilka förutsättningar och faktorer som fanns på plats.

Det som är utmärkande från dessa samtal är att:

– alla, oavsett erfarenhet, kan beskriva minst ett projekt som varit en framgång
– alla kan med enkelhet identifiera vilka framgångsfaktorer som låg bakom
– uppräknade framgångsfaktorer är till 95% i linje med principerna i det agila manifestet.

Vid senaste tillfället, på kursen ”Att leda och driva agila projekt” på Frontit, så reflekterade deltagarna över den på något sätt självklara uppräkningen. ”Vi sitter ju själva på svaren – varför GÖR vi inte detta hela tiden?”

Här är deras framgångsfaktorer och recept för framgång i projekt:

SCOPE (Omfång)

• Inte för stort
• Akta svällning

VERKSAMHET OCH KRAV

• Verksamheten med, hela tiden
• Närhet till kunden, har mottagaren med sig
• Har med sig kravställare och engagerad kravägare
• Visa skarpt mot beställaren
• Engagerad beställare
• Förberedelser, kratta manegen

MÅLBILD

• Tydligt mål
• Förståelse – alla drar mot samma mål
• Delmål – driv mot målen från start med timeboxar
• Beskriv VAD vi ska lösa, inte hur

TEAM

• Alla var där
• Folk engagerade
• Hålla lusten vid liv!
• Fira segrar
• Tät grupp
• Kräver närarbete
• Tydliga roller
• Emotionellt/funktionellt perspektiv

STYRGRUPP

• Engagerad och aktiv styrgrupp, som är påläst och tar sitt ansvar
• Utbilda styrgruppen

KOMMUNIKATION

• Kommunikation – intern och extern
• Samma språk

UPPFÖLJNING OCH UTVÄRDERING

• Utvärdera projektet löpande – och korrigera på vägen
• Ha bra uppföljning – hela tiden

VÄRDERINGAR

• Prestigelöshet

Grupperingen har jag gjort nu för att det ska bli lättare att läsa, säkert skulle någon av deltagarna valt en annan gruppering.

Efter att ha fått liknande faktorer vid olika tillfällen är det värt att särskilt uppmärksamma Team-faktorerna. Vi bör inte underskatta värdet av sammansvetsade team för att nå framgång. Tyvärr verkar detta bli mer och mer ovanligt i projektvärlden. Tillfälliga projektmedlemmar, projektmedlemmar på distans, splittrat arbete, lokaler som inte är anpassade för teamarbete, liten tid och inga pengar för  teamstärkande aktiviteter mm gör att vi slår undan benen för oss själva när vi försöker driva ”projekt”.

Själva idén med ett projekt är en fokuserad insats under en avgränsad tidsperiod som samlar olika kompetenser för att få ut nytta av teamorienterat arbete.

De organisationer som arbetar med långsiktiga team, dvs samma team – olika projekt eller utvecklingsaktiviteter, verkar nå större framgång. När glömde vi bort team-tanken i våra projektorganisationer?

Som projektledare, eller för den delen vilken roll som helst jag får i ett projekt, säkerställer jag numera att dessa faktorer (och synonymer) finns på plats innan jag gör ett åtagande som deltagare. Om de inte finns på plats när jag kommer in frågar jag vad vi kan ta för steg för att få dessa på plats. Vid t.ex distansarbete kan kreativa lösningar för närhet hittas, det finns exempel på detta. Om situationen är ”omöjlig” avstår jag hellre än att fortsätta kasta pengar i sjön genom att spendera beställares investeringar i arbete som inte har eller kan få rätta förutsättningarna att lyckas.

Hur gör du?

Why Swedish organizational culture is still very hierarchal

This insight has recently got very obvious for me.

Swedish management seems to be quite famous, both inside and outside our national borders, for being ”softer”, ”open”, ”inclusive” or less hierarchal than many other countries. This is true when it comes to law and sometimes organizational structure. We don’t get fired for going to our boss telling them what we think. We might get an evil eye or two, but we don’t get fired, which is a huge different from many other cultures.

The law makes it very hard to fire someone, you really need to have very strong motivation.

Jan Carlzon who got Swedish leadership style famous by introducing the ”flat organization” in the 80’s I believe made a huge difference in his organizations, where transformational leadership was encouraged, teached and spread, where co-workers were supposed to take an active part in the development of the company. How much impact this style had in the 80’s I cannot tell, all I know is that today, in the 2010’s it seems not very common to include co-workers in the actual running and development of business. It’s common with ”co-worker-feedback-meetings” where ordinary employees are allowed to ask questions (often in a big room) and give feedback to managers proposals. And with one or two yearly kickoffs where management try to collect input on goals and vision from their employees. But to actually take an active and trusted part in developing the organization seems less common. I do see signs of change, and the change might go very quick very soon, if we allow us.

For all I know both managers and co-workers in most Swedish organizations have a very very strong culture of pushing all decisions to the one titled ”manager”, it’s managers deciding which projects are having a ”go”, it’s all managers in steering groups (why?? Is anyone actually still believing in that the manager has the most current and relevant information to make good decisions?), the teams always waiting for the manager to tell them they’re allowed to be more agile, get the stuff they need etc. In steering document I read it’s said that the mangers are making the important decisions. Where did the ”flat” structure go?

In the organizational schemes I see there’s always a manager on top of each box, solely responsible for the boxes success or failure. In steering documents it is said the manager(s) are responsible for project success or failure. What happened to the co-workers responsibility? Why aren’t the teams or groups of workers included in organizational charts?

Also, which myself is suddenly very aware of, are we – the co-workers behaving as expected. We never question the manager-run boxes, we go, without even reflecting about it, to the manager for each little decision that needs to be made.  Since we won’t get fired for going to the boss and tell them what we think, it IS very strange we don’t go to them with other questions than ”signing this decision” more often. We are so scared of our feudal leaders, we don’t dare to call them up in the phone and tell them we think the company should do investment A or withdraw investment B.

Someone told me, I think it was Diana Larsen or Esther Derby, that often the boss, the big manager, the CIO, CFO, whatever, actually WANTS the co-worker to knock on the door and ask for a chat. The thing is we’re so into this hierarchal mindset that we’ve never actually think it could be so easy. The separation of classes doesn’t exist anymore in Sweden (though segregation does) but we still act as if it was so, even though you and the boss went to the same school, or have your kids at the same kindergarten or are both members of  the local climbing club.

It’s all about our mindset. We gaze up at the top wondering why they won’t let us do the business. We’ve never even asked for it, and when we get promoted to managers ourselves we forget the intrinsic power we automatically get by title and just go ahead in our meetings with other managers wondering why the organization and business is so slow.

Each day businesses need to make many many decisions. To limit the power of the organization to the manager bottle necks with consequences of slowing down business isn’t this against all business reason and wisdom?

To not make use of the current knowledge, experience and information residing in co-workers to make well grounded decisions in the right time without delay, isn’t this a terrible waste ?

Inject agile by coaching?

Is it possible to inject agile in an organization by hiring an ”agile coach”? To cut lead times, getting to market faster, be adaptive for fast changes, and make your customers happier?

This is what I believe is true about agile coaching:

1. The agile coach as a full member of team

When you put an experienced coach as a full member in a team, in a role where his main assignment is to do some ”real” work like testing, developing, requirements whatever and also has an explicit coaching role there is a good chance the team will getting more agile, if they have the right motivation.

If the coach also have the mission to pass the coaching role on, to one of the team members, there is a chance the team will continue being more agile after the coach is gone.

Being part of a team, doing real work, and passing the coaching role on is crucial for a longer lasting impact of new agile practices.

What else happens when the coach leaves the team?  Good chance of regression to old habits, I’ve seen it quite some times.

If you’ve hired a project manager with assignment to introduce agile, it’s very important to be aware of her power as a ”manager” even though you might not see it. The team may not be committed to the new way of working and the new process might quickly disappear when the project manager is gone.

The project manager also has limited influence on what actually happens at the bottom line – where the work is actually done, in the craft. The project manager needs one team member, someone doing the craft, who is also an agile co-coach, to make stuff happen all the way. And agile stuff needs to happen all the way into the craft, otherwise you’ll soon find yourself in trouble with delivery, defects and budget.

As a project manager you can suggest technical agile practices such as pair programming, test driven development and more but you cannot make it happen unless one craftsman will be your co-coach.

It takes two to tango.

2. Coaching by Kaizen – Continous improvement

If you already have a complete team, don’t need more people on the work, and still want to inject some agile in the organization, I believe an agile coach can do good without being part of the daily work. This by in a disciplined, structured and inspiring way run Kaizen activities, for example retrospectives.

With regular intervals the agile coach can facilitate retrospective workshops with the purpose of getting the team by themselves suggest what process changes they’d like to see, help them with tools and preparations to do the analysis and action plans and commitments by themselves.

If you hire such a ”kaizen coach” you will let the team decide what will happen. As a manager you cannot decide or foresee the outcome or actions from these retrospectives. Ideas that you never imagined yourself will start to come out after a while of continuous retrospectives. Some ideas you’ll like, and some not – ”We don’t need a manager anymore” could be such a thing. Are you prepared to hear this?

I believe this way of working with agile injection could be the most effective and long lasting way of changing a team or organization. Since they have themselves chosen what changes will be done they for sure will be committed.

If you also believe this could be true, are you prepared to give the team(s) a basis to act on their improvement suggestions? This could mean time (for example 10-15% work time each month just on improvement actions) or money (pay for tools, people or other resources that the team suggests) or politics (changing premises, HR policies or process conventions for example). Are you ready to help the team?

I have seen teams excel by having ambitious retrospectives each week up to each 3rd week. Some people say that just by running a lot of retrospectives or kaizen activities all software teams will after a while come to method suggestions very much like Extreme Programming.

If you’re not working with software I would not be surprised if all teams after a while of disciplined retrospectives will come to more and more agile principles,  values and practices. ”Sit together”, ”Visualize progress”, ”Working closer to customer”, ”Small batches” etc.

Are you ready to walk this path?

The reward will be high performing teams, delivering value fast to market and a healthy and innovative organization.

You will need to invest.

3. Informal coaching

The next coaching style I believe is actually working is personal, informal coaching. Eating lunch together regularly, or having coffee or running a course together or just spend time together in some way. I have mostly in this way learned what all this agile is about and also to see other aspects of this that you cannot read in a book, technical as well as human.

No one told me these people would be my coaches, the coach relationship just emerged lasting long and changing me a lot.

This is deep change. As a manager, if you want this to happen with your people, just pay a little bit attention when you see some informal coaching relation grow between sometimes unexpected co-workers or an outsider. Don’t ask them why they had such a long coffee break today or why they don’t spend more time with the hired coach.

Let it be.

These are the 3 styles of agile coaching that I’ve seen working, heard stories about, and been part of myself in one way or another.

The large scale ”agile process change projects” could work if you focus on the three things above.

Kvalitet och kommunicera lättrörliga krav – Sundsvall 42

Under konferensen Sundsvall42, som pågick den 18-20 oktober 2011 höll jag ett seminarium på tema ”Att kommunicera lättrörliga krav” i spåret ”Kvalitet” med undertexten ”Ok, nu jobbar vi agilt – är det bättre eller inte”. Flera frågor att svara på alltså, hur gör man det på 40 minuter?

Dessutom var det skrivet att detta är ett seminarium, inte en föreläsning, och min tolkning av seminarium är att det innehåller interaktivitet. Hur gör man en workshop i en biosalong med 60 deltagare?  Det finns säkert bra svar på det, det sätt som dök upp i huvudet på mig inför konferensen var att låta deltagarna refklektera omkring begreppet ”Kvalitet” och hur det kan tillämpas på kravarbete i en alltmer snabbrörlig värld – och dessutom dokumentera on the fly i Prezi. Att servera färdiga svar när det sitter 60 erfarna testledare, kravare, förvaltningsledare i publiken känns på något sätt.. omodernt – det måste finnas bättre sätt. Färdiga svar är bara att googla på – som min nyfunne digitala kamrat @erkstam sa under sitt föredrag om digitalisering.  ”Googla på mig så kan vi skippa hela den där presentationsbiten.”

Googla på ”Agile requirements” så hittar du en del, eller varför inte skaffa ett Twitter-konto tillslut och fråga där! Twitter är en fantastisk yrkeskunskapsbank för tips om artiklar, bloggar, rapporter mm. Om du hittar mig där (@ulrikapark] kan jag hjälpa till lotsa till intressanta grupper där du kan ställa frågan, eller så retweetar jag din fråga. Några tips från mig på tekniker och annat finns lite längre ner.

Prezi-dokumentationen från seminariet  (via traditionell dator behövs inget login). Jag försöker också få ner resultatet här i en något mer fyrkantig form som kanske är lättare att skriva ut. Tack till Ulf Eriksson, Reijo Soréus, Azim Rezaei, adjunkten från Mittuniversitetet och alla andra mycket kloka personer i lokalen som bidrog till ett facit, ett av flera multipla sanningar, för HUR vi bör jobba med krav för att uppnå kvalitet i de system, produkter eller tjänster vi levererar.

Några associationer  deltagarna gjorde till begreppet ”Kvalitet”:
(alla 60 kommer redovisas i separat inlägg)

LEVERERAT ENLIGT BESTÄLLNING

Vad kan vi göra när vi arbetar med krav för att bli säkrare på att leverera enligt beställning (”det får kosta så här mycket, jag vill ha det här”)?

Deltagarnas svar:
Var TYDLIG! Hur blir vi tydliga? Genom DIALOG och MALLAR t.ex User Stories.

Detta brukar jag kalla ”Extreme Expliciteness”. Extrem tydlighet alltså. Att använda krav&test-tekniken ”Specification by example” (Gojko Adzic har skrivit bra böcker i området) i kombination med user stories (Mike Cohn) är mycket användbart för att uppnå extrem tydlighet.

INGA FEL

Vad kan vi göra när vi arbetar med krav för att bli säkrare på att det blir rätt – inga fel?

Deltagarnas svar:
Test & granskning i iterationer!
Demos!
Flera iterationer över ett och samma krav!
Användarmedverkan!
Utvecklarmedverkan!

Inte bara kravaren är med i kravställningen alltså! och involverade på riktigt – mitt tillägg. Det räcker inte med att göra en workshop en gång där man ”samlar in krav” utan utvecklare och användare behöver vara med och påverka kraven löpande under hela genomförandet. Bästa sättet att lära sig mer om detta är att börja pröva idag!  Vad hindrar dig, ditt team, din organisation från att iterera över ett krav flera gånger, eller att involvera utvecklare i processen? Vad kan DU göra för att påverka det i små steg? Sitta 1 dag i veckan hos IT-leverantören? Sitta 1 dag i veckan hos din kravställare?

TRYGGT

Hur gör vi för att uppnå trygghet med kraven?

Deltagarnas svar:
Prototyper
Verifiera kraven, genom demos
Prioritering!
Kommunikation!
Rätt människor med

Ramverket Scrum innehåller många verktyg för just detta – tvärfunktionella team, prioriterade product backlogs och kommunikation och synlighet genom regelbundna demos och tvärfunktionella planeringsmöten (sprintplanering).
Scrum på 5 minuter.
Confessions of a serial Product Owner

ANVÄNDBARHET

Kvalitet är användbarhet. Hur uppnår vi användbarhet när vi arbetar med krav?

Deltagarnas svar:
Prototyper
Användningstester

Mitt tillägg: Engagera en duktig UX-designer (användbarhetsexpert ibland kallad) i teamet – som arbetar med teamet löpande genom hela genomförandet, inte bara i början eller i slutet. Personliga tips: Anette Lovas – Connecta, Fredrik Lindersson  – Söderhavet, Johanna Särnå – Valtech,  Sigrun Tallungs – Frontit, och säkert en hel bunt till därute t.ex på Antrop och Transformator Design.

Intressanta artiklar om User Experience Mapping

HÅLLBAR

Hur uppnår vi krav som håller över tid, är aktuella mer än 3 månader?

Deltagarnas svar:
Tydliga mål!
Gå ner på djupet! Gå ner på domänen och förstå varför.

Mål håller ofta längre än detaljerade krav. Vi ändrar inte målen varje dag, däremot gärna detaljerna beroende på förändrade omvärldskrav eller förväntningar.
Informationsobjekt/domänobjekt håller också längre än detaljer i funktionalitet är min erfarenhet. En informationsentitet – eller domänobjekt – (beroende på vilken ”skola” man pratar med) ändras inte varje dag när man väl lyckas förstå och kommunicera vad det är för objekt ”begrepp” vi pratar om. Därför är domänobjekt t.ex utmärkt lämpliga för att strukturera krav- och testdokumentation omkring, eftersom dessa strukturer håller över tid – åtminstone bra mycket längre tid än en user story.

Dessutom så vid de tillfällen jag varit med vid begreppsmodelleringsworkshops ”med rätt människor med” så har betydligt djupare insikter kommit fram om kraven. Insikter som kan vara både besvärliga och kännas omöjliga, men som verkligen bidrar till en djupare dimension av kravförståelse och detta kan förhindra allvarliga misstag och belysa nödvändiga samband och förändringar. En teknik som används alldeles för lite – eller för stelbent gömt i någons kammare, i ett hemligt filarkiv som bara vissa personer får åtkomst till. Sprid denna teknik!

Tips: Använd SMARTA mål. Googla på SMART goals. Eller fundera på vilka dina klarkriterier är. Beskriv, definiera vad ni menar när ett krav är ”klart” så har du ett mål definierat.
Tips: Arbeta med Domain Driven Design eller Begrepps-/informations-/domänmodellering. Förstå er verksamhet genom modellering. Ta hjälp av duktiga modellerare, kanske finns en ensam arkitekt någonstans hos er som inget hellre vill än att bli inbjuden till teamet och kravställningen? Eller en utvecklare som brinner särskilt för domänförståelse och modellering?

PORSCHE

Hur kan vi arbeta med krav om vi vill skapa en produkt/tjänst som är av motsvarande kvalitet som en Porsche?

Deltagarnas svar:
Smakar det så kostar det!
Sätt rätt förväntningar! Det kanske är ok att det blir en Trabant, bara förväntningarna är satta och kommunicerade så.

Min kommentar: Om vi förväntas skapa de administrativa stödsystemens motsvarighet till en Porsche, eller the BMW of kundtjänstsystem – då behövs det resurser för krav. Vi behöver antagligen flera olika kompetenser – analytiker, arkitekter, ux-designers, exploratory testers.. i teamen. Det räcker inte med en verksamhetsrepresentant på 30%…  Vi behöver också acceptans för att det kostar tid av flera personer i verksamheten såsom affärs-/verksamhetsutvecklare, strateger, domänexperter, personal att delta i användningstest, workshops mm.

OM VI HAR MÅLET ATT GÖRA ALLT DETTA, disciplinerat och ett steg i taget, visst kommer kraven hålla högre kvalitet?

Tack för orden och berätta gärna nästa år på SU42 hur det går med kraven!

Om jag hade trotsat programmet och hållt ett föredrag i stället, hade det jag tagit upp varit just dessa saker. De exempel jag hade med mig handlade om – Tydliga mål, begreppsmodellering, prioritering (backlog), user stories, specification by example och experience mapping – enklare version. Hade inte haft en chans att få med allt – t.ex användningstester och iterationer, så tack till deltagarna för att vi fick med mycket mer än jag hunnit med ensam.

De exempel från verkligheten jag tänkt visa upp finns lite av dem i Prezin. Vid något tillfälle ska jag försöka producera en artikel här om ”exempel från verkligheten på lättrörliga krav”.

Happy development!

Wikispeed and Agile @ universities – ALE2011 – Berlin

2 weeks after wonderful Agile Lean Europe unconference in Berlin, there are many things that stick.

One of the things that stick is WikiSpeed, this lovely project of developing a car going 100 MILES PER GALLON – with a self organizing distributed team with people in a lot of countries contributing to the project. People saying that agile cannot work in distributed teams could pay a visit to WikiSpeed on YouTube.  Thx to Thorsten O Kalning (@vinylbaustein) for giving us a ”everything is possible” mindset.  It’s possible to design and build a car that goes 100 miles per gallon! It’s possible to apply object orientation in car and make modules and parts that can be changed during driving. This is the car I’d love to drive.

Marc Lainez (@mlainez) and a couple of other people asked the question ”Why don’t you speek about agile and Lean at universities?”  I couldn’t find an answer in my head. ”Time?” If you have the time going to conferences or speaking at seminars or in community groups or whatever, you could trade some of that time and spend it sharing experiences and insights you’ve gained with the next generation? Insight gained from a lightning talk – if we don’t share – these students are gonna be our co-workers in a few years and probably we’ll need to first help them to unlearn some waterfall teachings they’ve studied hard to learn in school. (Not ALL university courses are like that of course, but far far too many). Why not start already in school. Share your agile mindset with next generations developers, designers and managers.

After this an idea of an ALE @ university day is forming at ALE Group at Linked In. The idea that is forming is to have a production game  or pair programming session with coaching, connecting students in many European countries online, with the help of students of course.

In the mean time – contact your uni and offer a guest seminar, speech, BDD-session whatever..

Story mapping session in the next post.. now it’s Saturday night right.

Former post on ALE2011 Berlin – Feature injection and Complexity theories

Complexity and Feature injection at Agile Lean Europe 2011 Berlin

While reading in news magazine Computer Sweden about all the big companies getting even bigger, and their sometimes so outdated strategies for development and business, I’m ready to agree with Brian Marick (@marick), saying that the only way being agile all the way is to start your own business. Several more people, among them Rachel Davis, said agile just won’t scale.

When companies are that big, you can make agile bubbles inside the company, networking with other agile bubbles in the company and have some changes happen. You’ll soon hit the system – HR, CEO bonuses, incitements, history, education and either you stay happy in your little agile bubble networking with your peers or you quit – and start your own business.

I still believe though you can make things happen with the mindset of the people around you in big business. I like being part of creating these agile bubbles all around, to see creative minds waken up from traditions, to dare to question ”the ways things always been around here”. That’s agile for me. Maybe you can’t turn an oil tanker around by doing Scrum, but you and your closest peers will learn a lot and have a lot more fun on the way and hopefully adding a bit more business value than usual.

Agile is a learning machine!  (Chris Matts quote I think, not good at remembering who said what)

Dave Snowden (@snowded) warned us agile bubble-creators that we’re in a danger zone of change and impact right now. It’s easy to get eaten by the old system when we hit the system right. So, he’s advice is you have to stop selling agile and start talking about it in other words! Now!

And that’s what Bjarne Bogsnes (Statoil) have been doing for a long time with the Beyond Budgeting movement, inspired and maybe strengthened by the spreading of agile thinking. I bring some of his words in my backpack. ”Event driven planning” in stead of ”Calendar driven planning” might speak to business people around there. And the metaphor: Having yearly budgets is like I had only 4 weeks a year where I could ask my bank for money. If it turns out the money is not enough the years consume and investments, I have to wait until next years ”open time” til I can get more money out from the bank, no matter what happens. And I have to spend a wasteful amount of time trying to foresee what will happen the coming year.

Dave Snowden also gave us another warning and important insight – it’s easy to get idealistic, to in the systems thinking way believe you can edit the process and then expect a certain outcome. That sounds like Lean thinking in my head. Make changes in the process and you should expect a certain outcome. Lean Software Development (and Lean in general) could probably add some complexity theories and improve to stay a relevant for the complex networks we act in, where there’s no one cause and no one effect.

Complex systems need constraints. Self organizing teams need constraints otherwise there is chaos. Compare with a self organizing birthday party for 10 year old kids. As soon as you draw an imagined border and say ”cross this and you’ll die!” team works getting better. Yes, we need management, nothing said about managers, but management. Constraints and Amplify/Dampen actions for the team.

Dave also gave a what we say in Swedish ”känga” (sort of a light kick) to all these Management theory x.0 books and courses. The same of old stuff. Anyway I think the ”Managment theory x.o” fills an important purpose. That kind of language talks to an audience normally not very attracted to ”Agile” ”Lean” ”Complexity theories” or whatever for them abstract and obscure strange name. Some hard core management words are needed to meet a wider audience, as long as we use them wisely. So for all of you that falls asleep when you hear about another Agile titled book, I recommend to buy Jurgen Appelos book ”Management 3.0 – Leading agile developers – Develop agile leaders”  and attend his course ”Management 3.0 – Agilt ledarskap i praktiken” in Sweden 24-25/10 at Citerus. Jurgen was one of the organizers of #ALE2011 and also got us bloggers a bit change management in practice at his talk. We’ll see if I change or not. At least I got the desire injected.

Here are More notes from Snowden’s talk.

Feature injection was a fun session with Chris Matts (@PapaChrisMatts), lovely British IT Risk Manager. dare to call himself a BA. (Am I the only one actually liking BA’s btw? They’re a competence all to often get wasted by putting them away in lonely rooms – not Chris I’m sure but a lot of his profession colleagues.)

”What’s the worst thing that can happen in a presentation?” he had a conversation earlier. What happened..  His session got feature injected by a minute of birthday party thrown by the lovely kid’s programme. Oana, one or two (?) of the kids mother was the happy celebrant.

Anyway Feature Injection, sort of a real application of pull system in systems development. Happy to see there is a theory for something I learned in a project not long ago – maybe a little too late – that YOU have to start with the recipient of your systems output, no matter who this is. This recipient, end customer or reader or whatever end user – has to first pull features developed from the systems. Ooach! This means that I really need to put end user’s first!? Again!? Oh all these end users all the time, please. It’s really challenging to implement this thinking, since the recipient often is a partner, who you don’t have really close development practices or relations with, or end users where the threshold for involving them early early in the process is very high – ”we’re only in pre-study”  ”we’re in such a hurry” ”the money doesn’t cover user recruitment..”

Anyway. Feature injection seems to be best explained by comics. And I love to hear about some real cases in Sweden. Will my case be the first, do I dare? I would for sure need some information/domain modeling expert, since the injection go all the way to the details of implementation.

clip from infoq.com. Whole comic

More about Story Mapping and ALE2011 in next post.

Thank you Caios for helping me out in a tough time
Thank you Tibault for great photos
Thanks to Olaf for spreading humbleness around
Thanks to Birgit for making me think.

Thanks to all people for being so friendly and bringing such a heartly atmosphere around you

What happened more in ALE2011 – Berlin – 7-9 sept