from the Crisp Consultants
One of the most common questions we get is whether to estimate in time or points. It seems like points are used only “to avoid thinking about time” and they are essentially the same. Wrong.
Let us give you the travel metaphor to give you an idea about how we are thinking.
This years Lean Kanban Nordic conference will be something extra. The focus in on improving the full value chain, from concept to cash. You will get an unique opportunities to listen and discuss with practitioners sharing their experience of how they have improved their companies using Lean thinking. For example, learn:
Yesterday we had one of our regularly occurring so called Agile Lunch & Learn in the tribe at Spotify I currently work. We wanted to make the lunch about why it is often better not to work and focus on flow than to maximize your work and focus on resource efficiency. I searched for something in the Crisp bag of games. Pass the pennies – more about big batches. Kanban tothpicks – to many rounds and variables. Folding envelopes – again more batches. Eventually I found the Lean Dot game.
What a find! This game will be with me for a long time. The best flow game there is, with extremply simple props: post-it notes and colored dots. You can run it in an hour and get tons of experiences and stuff to discuss, such as:
The use of traditional contracts when purchasing software carry a flawed assumption – thinking the contract is the right mean to regulate risk.
The insight is key risks are : skill of the provider, the maturity of the client (yes you!) and ability to communicate honestly during the project. Few of these are effectively regulated using traditional contracts focusing on features, time and money.
Which are the key risks when purchasing software?
Here’s a short animated video describing Spotify’s engineering culture (also posted on Spotify’s blog). See also Part 2. This is a journey in progress, not a journey completed, and there’s a lot of variation from squad to squad. So the stuff in the video isn’t all true for all squads all the time, but it appears
Continue reading
At Crisp we try to use consensus when making important decisions. Why do we do that?
Crisp is a very flat company. Most of us have no boss and report to no one. Basically you can be part of Crisp in two ways: either you have your own firm and have a partner contract with Crisp (all consultants have this) or you are employed by Crisp (administrative personnel). Crisp is owned by most (but not all) of the members/partners. The owners have, however, renounced their right to run the company (from all but legal necessities). This means that the company is run by all partners and employees with an equal vote each. We no longer have a CEO and we elect our board. This means we have to have good ways of making decisions together. And consensus is a very good way of making decision in a flat group like ours.
Tidigare kollade jag om det fanns intresse att hälsa på hos oss på Crisp och utbyta erfarenheter kring TDD. Efter att ett flertal hade visat intresse har vi nu schemalagt eventet till den 6:e maj. Anmälan är öppen! Ni som visade intresse genom att kommentera det första blogginlägget ombedes att anmäla er via eventets sida.
Continue reading
Grunden i traditionell User Experience (UX, användarens upplevelse av en produkt) består av iterativa användarstudier och interaktionsdesign under krav- och designfaserna, för att säkerställa att produkten kommer att uppfylla användarnas behov och ha god användbarhet. Vi ser till att ta reda på vad vi ska bygga innan vi börjar bygga det. Det finns två huvudsakliga problem med det här (som båda beror på vattenfallsmetodikens inbyggda brister). Dels överlämnas resultatet av arbetet i krav- och designfaserna till utvecklarna i stora och svårförståeliga dokument, ofta bestående av flödesscheman och annoterade wireframes som inte speglar den tekniska verkligheten. Detta rent felaktiga sätt att bygga en produkt leder ofta till att man i slutändan bygger fel produkt. Dels sker oftast leveransen av produkten till slutanvändarna långt senare än det var tänkt och då har marknadsläget vanligtvis ändrats, vilket också innebär att fel produkt levereras.
Agila metoder löser problemet med att leverera produkten snabbt nog. Lean Startup (innovationsdriven produktutveckling) löser problemet med att marknadsläget ändras genom att fokusera på affärsmålen genom hela utvecklingscykeln. Inget av dessa paradigm är dock användarcentrerade. För att möta detta problem har två tankesätt utkristalliserats:
“Rörelse trumfar stillasittande” är den första och viktigaste av de sex principerna för lärande från Sharon Bowmans bok “Using Brain Science to Make Training Stick”. Att bli certifierad Training From the back of the Room lärare var en resa med många steg och moment. En av uppgifterna bestod av att göra en presentation. Jag valde
Continue reading
In the first week of March I attended two Spotify unconferences about Continuous Deliver and Quality (which I also had the pleasure to facilitate). I am amazed on how many we were (people had flown in from a lot of other places), the energy in the room, the quality of the discussions, and the massive
Continue reading
Already convinced? Sign up for ToDo by Projectplace! Want to know more? Read on.
Here are the slides for my Passion for Projects keynote Spotify – the unproject culture (+ failure story “How to burn €1 billion”).
So, now I’ve spent 2 days with 600 projects managers at a PMI conference. Totally different from the usual crowds I hang out with. Fascinating to hear stories about project management successes and failures in all kinds of industries – from warzone reconstruction projects to eurovision song contest.
Here comes the second article in the Kanban at Sandvik IT series on InfoQ. Based on the experience from Sandvik IT, I try to answer the question “How to engineer kanban systems to be sustainable and resilient despite the constant level of changes in today’s Enterprise?“. This article is somewhat more complex and deeper than
Continue reading
I have just got the amazing news that I am one of the 6 nominees for this year’s Brickell Key Award! I am really humbled by the fact that you guys out there voted for me. The Brickell Key Award has been awarded to people that I look up to in the Kanban community like,
Continue reading
I juni kommer min kollega Jimmy Janlén och jag hålla kurs i deltagardrivet och upplevelsebaserat lärande. Vill vi hjälpa andra att upptäcka och praktisera sätt att skapa sant engagerande och lärande undervisning, presentationer och workshops. Kanske slipper ni då mina egen långa resa bort från katedern.
Så vitt jag minns det var jag 24, kanske 25 år. Jag och min vän Göran hade blivit inbjudna att hålla föredrag inför en större samling människor. Det hade jag aldrig gjort förut. Visst var jag van att prata inför andra människor, från seminarierna på universitetet till redaktionsmötena på vår lilla tidsskrift, men inte att hålla tal. Jag gjorde det som kändes säkrast. Jag skrev ett tal och läste sedan upp det.
Förutom att det tog jättelång tid att skriva talet, så kändes det inte bra att stå där och läsa rakt upp och ner. Visst försökte jag läsa med inlevelse och dramatik, ungefär som när man läser högt för barnen, men det kändes ändå inte bra. Höll inte åhörarna på att somna? Lärde de sig alls något? Det går att trollbinda en publik med högläsning, om man berättar en riktigt bra historia. Göran var bra på det, men inte jag. Något behövde jag göra annorlunda.
Role Expectation Mapping is a series of workshop that explores, clarifies and establishes which expectations members of a group, team or project have on each other.
If you suspect that collaboration is undermined because of mismatch of expectations between people, then this exercise could boost the team’s ability to collaborate efficiently together. It is also a powerful way to jump start a new team and give them a structure to relate to.
People always have certain expectations on each other, behaviors, responsibilities, etc., but if those aren’t made clear and agreed upon among everyone – you are bound to have unconstructive conflicts, colliding agendas, difficulties in collaboration and things that fall between chairs.
Kanban is easy to set up, maintaining and improving is harder! When I visit a kanban team, I use these questions to check they know what they are doing. They are helpful since they are not tool focused, rather verifies that there is a tactic being used. After each question I add “please show it
Continue reading
Hur mycket testtäckning ska man ha? Vad är skillnaden på line coverage och branch coverage? Vad är komplex kod? Hur undviker man att få fejkade mätvärden (gaming)? Vad är “förtroende” i det här sammanhanget? Hur kan man kombinera flera mätvärden?
Det och lite till försöker jag svara på i den här videon.
Om det känns lockande att fördjupa sig inom olika varianter och vinklingar av TDD, säg till, så ordnar vi ett TDD-kvällsevent här på Crisp.
Every successful implementation of Lean or Agile I have seen has an ingredient that is almost a contradiction. A leader who has low ego (not interested in putting himself first) is present (he/she has active conversations with teams and other leaders such, as change never comes as a complete surprise) is active (he takes part
Continue reading
2010-2011 gjorde RPS en bra grej. De byggde ett system (Pust Java) som gjorde polisen mer effektiv. Poliserna fick datorer i sina bilar och kunde direkt registrera brott. Därmed behövde de inte åka in till stationen för att avrapportera lika ofta som med gamla systemet. Systemet var skräddarsytt för att ge hög användarnytta, och projektet blev en framgång. Pust Java blev finalist i CIO awards “project of the year 2011” och DN skrev en helsida “Polisen rapporterar betydligt snabbare med ny metod“. Systemet var inte perfekt, men en bra start. Poliserna sa att det var bättre än vad de hade innan, och folk var optimistiska inför systemets framtid.
Sedan hände något tragiskt. Istället för att vidareutveckla och kontinuerligt förbättra systemet, så valde ledningen att skapa ett nytt system från grunden (Pust Siebel) med undermålig teknik. Det blev ett fiasko. Ursinniga poliser klagade på att en avrapportering kunde ta flera timmar – “Pust Siebel gör en helt frustrerad och på gränsen till vansinnig!” – och saknade det gamla systemet. RPS hamnade i ett mediadrev. En poliskälla uppskattade samhällskostnaden till 10 miljarder kr!
Efter massiv kritik från både media, poliser, skyddsombudsmän och oberoende aktörer med insyn i projektet, beslutade RPS att lägga ner Pust Siebel. Nu är det allt fler som förespråkar att Pust Java återinförs
Varför spenderar en myndighet hundratals miljoner på att bygga något bra, för att sedan spendera ytterligare hundratals miljoner på att byta ut det mot något dåligt? Ännu värre: varför gör man detta trots att hela IT-avdelningen visste, och högljutt påpekade från början, att det nya systemet skulle bli sämre?
Syftet med denna artikel är att belysa och sprida lärdomarna, så andra företag och myndigheter slipper göra om liknande dyra misstag.
I have collected and distilled some of the basic patterns of Kanban-board patterns I’ve found on various boards. You can combine them in any way that suites you, but you probably don’t need all of them at the same time. Here’s how a sample pattern looks like: If you print the pdf to 9 pages per A3
Continue reading
I have finally found the time to write the story of Sandvik IT’s journey into Kanban-land. The articles is now available on InfoQ: Part I – How we got started Part II – What we learned This story has been told several times, with Johan Nordin (check our LKCE11 talk) or alone (check my LKCE13
Continue reading
Testdriven utveckling, TDD, är en vana och för att skaffa sig en vana, behöver man träna. I den här videon gör jag en rolig övning i att bryta ner ett tal i primtal. Jag vill också trycka på att du ska träna dig att använda utvecklingsmiljön genom att skriva koden “baklänges”, använd en variabel och
Continue reading
Sometimes it’s hard for a team to know if they get tighter and better as a team over time. This is a tool that allows a team to learn just that.
The barometer is executed as a survey in a workshop. The survey consists of 16 team characteristics, packaged as a deck of cards. Team members vote green, yellow or red for each card in the meeting (or before the meeting as an anonymous survey). Once all cards have been run through, the team reflects and discusses the results. You can, if you want to, run through the exercise in thirty minutes, but I recommend to set aside an hour.
In this episode of our YouTube channel Crisp Agile Academy I talk about Sprint Burndowns. I discuss the value of having one and that it is a tool for the team, not anyone else. I also give examples of different kind of burndowns: Remaining Hours, Remaining Story Points, Remaining Tasks, Things in progress, and Confidence level. I wrap up the episode with a little quiz.
http://www.youtube.com/watch?v=qoMZoppaf0U
I denna video berättar jag om vikten av att se till end-to-end ledtid och att den största förbättringspotentialen hos en organisation med Agila team ofta ligger i stegen innan utveckling påbörjas. (for english readers: In this video I tell about the importance of improving end-to-end lead time – not only think about the development portion
Continue reading
Jag läste en artikel om User Experience (användarens upplevelse av en produkt) häromdagen. En person hade kommenterat texten med den väldigt vanliga kommentaren om UX. Han sa att “allt vi behöver göra är att låtsas vara en användare och utvärdera vad vi har byggt ur den synvinkeln”. Detta håller jag tyvärr inte med om. Vi är alltför partiska som produktdesigners och utvecklare, vi känner till för mycket om hur produkten fungerar. Dessutom tillhör vi troligast inte den avsedda målgruppen, vi kommer inte att använda produkten i en faktisk situation för att lösa ett faktiskt behov, så det kommer bli mycket svårt för oss att låtsas tillräckligt.
Men vad vi kan göra är att luta oss tillbaka på forskningsresultat som kan appliceras på de allra flesta människor och därmed de flesta av våra användare. Dessa resultat kallas designprinciper och med deras hjälp kan vi lyfta vår produkt upp till en bättre nivå. Detta är det minsta du kan och bör göra för dina användare.Continue reading
Den andra delen handlar om TDD-processen. Se alla våra video på YouTube-kanalen Crisp Agile Academy.
Continue reading
Den första delen om TDD på svenska på Crisp Agile Academy är en motivering om varför det lönar sig med TDD. Jag funderar över vad som händer om man inte skriver tester alls, skriver dem efteråt eller skriver dem innan. Den här serien är tänkt att bestå av korta avsnitt där något inom TDD gås
Continue reading