Stop starting, start finishing

10 11 2012

I feel like I’m ignoring my blog…

If anyone would care, I’m busy finishing programme set up of the conference ”Stop Starting – Start Finishing” (Lean Kanban Nordic) which will be held in Stockholm March 12-13 2013. Together with this great team – Håkan Forss (Avega), Anders Eklund (Frontit), Hermanni Hyytiälä (Reaktor Innovations) and Ketil Jensen (Leverage51) and the professional conference team at DF Kompetens.

At the moment Call for sessions is open a couple of weeks more. Don’t miss the opportunity to have a conversation with an audience of managers and others curious for next step in project , portfolio and change management.

Submit your proposal at sssf13.uservoice.com  or visit the Swedish submission info page at dfkompetens.se

Welcome!

How do you finish stuff in stead of starting more?

Annonser




Go see your managers day

2 06 2012

A follow up thought on my previous post on to show some empathy and put yourself in management shoes, to understand what she really cares about and what’s important for her.

A bold and probably a very insightful way of understanding your manager and how to speak with her, is to apply Genba – Go See principle – the other way around. Go See where the action is. Ask your manager if you can come for a ”study visit” 1 or 2 days, to follow her for 2 days as an apprentice just to understand what she’s facing every day and to understand business better.

Not that hard really?

If someone asks you if they can follow you for 1-2 days to learn about your way of working, your delighters and problems, with the purpose of being able to help you in a better way, would you be happy for that question? I would for sure. And I think your manager would too.

The effect I’ve already seen many times – The Go See principle is powerful whenever applied.

Go See your mangers day





Improvement is development

17 03 2012

At my job there is always something to be improved.

As soon as we have achieved something, a price, a delivery, a new customer, whatever, there is always something better.

This could be mistaken for critics. We just achieved this, why do you need something more and better? Sometimes me and my agile fellows probably could be seen for never being content.

And that’s maybe just what development is about? Always always get better at something.

Have you ever met a system developer content with his product? Proud maybe, yes, sometimes, but content?  No. ”It’s poor quality behind the surface”, ”It’s poor usability”, It’s bad code, It’s not what we COULD do if only..

Maybe system developers and people who has been developers, will always be developing. Never stopping. Never content with the product or service. Maybe we need these people to – develop?

To relentlessly improve is to develop business.





Complexity and Feature injection at Agile Lean Europe 2011 Berlin

17 09 2011

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





Using Agile retrospectives as a tool for organizational change

9 02 2011

Att stanna upp och reflektera i organiserad workshop-form ökar vår produktivitet markant. Jag har själv sett det fungera – när tillbakablickarna fungerar bra vill säga. Det är lätt att det blir mycket snack och liten verkstad. Med intresse och lite tips och hjälp från olika håll kan vi alla bli fantastiska workshop-ledare är jag övertygad om – och genomföra mirakel.

Därför har Frontit, Agical och Crisp bjudit in Esther Derby & Diana Larsen att komma till Stockholm mellan 14-16 mars för att hålla både introduktionsseminarier på temat ”Hur kan vi genomföra organisationsförändringar med hjälp av agila retrospektiv” – och en 1-dagars-kurs för den som redan provat på retrospektiv och vill komma vidare.

Läs mer i inbjudan. http://www.projektstyrning.se/files/agile_retrospectives.pdf

Sprid gärna vidare om du gillar förbättringar 🙂

Hoppas vi ses!





Slöseri med resurser att specificera innan utveckling

8 08 2010

En för många agilister gammal princip att beskriva, men den tål att upprepas gång på gång.

Varför är det slöseri med resurser att skriva kravspecifikationer för tidigt?

En jämförelse. Jag vill att du renoverar mitt badrum. Renoveringen ska starta i maj nästa år, då du är klar med ett annat jobb du gör åt mig, renovering av mitt fritidshus. Därför börjar jag skriva specifikationen nu, med så många detaljer jag kan komma på. Badrummet ska ha svart golvkakel som jag sett hos Badrumsexperten till ett bra pris. Badkaret ska vara inbyggt av jacuzzimodell. Väggarna ska vara av vitt mosaik-kakel som jag sett och en vägg ska flyttas ut 1,10 meter. Handuksvärmare av modell värmi  mm.

