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:
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.
Community comments
Bottleneck?
by Jim Standley /
Re: Bottleneck?
by Amr Elssamadisy /
Synchronicity
by Kevin Rutherford /
Re: Synchronicity
by Amr Elssamadisy /
Learning is hidden and underrated.
by cleve gibbon /
Re: Learning is hidden and underrated.
by Amr Elssamadisy /
See also...
by Matt Savage /
To be an agile development org or not to be...
by Remember Objective /
Re: To be an agile development org or not to be...
by Deborah (Hartmann) Preuss /
Re: To be an agile development org or not to be...
by Greg Helton /
Feedback from Agile 07 Lightning Talk
by Amr Elssamadisy /
Re: Feedback from Agile 07 Lightning Talk
by David Chia /
Implication is not bidirectional
by Cliff McCollum /
Re: Implication is not bidirectional
by Amr Elssamadisy /
Bottleneck?
by Jim Standley /
Your message is awaiting moderation. Thank you for participating in the discussion.
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 /
Your message is awaiting moderation. Thank you for participating in the discussion.
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 /
Your message is awaiting moderation. Thank you for participating in the discussion.
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 /
Your message is awaiting moderation. Thank you for participating in the discussion.
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...)
Learning is hidden and underrated.
by cleve gibbon /
Your message is awaiting moderation. Thank you for participating in the discussion.
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 /
Your message is awaiting moderation. Thank you for participating in the discussion.
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 /
Your message is awaiting moderation. Thank you for participating in the discussion.
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 /
Your message is awaiting moderation. Thank you for participating in the discussion.
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) Preuss /
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks for the colourful illustrations, Mr or Ms "Objective" !
Re: To be an agile development org or not to be...
by Greg Helton /
Your message is awaiting moderation. Thank you for participating in the discussion.
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 /
Your message is awaiting moderation. Thank you for participating in the discussion.
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 /
Your message is awaiting moderation. Thank you for participating in the discussion.
While I agree with most everything in the article, and enjoyed the ideas it presents, it contains some very poor logic:
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 /
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree that implication is not bidirectional - let me clarify:
Re: Feedback from Agile 07 Lightning Talk
by David Chia /
Your message is awaiting moderation. Thank you for participating in the discussion.
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.