Crisp's BlogPage 31

(sorry, this article is in Swedish, because it is a response to a Swedish article. I won’t make this a habit.)

I en artikel i Computer Sweden den 3 feb står det ”siffror visar att nio av tio Scrumprojekt misslyckas”. Men de angivna siffrorna handlar i själva verket om något helt annat – att 9 av 10 personer som säger att de kör Scrum inte implementerar Scrum fullt ut. Detta säger ingenting om huruvida själva projektet lyckades eller inte (eftersom Scrum inte är ett självandamål). Denna typ av sensationsjournalistik gynnar ingen – utom möjligen tidningen som vill öka sina tittarsiffror, men på bekostnad av trovärdighet.

Låt oss därför titta på lite mer relevanta siffror istället….

These are checklists I have compiled to help my Kanban teams stay focused

"Anytime" Iteration planning Daily standup

Download as pdf

Last week I attended the Problem Solving Leadership class held by Jerry Weinberg, Johanna Rothman and Esther Derby.
It was a week full of exercises and simulations and I consumed more knowledge during one week than I usually do for months. 
And I am still digesting it.  This is a early debrief of what I think I have learnt.

I recently got  a valid question from a collegue and it deserves an answer.
"When do I use Scrum and when do I use Lean?"

Lean predicts that work happens in a certain order. Scrum has a "chaos" approach where work can be done in best possible way, dictated by the situation.

Therefore Scrum works better than Lean in environments with rapid change, on the edge of chaos where the same solution rarely work twice.

Kanban pracitioner or a Scrum team thinking of adopting it?, don’t miss out on the "Future of Agile" conference 27:th of May.

An unique opportunity to learn from practitioners and experts about experiences and best practices for Kanban and Lean in our "Bring your kanban board" session. Joining us is David Anderson – father of Kanban.

Future of Agile, May 27, Stockholm

När du förstått poängen med testdriven utveckling kommer givetvis krånglet. Så hur tar man sig vidare?

Vi börjar med poängen så att vi är överens om vad vi menar.

Testdriven utveckling (TDD) säger att man först skriver ett test som fallerar (viktigt), sedan implementerar man så att det inte längre fallerer.

I det läget tar man sig en funderare om man tycker att designen och kodstrukturen är enklast möjliga. Om inte så fixar man till den, utan att ändra vad koden gör, refactor på engelska. Eftersom de tester man har, går igenom så är det tryggt att ändra implementationen.

Vi fortsätter sedan med ett nytt varv, test – implementation – refactor.

Enkelt så långt, men vad är poängen?

A Russian translation of my book Scrum and XP from the Trenches is now available. Thanks Aleksey Solntsev for initiating this project, and thanks to all of the 17 people who contributed (listed on the first page in the book). French, Spanish, Japanese, Chinese, and Portuguese translations are also available. Korean, German, Italian, and Slovak

Aleksey Shevchenko have on developer.com published 10 commandments for Java Developers, and they are of such lousy quality that I just have to respond (this vaguely resembles a xkcd cartoon :-). His commandments are: Add comments to your code Do not complicate things Keep in Mind – "Less is more" is not always better No

I dessa agila tider sker allt mer utvecklingsarbete vid tangentbordet, men är det verkligen bra? Ställ er vid tavlan och rita pilar och bubblor innan ni knackar kod! Fast man kan inte göra som vi gjorde förr, BDUF är fortfarande dött.

I today got these sent from my collegue Hans Brattberg. It it an essentional vocabulary for the Agile practitioner 🙂

* BLAMESTORMING.
Sitting round in a group, discussing why a deadline was missed or a project failed, and who was responsible

* SEAGULL MANAGER.
A manager who flies in, makes a lot of noise, craps on everything, and then leaves

Hur många av er har inte läst om misslyckade projekt, som blivit mycket dyrare än planerat? Jag har svalt detta sätt att resonera, skakat på huvudet, och tänkt "Jaja, vilka kretiner". Men nyss pekade min kollega Mattias Skarin på ett mailinlägg av Roy Morien på en mailinglista med namnet scrumdevelopment (hur hinner han läsa allt?)

