Tag Archives: flow

A Decade of Agile, A – F

Posted on by

A decade of agile boils down to theses simple fundamentals and steps for me.

A.
Ask: do you need to improve as an organization?
Only go forward if your sincere answer is yes.
Ask everyone: Do you want to improve? Same procedure.
Make sure you will fail (and win) regularly by commitment (plan/hypotheses) and checkpoints.

B.
Work with just a few things at a time.
Work with small things.
There are NO exceptions to this. This is a LAW.

C.
Build quality in. No exceptions here either. Also a LAW.

D.
Focus on customer value
This is optional, but you might be out of business quickly.

E.
There are multiple ways to achieve this. You are probably stupid if you do not test Scrum, since it’s a great litmus test if you actually get A – D as an organization.

F.
And yes. There are people too.

Let the User Story Flow

Posted on by

One of my biggest surprises when I first met the squads I where going to work with at Spotify was that none of them were using User Stories. At first I observed to see their alternative. Unfortunately there was none. Instead most of the work got done as big chunks of work (what I would tend to call Epics) that was sliced into a todo-list of tasks (named that way by the developers) and also divided according different platforms.

Squad focus on technical tasks

A typical board contained one or more business cases and lanes for each developer/platform with tasks that were executed upon. These big “busses” where on the board blocking other works for weeks, which of course meant there needed to exist one or more emergency lanes for all expedite work (in the long run, most work).

This is a setup that does not foster collaboration, focus on value and art-of-the-possible. From an agile fluence point of view I would say it is a way of working that does not even reach fluence level 1 (Christian and I will describe agile fluence in more depth in a follow up blog post). From my experience focusing on User Stories is a great way of fostering the above values, and reach fluence level 1.

read more »

Learning flow with the Lean Dot Game

Posted on by

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 »

Agile game – Pass the pennies

Posted on by


Timing: 10-15 mins

Ingredients:

  • 20 Pennies (any kind)
  • 4 departments (1 worker per dep. sitting at table)
  • 4 dep. managers with stopwatch
  • 1 CEO  (with stopwatch)

Directions:

Game has three turns – each with different batch size [20, 5 and 1].

Workers job is to flip the pennies he receives as fast as he can and then pass them on to next. Department managers job is to take time his worker spends from the first to the last coin flipped. CEO takes total time from the first coin to the last. 

For fun, let managers have a "one-on-one" chat with his worker after each round.

Display results on a flipchart:

 
20 coin batch 5 coin batch 1 coin batch
Department 1 10s 17s 12s
Department 2 12s  
Department 3      
Department 4      
Total .. .. ..

Learning Points:

  • When batchsize decreases, total cycle time decreases
  • As total time decreases, worker time increases!
  • People idle more when batch size is high

CREDIT: Agile Coachcamp members