The lean conference of the year – Stop Starting 2014

Stop Starting Start Finishing . Lean Kanban Nordic 2014

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:

read more »

Learning flow with the Lean Dot Game

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.

Result board from a round of the Lean Dot Game

Result board from a round of 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:

  • Why it’s better to slow down
  • Adapt to bottlenecks
  • Batch sizes
  • Little’s law illustrated
  • Waste and inventory
  • Customer collaboration
  • In process testing
  • And more, and more, and more…

read more »

Why you are better off using a developer than a lawyer when purchasing software

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?

  • Lack of provider skill
  • Lack of customer maturity
  • Lack of ability to utilize late learning
  • A one time shot to get any IT updates in my environment
  • I win, you loose approach – no shared economic incentive
  • Lack of communication, during execution

read more »

Spotify Engineering Culture (part 1)

Here’s a short animated video describing Spotify’s engineering culture (also posted on Spotify’s blog).

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 to be mostly true for most squads most of the time :o)

Part 2 hasn’t been recorded yet. Stay tuned.

Crisp consensus model 2.1

Our consensus signs, by Jimmy Janlén

Our consensus and meeting signs, by Jimmy Janlén

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.

read more »

Det går nu att anmäla sig till TDD-eventet!

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.

Lean UX & Agil UX – modern användbarhetsmetodik

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:

  • Lean UX, där vi ser till att bygga rätt produkt genom kontinuerlig validering mot affärsmålen av det vi bygger just nu och starkt fokus på att lösa användarnas problem
  • Agil UX, där vi ser till att bygga produkten på rätt sätt genom kontinuerligt samarbete runt det vi bygger just nu och fokus på leveransmålen

Venn-diagram över UX, Lean UX och Agil UX read more »