1-2 days every week I schedule “slack” days, where I try to catch up on emails, do some admin, prepare for future engagements, and such. During the past year I’ve been using the Pomodoro technique more and more consistently and, the more I use it, the more I find that it really works well! It

Hur höjer man kvaliteten på koden i ett projekt?
Här min topplista på vad man kan/bör göra.

En fördel med denna kris är att vi IT-folk, så fort någon sneglar i vår riktning, kan slå ut teatraliskt med händerna och säga "Nonononono, titta inte på oss – vi är oskyldiga". Dock kan den svida nog så illa, speciellt om man är konsult. Så, hur djup blir krisen för oss? Enligt den ansedda

Alistair has kindly published a summary of ideas and practices around Agile contracting,
Areas covered, Fixed time, Fixed Scope and some new ideas.

But remember, in any contract honour the Principle of fair exchange (by Verna Allee):

"Do not enter a contract where you would not wan’t to participate as either side as signing party."

5 months have now passed since we introduced Kanban and Agile to two teams. Here is a half way report:

Good stuff

• Trust has grown significantly, to developers and to managers
• The work they put in is now visible and appriciated in the organisation
• "We now have visibility and can affect our situation" / team member
• Both have taken significant steps from specialized individuals to teams. This is seen in frequent cooperation and problem solving.
• Knowledge sharing has intensified dramaitically
• Managers can instantly spot problems by walking through the department looking at the kanban boards
• 2 months after introduction, one team was voted "best in company" that sprint. It was also acknowledged as second highest "good" thing in company retrospective same period

Challenges remaining:

• It is hard to find clear team goals (there are no sprints)
• Knowledge sharing puts pressure on senior members, it is important to give something back, making their work fun
• A constant struggle fixing root causes outside team limits
• Teams evolves so rapidly it is hard for organisation to keep up!

The positive problem of the month
I was called in to one teams retro…

"we think we have a problem.."
"uhm.. (holding my breath) . tell me"
"well in our retro, we have too few problems…"

I’d love to see more of this 🙂

Några kollegor på Crisp gav tipset att titta på videon från David Andersons presentation Future Directions for Agile från Agile 2008 Conference. Väldigt väldigt intressant, och emellanåt ganska provocerande, så det kan inte bli speciellt mycket bättre. Real Options Theory var ett intressant nytt område som jag skulle vilja läsa mer om (närbesläktat med Lean),

När jag började lära mig Scala så stötte jag direkt på Actors, ett koncept snott från (om jag förstått det hela korrekt) Erlang. Actors är ett sätt att få till concurrency genom att skicka meddelanden, till skillnad från det vi alla under ett decennium svettats med i Java, trådbaserad concurrency. Tanken är att det ska

Cory Doctorow (som bland annat är känd som intressant SF författare) har sammanfattat varför han inte tror att metadata (dvs data om data) kommer att lyckas i Putting the torch to seven straw-men of the meta-utopia. Kort och kärnfull spark i skrevet på de som tycker den semantiska webben är intressant. Ouch!

Anne Thomas Manes förklarade den 5:e januari SOA som dött, och ett flertal personer har inspekterat liket och godkänt dödsprotokollet. Själv är jag inte bland de närmast sörjande, och sörjer inte heller. Good riddance, som det heter. Tvingade mig själv för ett par år sedan att läsa en hel bok i ämnet för att försöka

I currently coach a system administration team. Anyone who has worked in one knows the constant attention required and the difficulty to find  uninterrupted time. (phone ringing constantly..) 

Doing kanban, we do iteration plannings every week and they need to be fast and accurate and we only need to keep a 45 min window. We have experimented with different approaches, and this has been the best working.

This is not you, right?

• Customer making changes at a faster rate then the development teams can implement
• A development team running short sprint lengths only to deliver crap to QA
• A development team promising features at a quicker rate than we can make avaliable to end customers – only to build up a queue of unshipped work
• A management team changing directions in a faster pace then company can absorb them,
• A software development company entering an Agile contract with a waterfall process

