A Learning Culture

I love conferences – I get to meet so many smart practitioners and come home bursting with new ideas. I’m back from Agile Development Practices and I learned a ton. One thing that’s on my mind both from the conference and other reading I’ve done this week is the importance of a culture that enables and even promotes learning.


It’s easy to forget that failure is good – if you can fail fast enough. That’s one reason agile works so well – short iterations and work transparency let us fail fast, and everyone knows when we fail. But failure shouldn’t only be seen as negative. We learn a lot more when we fail.


I recently read a great post titled “Are you building a learning suppression system by Daryl Kulak from his upcoming book. Here’s an excerpt.

What happens in organizations is that people get punished for committing sins of commission but they do not get punished for sins of omission. This shapes the mind of a person into saying “No, we better not try that,” attempting to avoid the nasty results of commission errors while ignoring the problems of omission errors, which don’t seem to cause as much havoc.

We don’t want to suppress innovation. Mistakes should be tolerated, not punished. We want a learning organization so our teams can always adapt to change, and thrive.

More on Learning from Linda Rising

Linda gave an enlightening talk Wednesday at ADP about retrospectives, and she talked a lot about having time for thinking and learning. These are my notes on her talk, so I hope I haven’t misinterpreted anything she said. You can find more material direct from her on her site.

When confronted with practices such as pair programming or retrospectives, some managers have this reaction: “We don’t have time for thinking”.

But we aren’t trying to stop, analyze the root cause of all of our problems, and fix them all. We need to do little experiments to see if they solve some problem we’re having. If the solution works, we don’t even have to know why, we can just use it. Linda compared this to tuning a musical instrument – we can make tiny changes, and these give us lots of value.

Linda quoted Tom DeMarco’s book, Slack. You can’t learn or change if you have no slack. Linda cited research showing that not being able to express feelings and thoughts in the normal course of business weighs us down, slows us down. It sounded a lot like technical debt to me! We fret about things that aren’t going well, and if we don’t get a chance to experiment with ways to improve them, we become less and less productive, more and more unhappy.

Going back to that idea that we must tolerate failure, it’s important that we don’t criticize or blame our teammates. Every team member should feel safe to raise issues and propose ideas. Linda cited Norm Kerth’s prime directive for retrospectives: We must believe that everyone did the best job he or she could, given what was known at the time. Everyone used their skills and abilities, the available resources, to their best advantage, given the situation at hand. When we start from there, we can avoid pointing fingers, and simply try to learn: what’s going well? What’s not going so well? How can we improve? What still puzzles us?

Linda advises us to watch for stereotypes: “These people are just no good at…” She was talking in the context of retrospectives, but this is good advice for everyday work. We even stereotype ourselves. We have to believe, instead, that we can get better. Then we will.

Focus on experiments. Identify the next experiment, and ask the three questions about it at the next retrospective. Share knowledge. Look for patterns.

Time to Learn

As Linda noted, everyone says they want to learn, but few take the time to do so. Take some time to learn something new today. See what you can do to promote a learning culture within your organization. Show your manager the Google 20% rule, and the value that Google has derived from that! Lots of companies, big and small, have something similar: Wiki Wednesdays, Engineering Sprints, one hour per day devoted to professional growth. People on agile teams love learning, and it makes us happy. When we’re happy, and when we are always learning and experimenting, we can do our best work. To me, that’s what agile is all about.

9 comments on “A Learning Culture

  1. Hi Linda,

    I work in a small company in Brazil called Bluesoft as a technicall leader and we just decided to give the all developers 4 hours a week to study and learn something. They have choosen their topics and I gonna have 2 meetings of 10 minutes with each of them every 15 days to see how they are going with their studies. So in January they are going to present what they achieve to all the team in a 45 minutes session and they are gonna write an article so we are gonna publish it at our blog. All of them seem to be very excited about it. I asked them to focus on how we can use whatever they are studing about to improve our work… So we can use it as a tool for the PDCA cycle too.

    Most of them decided to use books that we have in our library. The topics are:
    – Working Effectively with Legacy Code
    – Refactoring Databases
    – Google Web Tookit
    – Java Context Dependency Injection
    – Implementing Lean Software Development
    – Implementation Patterns
    – Clean Code

    I really think that we are gonna have a much mature team in the future by using this approach. What do you think Linda?

  2. I have the same questions! I was on a super team this summer, where everyone on the team gives back to the dev/agile community by contributing to open source projects, blogging, writing, presenting. It was heaven! But normally, though the people I work with are great at what they do, and always researching the latest technology and techniques that will help us do a better job, and improving process, most people don’t do a lot of ‘outside’ activities like blogging or contributing to open source. It puzzles me that our culture doesn’t seem to promote these things. So if you do come up with more answers, please share them!

Leave a Reply

Your email address will not be published. Required fields are marked *