Jag lägger en hel del tid på att hitta allt detta kakelmodeller och badkarsmodeller, spenderar mycket tid hos olika butiker och har redan börjat välja ut handdukar. Vad är problemet med det här?

Det här är ett väldigt enkelt och litet exempel där konsekvenserna inte blir förödande stora om jag kastat bort tiden, men faktum är att det räcker med att

1. Jobbet i fritidshuset tar (naturligtvis) längre tid än planerat, så badrumsrenoveringen kan inte börja i maj, och jag vill ju jobba med samma hantverkare, eftersom vi jobbat upp ett förtroende. Jag måste också säkerställa budgeten för fritidshusrenoveringen innan jag kan börja badrummet. Så den ursprungliga planen är trasig innan vi börjat.

2. När jobbet i badrummet väl kan starta i augusti nästa år visar det sig att det svarta golvkaklet inte alls går att få tag på i Sverige längre då det gått ur mode. Endast importerat från Italien kan beställas till en kostnad av 10 000 kr/kvm i stället för 1000 kr/kvm som planerat. Det är alltså inte längre aktuellt med det här och jag vill byta till vitt golvkakel. Då passar inte längre det vita väggkaklet jag tänkt från början och jag får tänka om, och hitta en ny färg och nya mått som passar med det nya golvkaklet.

3. Eftersom fridishusrenoveringen (naturligtvis) blev dyrare än planerat, måste jag överge tanken på inbyggt jacuzzibadkar och jag får ge mig ut och hitta ett passande stående vanligt badkar. Ut i butikerna igen..

4. När vi ska flytta väggen visar det sig att just den storleken jag tänkt inte fungerar med eldragningar gjorda i huset och en gammal skorstenssockel så måtten får planeras om och den lista jag gjort på golvyta och väggyta får skrivas om.

Någon som känner igen sig? Kanske av renoveringsbekymren? Men knappast inte av den specificerande delen, för VEM skulle skriva en detaljspec 8 månader i förväg av en renovering som ska göras kanske nästa år?? Däremot är det säkert många förnuftiga hemrenoverare därute som 8 månader i förväg börjar fundera på KONCEPTET, bläddrar i badrumstidningar, letar inspiration, gör sporadiska besök i butiker, skissar på papper gör en grovplanering och väntar tills JUST-in-time för att göra en riktig budget och planera det riktiga materialet och väggflyttarna.

Varför undrar jag, motarbetas denna princip så ofta i systemutvecklingsvärlden? Varför envisas så många med att fortfarande skriva detaljspecar på funktioner som KANSKE ska byggas, kanske har budget och kanske är aktuella om ett år, som är helt beroende av implementation av funktioner vi bygger just nu och vi än inte har sett resultatet av?

Min teori är – gammal vana, så har väldigt många (inte alla – inte Google, inte iPhone, inte alla dagens framgångssagor..) gjort de senaste 50 åren. Det går att ändra sig. Men stora förändringar är som alltid förknippad med stor ångest.

Prova att fundera på hur du agerar i andra utvecklings/renoverings/trädgårdsplanerings-, design- och eller förändringssituationer  och där finns många enkla svar på hur utvecklingsprojekt kan komma i mål med betydligt mindre resursslöseri.





Kursmaterial till seminariet på Avega

27 05 2010

Vi hade en givande övning där deltagarna skrev user scenarios på att få del av kursmaterial. Fantastiskt roliga idéer och tankar som utmanar hur vi föredragshållare och stackars arrangörer jobbar med vårt material egentligen. Jocke, dela gärna med dig av ditt nuvarande scenario här.. 🙂

Jag lovade iaf att lägga materialet utanför min lokala disk och på bloggen, så nu finns det på Dropbox och länkat härifrån under rubriken Kursmaterial och presentationer

Lycka till med systemen, processerna och människorna.