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

Projektledare – behövs de?

I torsdags kväll (25/8 2011) arrangerades debatten ”Projektledare – behövs de?” på Villa Ludvigsberg, Frontit/ProjektStyrning tillsammans med Dataföreningen Stockholm (projektledarnätverket). 50 reflekterande deltagare dök upp, och i startpanelen satt Andreas Larsson, Olof Melinder, Torbjörn Gyllenbring, Anders Ivarsson, Hanna Wallin, Carina Meurling och jag själv. Markus Ekelund, VD på Frontit modererade.

Upptakten var debatten som då och då blossar upp i diverse forum, än mer på sistone ju mer agile-rörelsen sprider sig. Vad ska vi ha projektledare till? Är det en utspelad roll på samma sätt som maskinskriverskor? Förhindrar projektledare ansvarstagande hos andra, eller är de nödvändiga för att nå ett resultat, koordinera och vägleda en grupp människor framåt som ska utföra en uppgift..? Är ScrumMastern den nya projektledaren?

Många frågor ställdes. Besvarade vi frågan under dessa 2 timmar? Skulle vi uppfinna projektledaren på nytt om det inte redan var en inarbetad roll?

Efter 2 timmars sansad diskussion och berättelser om situationer där projektledarens närvaro eller frånvaro påverkat oss på olika sätt, upplevde i alla fall jag att de stora tankarna började smyga in. De 2 första timmarna var ett ömsom lyssnande på andras perspektiv och vädrande av sina egna. Vi kunde konstatera att vi har olika erfarenheter av projektledare – allt från maktgalna kontrollfreaks till coachande, uppmärksamma hjälpande händer.

Det behövs någon som hjälper teamet att kommunicera, utåt och inåt, kanske kommer framtidens projektledare kallas kommunikatör i stället? Eller coach?  Det behövs också någon som agerar paraply ibland. En klok person i publiken sa att när solen skiner och allt är toppen, vem behöver då ett paraply som stör rörligheten? Men när det regnar och öser ner, är inte ett paraply bra att ha då? Hur ofta jobbar vi egentligen i ideala situationer för självorganiserande team?

Det kanske räcker med en ledare nånstans i bakgrunden som krattar marken, och verkar men inte syns, tyckte vi efter Andreas Ivarssons berättelse om ett projekt där teamet agerade helt själva – men naturligtvis hade det både bemannats och skrivits avtal och hållts kontakter mellan ”gubbar” eller ”gummor” för den delen med höga hattar. Kanske av gubbar och gummor som förstått vikten av att inte lägga sig i i onödan, som låter teamet blomma själv och bara ser till att teamet får vatten då och då.

Efter 2 timmar, halvt utsvultna, började diskussionen handla mer om långsiktighet, effekter och ansvaret för detta. Vi tror att styrgrupper och ledningar framöver kommer att tänka mer långsiktigt. Kanske kommer projektformen användas mindre och inte lika ofta för systemutvecklingsinsatser. Kanske kommer effektledare tillsättas snarare än just projektledare.

Jag tror att med lite lagom mat i magen och en paus hade vi kommit ett steg djupare. Om vi fortsatt 1 timme till hade kanske  de väldigt kloka frågorna ebbat ut till förmor för fler tydliga insikter. Detta var början för en grupp projektledare eller f.d projektledare att reflektera med andra över frågan. En fortsättning är nödvändig för att kunna ge några svar, och ta höjd för att det då kommer säkert krävas 2 timmar startsträcka för att de riktigt visa orden och insiktsfulla svaren ska höras. Jag är säker på att vi kan det.

Det var många som ville stanna kvar en bra stund efter debatten, trots hunger och sen kväll. Detta tyder väl på att detta ska fortsätta.

Eventuellt får jag möjlighet att sammanfatta debatten på 3 minuter under ett blixttal på konferensen ALE2011  (nätverk för Agile & Lean Europe) om 2 veckor. Vad tycker DU som var med att jag absolut måste ta med mig från debatten då?

Tack alla som bidrog genom att bara närvara, eller genom att prata, till en fantastisk diskussion.

Alla älskar vattenfall?

Jag tror de allra flesta organisationer (i Sverige iaf) numera säger att  de vill bli, håller på att bli, eller redan är agila. Åtminstone utifrån de berättelser jag hör och ser.

Vad väldigt få av de personer som uttalar sig om detta verkar vara medvetna om är att organisationen för att dra nytta av de agila metoderna, faktiskt på riktigt helt måste överge vattenfallsmetoden, och den viljan verkar än så länge bara finnas hos några få organisationer och personer. Alla verkar älska sin baby – vattenfallsmetoden, tryggheten, vanan, den kända marken, som visserligen misslyckas konstant men den är ändå känd och förankrad – Så här har vi alltid gjort!

Jag får ibland frågan att hålla utbildning i Scrum och agila metoder – då samtidigt med klausulen . ”Ja, fast vi måste självklart behålla nuvarande process med kravspecande och detaljerad analys och exakt tidsuppskattning innan projektet”. Vad svarar man på det?

alt 1 – Glöm det! Väx upp och säg till när ni är redo för att bli agila, återkom då, så sitter jag o gör annat så länge.

alt 2 – Ok! Kul! Hur antar vi den här utmaningen då? Vad kan vi göra tillsammans under utbildningen och efter för att se och förstå nödvändigheten av att överge babyn för att kunna adoptera en ny? Vad kan vi hitta på?