We apply agile principles to be fast and responsive to changes. Lean teaches us to "deferr decisions", agile to "change late". But doing this and turning a blind eye to real limitations we  fool ourselves to believe we can drive faster than we are able. Result? Quick steering adjustments aimed for a sports car brings the truck into inbalance and possible into the ditch.

running this?	..or this?

Alex Miller har haft den intressantaste bloggen för de som intresserat sig för Java 7, och han har en speciell sida där han summerat all information han kommit över. Java har känts lite övergivet på Sun, tycker jag. Det har inte funnits någon kapten på skeppet. Gosling gör lite som han vill, men driver inget

I often hear from Scrum teams they don’t understand why estimating in story points are better than estimating in ideal man days. Here comes three reasons …

I’m half time on paternity leave so this blog entry will have a touch of my life at home with my 1-year-old son Oliver.

Even though they can’t speak, those young citizens have a lot of power since their screaming can make a father do anything they want and do it now. Similarities to eager product owners are not too far away 😉

I torsdags fick jag chansen att hålla en presentation av det som ligger mig varmt om hjärtat; de största hindren för att uppnå effektivt team samarbete.

Slidsen från presentationen har ni här.

Min presentation byggde mycket på Patrick Lencionis bok och arbete kring "The five dysfunctions of a team". Jag har under min karriär själv konstaterat att ofta så är det största hindret för framgång bristen på bra samarbete i ett företag i synnerhet i utvecklingsteamet självt. I Patricks arbete har jag upptäckt många bra idéer och verktyg för att skapa bra samarbete i nästan vilket team som helst.

Jag har nu också fått chansen att pröva att omsätta dessa idéer i praktiken och se att de faktiskt fungerar. Redan innan jag hade upptäckt Patricks bok, hade jag på olika sätt jobbat på ett mer informellt sätt jobbat med att uppnå effektivare samarbete i de utvecklingsteam jag jobbat i, men Patricks mer strukturerade angreppsätt är betydligt snabbare och mer effektivt, speciellt genom att alla i teamet blir medvetna om vilka hindren är och vad man kan göra åt dem.

Nedan följer en textversion min presentation som jag höll den på javaforum. Jag lyckades spela in den på video också, och kanske jag orkar klippa ihop den med slidens och lägga ut den här på bloggen framöver, vi får se.

Kurs i The Five Dysfunctions

Jag kommer den 4 februari genomföra en kurs i ”The five dysfunctions of a team” med syfte att i detalj gå igenom de fem dysfunktionerna samt verktygen och övningarna för att bearbeta dem.

För de som inte orkar vänta tills dess, kommer jag också genomföra ett morgonseminarium på Crisp lokaler på Sveavägen 31, den 16 december kl 9-10, där denna presentation, utökad till en del, kommer ges.

För att anmäla dig till seminariet eller kursen maila academy@crisp.se

Continue reading

A French translation of my book Scrum and XP from the Trenches is now available. Big thanks to Guillaume Mathias, Bruno Orsier, Emmanuel Etasse, and Christophe Bunn. Spanish, Japanese, Chinese, and Portuguese translations are also available. Korean, German, and Slovak translations are underway. I never cease to be impressed by the agile community! All translations

A Portuguese translation of my book Scrum and XP from the Trenches is now up on the Brazilian InfoQ site. Big thanks to Renato Willi for initiating and coordinating this effort, and thanks to all the other 30 contributors as well who made this happen (listed at the end of the book)! Spanish, Japanese, and

Min gode kollega Hans Brattberg ställde denna provocerande fråga:

Vad i Lean hindrar oss från att göra en kejda av
Req Spec -> Architecture -> Design -> Program -> Test -> Production

Med handovers hela vägen?
Utan kommunikation?
Utan Cross Functional?
Utan Feedback?

Cycle time helps us monitor our system performance. So cycle time is a good  thing 🙂

But there is two ways of tracking it. First (obvious) way is by starting a stopwatch when an item enters system and stopping it when it exits. This gives a reliable measurement but only after we have passed the process.

But there is a better way!