Amplify (Individual) Learning

#learning #lean

As I (finally) started reading Lean Software Development from Mary and Tom Poppendieck [1], yesterday I was reflecting on the literal meaning of the second principle: Amplify Learning.

Totally unrelatedly, some days ago a discussion at work had started around making sure we keep learning and encourage everyone in the company to do so. As knowledge workers, learning is indeed a critical part of the career management of all of us.

So reading this "amplify learning" clicked to me, and this got me thinking that in current team, I believe we are not really good at making sure that when people learn things (an useful API, a nice way of solving a recurring problem, or something new that could prove interesting to the bigger team) when working on a Story, this is then systematically shared to the rest of the team.

For instance during a Friday lightning talks session, or something similar.

Is Unshared Learning Waste?

swarf

The first Lean Software Development principle is Eliminate Waste. Oh wait, I thought, that’s interesting.

I started scribbling a schema with my 5-year-old capabilities to represent the indirect "result" that individual learnings are lost if unshared. Basically, if we are looking for an analogy, these "lost/unoptimized learnings" could be seen as a by-product, or worse as swarf. [2]

optimize learnings

Condensing boiler

I thought about the condensing boiler I have in my house. Roughly, this type of boiler collects back the heat of the burnt gas by condensing it to water and reinject it in the circuit. [3]

This allows that type of boiler to have a better efficiency. In other words, for the same amount of gas, that kind of boiler will produce more heat.

You see where I’m going right?

Share learnings in the Definition of Done

So I guess it is now clear I posit that not sharing learnings with the full team in a systematic manner is a lost opportunity :-).

Obviously, the analogy could be seen as falling short on the aspect that the learnings are not lost for the developer who went through it?

Well, I am inclined to think that this still would be very suboptimal. I believe we all have realized too often how trying to explain something to someone else was revealing how shallow our understanding actually was.

Hence agreeing as a team that for each Story, a lightning talk [4] will for example be delivered sounds like a good way to make sure the knowledge will be forced to be structured, understood deeply and magnified for the benefit of the whole team. [5]

Recap

In my experience, doing this kind of sharing on a voluntary basis, during brown bag lunches for example, has always stopped more or less quickly. The pressure and the day-to-day life we all go through generally tends to come back naturally after some time and make this habit fade out progressively.

By making it part of the team’s definition of done, it sounds like we could amplify individual learnings to the full team (and more! [6]).

For instance, I would imagine something like a 30-minutes session on Friday mornings after the team standup. Each presentation would be maximum 5 minutes, presented by people who completed Stories since the previous Friday.

What do you think?

Note
If you tried something like this, or this is a practice still even in place in your team, I am very interested to hear your thoughts! Do you like it, what did or did not work? Etc.

2. Thanks a lot Owen and James :-)
3. Note however that IANAP: I Am Not A Plumber ;-)
4. or a blog entry, or both!
5. On top on helping teammates grow their public speaking skills.
6. recording could even have an impact company-wide, though it might add an unnecessary pressure to people
comments powered by Disqus