Hur är din approach?

Själv tror jag att så länge vi väljer att vara i konsultbranschen kan svaret i princip bara bli alt2, men att känna av klimatet ordentligt och faktiskt våga ge upp när det är för lång resa. Kanske är det något annat organisationen behöver först? Kanske gå utbildning i effekthemtagning och mål/visionsarbete, eller varför inte teamutveckling eller verksamhetsarkitektur eller något annat intressant. Scrum kanske inte alltid bör ha företräde i alla organisationer bara för att det känns modernt att säga att man gör Scrum? Det kan beställare tänka på . Vill vi verkligen överge vår baby – vattenfall? Vi älskar den ju så?

ps. för den som undrar. Den här bloggen får helt enkelt bli blandade språk.. ibland svenska ibland engelska.

Why estimation by email is a bad idea

It seems like the most common way to communicate between customer (for example a Marketing department) and supplier (for example a development company or a webb design company) is by email.

Email seems to be the most common way to ask for an offer or an estimate.

By working both on the customer and the developer side I very clearly have seen during 15 years of web and IT development projects, that making estimates through email communication is a very bad idea and a big WASTE. Why?

• Reading and make a correct interpretation of email descriptions of a design idea someone else has written, is extremely hard
• Email is very close to one-way communication. The ones reading your email are scratching their heads trying to figure out what you mean. To pick up the phone is very uncommon these days. The readers (suppliers) will try to collect all their questions in one email, in stead of 20 small ones – by the time for writing the email back, they’ll have forgotten half of the questions or think it’s to small to write in an email.
• Email is very close to one-way communication. The readers (suppliers) cannot share their own ideas of better solution or their questions
• Email communication takes TOO MUCH time for all people involved. The lead time from the customers idea to a fair estimate can be weeks. Bring the customer and supplier together for 1 hour (or video conference if the distance is too far), and you will have a fair estimate that same hour.
• When you finally reach some estimate by email communication after 1 week or more, there will be so much misunderstandings so when the service or functionality is developed there will be endless discussions about the estimate and  – who said what, who had the right intepretation. When you talk about design issues face to face there is at least a fair chance of common understanding.
• Email communcation wastes the creative minds of both the customer (writer) and the (supplier) reader. You’re not taking advantage of the creative nature of face to face communication where you can share ideas, draw, explain impediments, constraints, the purpose and develop the idea to a better and in the long run much cheaper one, by making a better solution for both you and your customer.

Please STOP this! And you will come much quicker to time to market – and have much more accurate estimates.

It’s very easy. By going for 1 hour travel time to meet your supplier to have a 1 hour conversation about some idea, you will for sure save many many hours in later discussions (by probably writing angry emails). And if they like you, you might be brave enough to ask them for a desk to borrow the rest of the day with your laptop so you don’t have to travel back that day.

Try this @ home and @ your supplier and you will both win the estimation game.

The system is you!

“Changing the system, will change what people do. Changing what people do, will NOT change the system.” (Peter Sholtes)

The system that people work in accounts for as much as 95% of performance, as Edward Deming said.

What Deming and his followers say, is that it’s no point for a manager to try to optimize the perfomance of workers, by pushing them to work harder, more, extensive training etc. Managers and others need to change the system, to make any visible change in performance.

So is there no need for you to change? To start take individual accountability for the environment you work in, and the conditions that stops you from doing what you believe is right?

They do NOT say that individual actions has no effect. Individual actions is another story.

Who created the system in the first place? People.
Who sustains the system we work in? People.
Who has the possibility to change the system? People.

In fact, the system cannot change itself. It has to be changed by people. Managers, co-workers, team members, people like you and me.

When you realize that YOU are the system then it’s easy to see that you can make a difference. By using courage to say NO to useless re-organizations, to suggest better ways or go to agile war.  To say: ”We’re not doing this anymore!”.   All successful organizations, revolutions and break throughs in innovations and working conditions has started with someone not aggreeing with how the system works.

If all people believed that individual action has no point, that it’s all about ”the society” to change by itself, women would still have no voting rights, dictators would still sit comfortably in northern Africa, we would still have feodal rulers everywhere, slavery would still be legal.

These are big changes that has happened. In the agile IT community we’re talking about much smaller changes. Like how our work places are arranged, how the team sits, what tools and routines we’re instructed to use or what internal politics says is right or wrong to do for you as a co-worker. So of course there is much easier for us to make changes. Small change – small revolution.

Have you allied with your team members lately? Do you want to use Kanban, but the project manager doesn’t? Do you want to do retrospectives, and your project manager doesn’t? You want to automate tests? Your manager says you don’t have time? Need a product owner on site? No one will give you that unless you do ask for it persistently, creatively and humble with a decisive look?

Get allies, as the labor unions did. When you’re 6 out of 9 in a team that really wants to throw out the document heavy process and put in face 2 face communication or whatever agile technique or method you like to have – it’s easy to organize yourself and make changes!

It’s a bit ironic how often I hear agile minded team members (sometimes myself even) say that they need the project manager to change before they can go agile. You need a manager to get self-organized, is it so?

You are the system. You cannot change it all by yourself. But sure is, you can be the first to say NO!

If you first get friends with the one that stops you from doing whatever agile thing you like to do, by inviting him or her to lunch and show some interest and respect for his passions, then the NO will for sure be much easier to turn into a YES – we will change our little world, our little system to a little better place to be in.

Thx to friends at Agila Sverige conference for making me think.