BT

Failure to Learn Stifles Productivity

| by Amr Elssamadisy Follow 0 Followers on Aug 14, 2007. Estimated reading time: 1 minute |
Amr Elssamadisy and Deborah Hartmann have written an article, The Secret Sauce of Highly Productive Software Development,  asking us to consider that there may be one common attribute to all software development projects that, if focused upon and improved, can make productivity soar.  In fact, they implied that many of our most successful teams are already leveraging this common attribute today.

They claimed that the attribute is a team’s ability to learn and learn quickly.  Learn about what?  Everything, each other, the technology, the domain, the customer, etc.  A team that learns quickly succeeds faster.

They start off asking us to consider this hypothetical situation:

Suppose I was your client and I asked you and your team to build a software system for me. Your team proceeds to build the software system.  It takes you a full year – 12 months – to deliver working, tested software.

I then thank the team and take the software and throw it out.  I then ask you and your team to rebuild the system.  You have the same team.  The same requirements.  The same tools and software.  Basically – nothing has changed – it is exactly the same environment.

How long will it take you and your team to rebuild the system again?

When they presented this hypothetical situation to their students – many of them with 20+ years experience in building software – they typically respond with anywhere between 20% to 70% of the time.  That is, rebuilding a system that originally takes one year to build takes only 2.5 to 8.5 months to build.

Are teams truly harnessing this power of "lessons learned" in all their practices?

The full article presents a thought-provoking point of view to software development in general and Agile software development in particular. 

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Bottleneck? by Jim Standley

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?

Synchronicity by Kevin Rutherford

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.

Re: Bottleneck? by Amr Elssamadisy

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.

Re: Synchronicity by Amr Elssamadisy

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...)

Very interesting article by Alexandre Poitras

Just wanted to point out that this article was very informative and I totally agree about learning being an hidden "bottleneck" which is most of the time ignored in traditionnal methodologies. It's seem so clear once explained to you.

By the way, I really enjoy the quality of the articles on InfoQ. Continue the good work, it's really appreciated to see a site dedicated to quality content rather than publishing the latest "Framework XYZ has been released".

Learning is hidden and underrated. by cleve gibbon

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?

See also... by Matt Savage

Pat Kua's series on onboarding new team members:

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

Re: Learning is hidden and underrated. by Amr Elssamadisy

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.

To be an agile development org or not to be... by Remember Objective

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.

Re: To be an agile development org or not to be... by Deborah Hartmann

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

Re: To be an agile development org or not to be... by Alexandre Poitras

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.


Totally agree and yet you are only discussing technical learning. Domain learning (distillation as Erik Evans called it in his book) is at *least* as important as technical learning.

Re: To be an agile development org or not to be... by Greg Helton

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?

Feedback from Agile 07 Lightning Talk by Amr Elssamadisy

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

Implication is not bidirectional by Cliff McCollum

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.


If learning accounts for 25%-80% of a projects time, I agree that spending time on things other than learning may have decreased value.

However, this does NOT imply the converse, as your quote seems to indicate. There can still be numerous things that will increase productivity that have nothing to do with learning. Nothing in this article, or its evidence, supports the idea that all productivity increases come from learning.

Re: Implication is not bidirectional by Amr Elssamadisy

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?

Re: Feedback from Agile 07 Lightning Talk by David Chia

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

16 Discuss
BT