Activities to Explore Waste in Software Development


#1

How do you explore waste in software development with your team?

Currently I’m running a couple of workshops to explore the 7 wastes of software development (plus a bonus):

  • Partially Done Work
  • Extra Features
  • Relearning
  • Handoffs
  • Delays
  • Task Switching
  • Defects
  • Untapped Creativity.

I had some exercises that worked quite well. I can see improvements. I’ll note them below. I would love to hear your own.


Solution engineer: How to avoid rework and waste
#2

The waste of partially done work
The purpose of this is to show how maximised work in progress (and taken to the extreme) can really limit progress. Full credit to Karthik Nagarajan for inspiring this exercise. I simplified as I was just looking at a single aspect (the waste of not limiting WIP and having too much work in progress).

I set up two Kanban boards. One on either side of the room. Each had only 3 columns: To Do, Progress, and Done.

The team then created cards necessary to construct a rocket from this diagram.
rktparts

One card for each part. I didn’t focus on the biggest value as I was concentrating on the effect of partial work.

So now the game and this was thanks to Karthik’s idea. I had a coin. One volunteer/victim stood at both boards. One given the instruction, “Maximise the work in progress, if something becomes blocked pick up something new”. The other was told to “maximise” throughput and wherever possible get work done. The other instruction to person number 2 was that they had a WIP limit of 3.

The rules of operation were thus. I flip a coin. If it is heads you may either pull a story to the next column or unblock a story. I flip a tails a story in the progress columns would be “blocked” until they could unblock it with a heads toss.

I flipped the coin about 30 times, so some work was moved across the board. At this point I stopped and had the teams look at the two boards. You can see the results below.

The improvements would be ensure that I provide a prioritized list, but not a major improvement. Also the person at board one, was a dyed in the wool agilist, so he almost couldn’t comprehend not having WIP. I had to repeat the rules multiple times. I would probably choose someone with less experience. It was a fun exercise though and worked quite well.

More to follow… Interested in feedback on how to improve.


#3

Love the rocket game!

Plenty of exercises that show how context / task switching “make you dumb”

Here are two:

  1. http://www.andycleff.com/2015/06/the-cost-of-context-switching/
  2. https://www.crisp.se/gratis-material-och-guider/multitasking-name-game

#4

I hadn’t seen those. Cool. I was going to go with a simple race or 2 races.
2 people, 3 columns: Letter, Number, Roman Numeral.

Person One writes left to right, line by line until they reach X
Person Two writes column by column and we see who wins.

To take the speed of writing, will swap it and go again. It is quick, simple and demonstrates the effect.


#5

Waste #2 The waste of extra features.
The plane game
I’ll admit, I like getting adults making paper planes as it is always fun and engineers are right up there on the scale.

The Set Up
Two people are given a few sheets of paper. The rules are spelled out to both:

  • Minimum number of folds to make the paper plane
  • Each prototype needs to be approved before testing and release
  • The next prototype can add more complexity if needed
  • The plane will be considered flight ready when it can fly at least the length of the table (about 2.5 meters).
  • The front of the plane must have a nose cone (pointy bit)

Round 1
Both teams will make a plane (5 folds). I accept one plane as ready to test, but the other, I state that it needs to have a more pointy nose. “Let’s do another sprint”.

Round 2
The tested plane doesn’t reach the end of the table, so they add 2 more folds to the prototype. As does the second team. I accept one plane (the one that was previously tested), but reject the second as it really needs a tail.

On testing the first team with the accepted plane meets the spec and is accepted as done

Round 3
Reject it with the need for fins on the wings

Round 4
Reject it with it needing skids (feet) to land on. At this point I provided some masking tape.

Round 5
Reject it as it “looks plain” (no pun, not intended) and get them to add them.

Round 6
I relent and let them test it. The plane flies straight into the table

Pulling it back to the point at hand. We look at the differences. The “features” really didn’t add value and there was also a cost in time as we went through a lot of work before even reaching a test phase.

The exercise ran quite well.

From an improvement perspective, I would consider getting team 1 to continue “producing planes” with minor improvements aimed at experimentation and maximizing flight time. So that way we can also see the additional waste of not being able to iterate whilst the “features” were in development for team 2.

All in all a good exercise


#6

Waste #3 The waste of relearning
One of the team was joining the workshop remotely. To extend the participation. I sent the image below to them prior to the session.

At the start of the exercise, I asked them to pick 2 team members. Those team members were given 2 pieces of paper. The remote team member was asked to describe the image and the 2 local team members were asked to draw the image based of the description alone.

I was trying to simulate what happens when you have less than perfect information as such might exist when you have a person holding all the knowledge.

We repeated the exercise with another image displayed to all, but I limited the time to about half the time we had previously.

We then looked at the results together. The link was made that even with constraints of less time, when knowledge was shared, a much better result could be achieved.

The resultant drawings can be seen here.

The exercise seemed to land home. The only way I’d tweak this is by getting everyone at that table to have a go at the drawing. It was a fun exercise.


#7

#empathy


#8

A wonderful execercuse Brad. Love how you were able to make it distributed team-focused!

Have you Seen the empathy toy?

Similar underlying concepts around communication shared meaning time box constraints.

And similar concept that I shared in our retro thread


#9

I saw the Collaborate and Nobody Dies retro, but the empathy toy is completely new to me. That looks great.

Lol. It feels like, by the time I get through just compiling the 7 exercises in a single post, I will have written a chapter of a book. How funny. I’m learning every bit as much and probably more than most of my team.

“The more you know, the more you know you don’t know.” - Aristotle


#10

Heck, might be an entire book!


#11

Lol. Let’s call it “Agile games for any learning occasion” it has a nice ring to it.


#12

I’ve used a 2-page excerpt of the 7 Wastes as a retrospective topic. My typical format is to ask each team member to identify which 1 or 2 wastes resonate with them the most. On finding commonality, we then explore how we can minimize those wastes. Even for the wastes that aren’t the top priority, the exercise starts to highlight the concept.

The wastes also provide a good framework for root cause analysis or 5-Whys - though I also caution about overly using them as crutch or short-cut.