Failure to Learn Stifles Productivity

I'd rather think it is just what we DO most of our time. Whatever you call it, the "learning lense" does look like a valuable view.

And this view will show us interesting things about the cost of change and the value of Big * Up Front?

The claim that learning is the bottleneck, in the TOC sense, is fascinating - and will have many of us scurrying away to draw CRTs to check it! Your article also dovetails neatly with a number of others that have appeared in the last few days - see my mini carnival-of-blame for a survey that ties them together into a story.

I'm glad you agree that the "learning lense" idea is valuable. The 'bottleneck', in TOC terms, is counter-intuitive. In fact, the idea that there *is* a common bottleneck even more uncomfortable.

But, I cannot think of one single thing that can make any team get such a gain. As awkward as that may feel and sound, it points to the fact that it *is* the bottleneck.

I have shared my thoughts here to test that bold assertion with the community.

Thanks Kevin! Please share your thoughts on the bottleneck idea. I would be equally happy to have holes blown in the theory as to have agreement/validation. (Well, I would prefer validation to be completely honest, but...)

I really enjoyed reading this article because we are currently embracing agile practices and a lot of what you mention we have and are encountering with respect to learning.

I found that great teams are full of people who want to learn and on learning new thingthrive s. Agile is a great way to build this into everyday project life.

On the article I found that teams that skip retrospectives suffer badly. I think it is one the most important parts of the learning process. Also, migrating the "whole" team thinking over to TDD is challenging but very important from the feedback cycle perspective. These two have stood out key contributors to addressing the learning bottleneck.

I'm interested to know if you have any similar experiences with the practices you mention in your article?

Pat Kua's series on onboarding new team members:

www.thekua.com/atwork/category/onboarding-strat...

Thanks Cleave!

Check out the book on Patterns of Agile Practice Adoption: The Technical Cluster (www.infoq.com/minibooks/agile-patterns) - it is focused on adoption, which necessarily includes learning.

that is the question.

The end result of not learning is fragmented, transient non-organization of temporary specialist workers, who never talk to one another about actual business-related problems or technical creation because they have nothing relevant to say to one another.

That's pretending you don't have a development organization.

Nobody has "enough time". They only have time to keep going in their specialist microcosm. "Learning"? What are you talking about--don't you have enough to do? A new language? What for? I am not in pain even though I'm still compiling and "building" web apps...

Ruby? Ruby on Rails? I've never heard of them before this conversation. He was serious.

Learning is always "playing" and only in spare time, which there is none of. Why would a person have spare time if they were essential to the organization? To the non-organization...?

What customer in their right mind is going to pay for me learning something, unless I'm a certified learner of some kind with a demonstrated track record of getting an ROI from learning? Why not just hire someone who already knows? How does the customer know that the developer is willing to jump in? Easier said than done...

I have 600 fields to display in a form. I do it the hard way and charge the customer for that, and they think they're getting a hard worker. I pass this pile of code on to the next developer, who declares it a unmaintainable pile of rubbish, but it sure must've been a lot of work, yeah.

The next developer invests some learning time, finds a way to do it much easier with less effort. It's a total rewrite. What do we tell the customer?

But then, that developer has moved on to AJAX and wants to rewrite it again...because they have since learned that it could be done much simpler. Server-side is just boring now...no matter what the language.

Thanks for the colourful illustrations, Mr or Ms "Objective" !

Why teams don't grow? In the case of the agile team I was on, it is because my project lead at the time thinks that every domain object should be responsible for its own persistence. And lots of similar reasons. Is there ANY overlap between Agile and good design?

So, I was at Agile 07 this week and attempted to give a lightning talk (5 min max) about this idea. I suggested the hypothetical example in the article and asked the attendees for responses.

For the very first time in all the groups I have asked, several people seriously said that the second time around will take significantly more time to build. People don't really speed up until the 3rd time around. There were some that had (almost) built the same thing twice also (conferences are great!)

Hmm.... What does this mean? Does this mean that the hypothesis of learning being the bottleneck is wrong? Or that we, as human beings, need several times 'around the block' to learn correctly?

I'll try to encourage some of the attendees of that session to comment on this thread.

Amr

While I agree with most everything in the article, and enjoyed the ideas it presents, it contains some very poor logic:

It means that any efforts we spend on anything other than learning will provide only limited productivity gains. Conversely, it means that anything that does improve our productivity has somehow improved our rate of learning.

I agree that implication is not bidirectional - let me clarify:

While I agree with most everything in the article, and enjoyed the ideas it presents, it contains some very poor logic.
<\blockquote>

If and only if (iff) learning is the bottleneck, then all productivity gains must come through improving that bottleneck. (The article is a hypothesis and not a proof or evidence of an experiment.)

The assertion made in TOC is that any improvement in throughput can only be through improving the bottleneck.

So, let's make this easy, all it takes to disprove a hypothesis is one counter-example - could you oblige me with one?

It could mean that the projects that they were talking about just took that long to do.

The classic example is giving birth. It's not going to be much faster than 9 months, that's just the nature of it. The mother that has given birth already cannot use her knowledge to have a second child in, say, 4 months. In fact, the second pregnancy might prove even more difficult because of any number of external factors. Even though the mother gained knowledge from the first pregnancy, it wasn't applicable the second time around.

Is learning the bottleneck? Great question. Maybe it's only half the problem. As the GI Joe cartoons of my youth used to point out, "Knowing is half the battle." Perhaps the other half is doing, being able to use the knowledge you've gained. If you can't use it, was it that useful?

Also, what do we decide to learn? Are we learning the correct things? Let's use a driving example. Let's say I've got a manual transmission car and I'm learning how to go from A to B. I've determined that being able to shift optimally can shorten the time by 10%. That's great, but not when compared to a shortcut through an alley that could've saved me 80% of the time.