The importance of failure (and of praising effort not intelligence)

Neon sign reads: People fail forward to success by Ian Kim on Unsplash
Photo by Ian Kim on Unsplash

I’m finally learning Russian (again)

I am currently learning Russian and reminding myself of the integral importance that failure has in the learning process.

I visited the USSR in 1988 as part of a modern studies high school trip to Moscow and Leningrad (now St Petersburg). You can see the photos from my trip on Flickr.

In late 1987 I started a short course to learn some Russian phrases. I didn’t get much further than Что это (what is it?) and это стол и стул (it’s a table and chair) before I gave up. Still, at least learning the Cyrillic alphabet helped me read signs as we travelled around this other-worldly country that was then still behind the Iron Curtain.

Since then, however, I have always wanted to complete the course and learn Russian for nothing other than the academic satisfaction. Plus, obviously, if Russia is to continue to interfere in national politics and influence elections it would be useful to be able to communicate with our eventual overlords in their own tongue.

Thirty years on and I still haven’t learned the language. Which is why, last week I decided that now was the right time. I realised that there would never be a perfect time. I would never have a free six months to devote to the task. If I wanted to do it then I would just have to start now and squeeze it into my daily schedule—five minutes here, ten minutes there.

Why did I give up so easily?

But why did I give up so soon after starting to learn?

There are likely to be a few practical reasons, not least energy levels, volume of school work, and family dynamics (my dad was suffering from brain damage by that point).

Surely, it can’t all have come down to time or motivation. Back in 1987/1988 I had all the time in the world—besides school I had few other commitments. And I had the motivation—I would be visiting Russia during the Easter break in April 1988.

But I still gave up. Why? This puzzled me for a long time, until I found the answer in a couple of books about parenting.

I think the problem was that for as long as I remember I had been told that I was clever, and learning Russian is hard—I gave up, I reckon, because it challenged my self-perception as a clever boy.

This isn’t as daft an idea as it sounds.

The importance of praising effort

In Professor Richard Wiseman’s book 59 seconds: think a little, change a lot (Macmillan, 2009) he explains why “telling a child that they are bright and talented is a terrible thing to do” (p.281).

During the late 1990s a couple of psychologists (Claudia Mueller and Carol Dweck) from Columbia University, New York ran a series of experiments with children, during which one group of children were praised for being clever while the other group was praised for the effort they put in (regardless of whether they got the answers right or wrong).

What they discovered was that children who were told they were really bright after completing one set of tasks were then less likely to exert themselves when presented with a choice of further tasks. While the children who had been praised for the effort they put in during the first task were far more likely to opt for a more difficult second task.

Telling a child they are intelligent might make them feel good, but [it] can also induce a fear of failure, causing the child to avoid challenging situations because they might look bad if they are not successful. In addition, telling a child they are intelligent suggests they do not need to work hard to perform well. Because of this, children may be less motivated to make the required effort and be more likely to fail.

Professor Richard Wiseman, ibid, p.283

Po Bronson and Ashley Merryman go into more depth about this research in their book Nurture shock: Why everything we think about raising our children is wrong (Ebury Press, 2009).

It turns out that children who are frequently praised tend to become more competitive and more interested in belittling others. Their primary interest becomes image-maintenance—having been told they are clever, they want to continue to be seen to be clever even if that means pulling others down around them.

Looking back at my childhood and teenage years, I don’t recognise that last aspect of tearing others down but I wholeheartedly recognise the image-maintenance part—I would joke years later that I simply dropped those subjects that I didn’t do well in, not realising at the time that I did this because they clashed with the self-image that I had been developing and which was being built-up by folks telling me that I was clever.

I liked being clever. I didn’t like doing things that didn’t make me feel clever. It makes perfect sense. But I wonder what I missed in giving up things too soon. I wonder what would have happened if instead I had been praised for my effort and dug in deep at times.

How can students succeed if they are not taught to fail?

While I was working as the warden in a university halls of residence, I would frequently have conversations with students about the importance of failure.

Here we had, arguably, some of the brightest young people in the country who had progressed from success to success to become, in many cases, the brightest in their school. And then when they arrived at St Andrews among other similar youngsters they found themselves to be decidedly average.

That took them quite by surprise. And coupled with a different style of learning at university and an increased workload many found themselves not hitting their usual 100% expectations.

To many it felt like the sky was falling in: their world was collapsing and their self-image was being shaken at a fundamental level.

In my first year at St Andrews, I would tell them, I failed two-thirds of my course. Two-thirds! I passed divinity but failed Old Testament and ecclesiastical history; I managed to progress to second year by the skin of my teeth. But that experience changed me—it helped me to understand how I work best. It helped me to understand what works for me, and what doesn’t. In the end, I graduated with a 2:1 honours degree that I was delighted with.

It is okay to fail

This paragraph from an article on @TeacherToolkit that I read last year resonated with me:

In recent years there seems to be an accepted fallacy that learning happens in a linear fashion, with educators setting up opportunities for children to jump from success to success without ever encountering failure. However, if this is the case, to what extent are your pupils simply working as opposed to learning?

Teacher Toolkit

They suggest incorporating failure in the learning process. This is their list of suggestions:

  • Provide the children with the toolkit to cope with failure.
  • Praise the children’s best efforts and show them how to move their learning forward.
  • Develop an ethos where the children are not afraid to fail and develop strategies to overcome challenge.
  • Don’t hide mistakes from children. Adults make mistakes all the time, but children seldom are afforded the opportunity of witnessing this.
  • Make teaching points of your mistakes and model how to deal appropriately with failure.
  • Pupils should have the confidence to attempt new activities in a safe and secure environment knowing that failure will be met with encouragement and support. Failure isn’t something to be feared, but rather is part of the learning process which should be embraced.
  • Children need to know that it is okay to fail and it is the trying again that is important, this is how children succeed.

But it’s not just children and university students who need to learn the importance of failure. For the last few years I was working as an agile project manger in a web development team—”fail fast” is something we used to advertise as one of the benefits of working in an agile manner.

I’m delighted to see Karl Scotland (from whose writings I have learned a lot over the years) is running a session at this week’s Lean Agile Scotland event in Edinburgh entitled “Failure is not an option”.

That’s right, failure is not an option—it is a necessity.

For many organisations, failure is something to be avoided. Poor results are frowned upon; people don’t take risks, and they hide undesirable results for fear of being blamed. But it’s these failures that generate new information from which we can learn, and this learning is what leads to organisational improvement and long-term success. This session will explore why failure is not an option, but a necessity, and how we can make failure a friend and not a foe. Karl Scotland  “Don’t bury your failures. Let them inspire you.”

Lean Agile Scotland

Let your failures inspire you

I really like that quotation: don’t bury your failures, let them inspire you.

There is something here to inspire me as I try to remember what этот (this), он (he), она (she) and оно (it) mean in Russian; as I try to encourage Joshua to do his French horn practice—”you’re trying really hard to play the right notes, well done” rather than “you’re so good at that”; and as I reflect on my last twenty years of work and try to make sense of what my strengths are, what weaknesses I need to work on and where I should put my energy next.

Lean Agile Edinburgh meetup at Royal London, March 2018

You can watch the recording of the live stream above.

  • 14:33 Introductions
  • 18:45 Welcome from Royal London (hosts)
  • 23:50 Kathy Thomson—Explain and explore
  • 42:00 Krish Bissonauth—CIA model
  • 1:24:00 Greg Urquhart—What does Agile even mean now?

Last night I took the train down to Edinburgh for my second Lean Agile Edinburgh meetup.

Started in June 2013, Lean Agile Edinburgh is an informal and social monthly meetup to discuss and share all things agile, lean, kanban, scrum, etc. At most meetups we have talks, workshops/activities or Lean-Coffee discussion sessions.

Yesterday’s meetup was kindly hosted by Royal London at their new offices at Haymarket Yards in Edinburgh, a short hop, skip and a jump from the railway station. Last month’s was hosted at the other end of Princes Street, in the Amazon Development Centre Scotland offices at Waverley Gate.

The evening began with an opportunity to network and chat with folks over pizza and refreshments, before we took our seats for three excellent presentations.

Explain and explore

The first session was a very hands-on, get out of your seats and move about exercise lead by Kathy Thomson, a scrum master at Royal London.

We were each given a postcard and pencil and invited to answer the following question in either a word or short phrase: “What does agile transformation mean for you?”

I wrote something like, “Iterative change that is collaborated on by a team towards a shared goal”.

With our postcards completed we were invited to stand in a large open space to the near the presentation area, and turning to the person next to us explain our answers.

Next we were invited to exchange our cards with someone else, and then someone else, and so on until we had effectively shuffled the cards. I ended up on in the middle of the room. This was the ‘explore‘ part of the exercise.

And then again we were to pair up with the person next to us and explain to them the card we were holding. Which, obviously, was now not our own card. Interestingly, I felt less defensive about explaining this card. And I appreciated seeing someone else’s perspective on the same question.

Somehow, I ended up with two cards for this one! And I can’t remember either of them.

And then we were off around the room again, quickly exchanging cards, and pairing up to explain our new cards to one another. Mine simply said, “Pace”.

It was a really interesting and useful exercise, even with a room of about 60 people.

Control Influence Accept model

Returning to our seats, Krish Bissonauth, an Agile coach at Royal London, introduced us to the Control Influence Accept model (or CIA model).

This is a versatile problem-solving and stress-management tool that identifies three ways to respond to challenges:

  • Control—identify the elements of the situation over which you have control.
  • Influence—identify the elements over which you have no control but which you can influence.
  • Accept—identify the elements over which you have neither control nor acceptance, which you will simply need to accept and adapt to.

I loved the Clarke Ching quote he finished with. It spoke about social comparison—why do your Facebook friends’ holidays and kids look so much better than your own? It’s simple: their lives are just like ours but they only share the good stuff. So it is with books we read and presentations we experience about Agile and DevOps: we see the good stuff and we feel bad.

His message: stop comparing yourself to the “Facebook” versions of Agile and DevOps, and start comparing yourself with how you were doing three weeks ago, three months ago, three years ago, and feel proud of the all the hard work you are doing and the progress you have made.

What does Agile even mean now?

The final talk was by former Skyscanner product delivery director, and current Agile 4-12 consultant Greg Urquhart.

There was much in Greg’s talk that resonated with me, but it was what he called his “cut the Agile bullshit-o-meter” slide that I found most helpful. He had set himself the task of limiting his definition of what agile is to just five bullet points. This is what he came up with:

  1. A culture of experimentation constantly generates validated learning.
  2. Teams have missions, mastery and the autonomy to act with no strings attached.
  3. Software is frequently delivered to users. We learn its value through serious use.
  4. Teams and resources align beautifully to strategic objectives at all times.
  5. Minimum viable bureaucracy.

If you’re not doing these five things, he argued, then you’re not agile.

Towards the end of his talk he advocated for what he called scientific engineering (learning work) and argued that this more than lean and agile (knowledge work) would bring about the most effective and productive change.

This aligns with another talk I attended recently in Perth at the Scottish Programme and Project Management Group conference, where one of the speakers encouraged all the project managers and business analysts in the room to start to get familiar with big data and data analysis. It’s what the most valuable companies in the world are doing—Apple, Google, Amazon, Facebook. They are using data (massive amounts of data) to design and refine their products.

I walked away from last night’s meetup feeling encouraged and more animated. It has certainly given me a lot to consider, a couple more tools under my belt, and a little more clarity about the direction I want to take my career.

Thanks Lean Agile Edinburgh.

The boys ‘helping’ me with my studies

Boys on the desk
Reuben, Joshua and Isaac ‘helping’ me with my studies

 

For the next few days I’m on a course at work looking at DSDM Atern agile project management. It’s certified, so I have exams on Wednesday morning (foundation) and Thursday afternoon (practitioner).

When I got home last night, after dinner, I decided to sneak upstairs and get about 45 minutes of study in before the boys had to go to bed.

It turns out Reuben, Joshua, Isaac and monkey had different ideas and came to ‘help’ me study.

Agile planning poker

For a few months we’ve been starting to use Agile, and specifically Scrum, methods in planning and managing our Web projects at work.

This week we adopted a new practice: planning poker.

Agile / Scrum iteration planning board
Agile / Scrum iteration planning board

Like many teams starting out with Agile practices we didn’t just jump in feet first and adopt every Agile method going; that would have been too much to take in. So we began with a few methods:

The photograph above, taken a couple of months ago, shows the planning board in our office — an information radiator — that shows us at a glance how many tasks are left to do, what’s currently being worked on, what’s in testing, what’s done and (unlike, I would guess, most other Agile boards) what we’re waiting for.

Multiple projects

By definition Agile really should be used by teams working on one project at a time. It’s simply not efficient working on more than one because as soon as you start switching between different projects you lose time. One reason is that it takes time to get back up to speed with project B after working on project A.

However, some of us have no option but to work on more than one project at a time, as well as juggle support emails, telephone calls and the like. In which case you simply have to adapt the principles of Agile to accommodate more than one project, and essentially run them all in tandem as though you were working on multiple threads of a single project.

Karl Scotland, formerly Development Team Leader with BBC Interactive wrote a really useful paper back in 2002 entitled “Agile planning with a multi-customer, multi-project, multi-discipline team” (DOC, 225 KB) in which he explained how he ran things at the BBC where they would regularly work on three projects simultaneously.

We currently have 19 projects on the go at the moment. Which is far, far too many and we need to do something about it. So this week we revisited our project backlog and introduce a new Agile method to the mix: planning poker.

Planning poker

Planning poker cards
Planning poker cards

The idea behind planning poker is very simple: “planning poker is a consensus-based estimation technique for estimating, mostly used to estimate effort or relative size of tasks in software development” (Wikipedia).

Each member of the team had a pack of cards (I made our cards using Microsoft Publisher 2007 and a handful of skills) which have a sequence of numbers printed on them. They are quite often close to a Fibonacci sequence to reflect the uncertainty in estimating larger items. Our pack uses the sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, a ? (unsure) and a coffee cup (I need a break).

We then took each item in our project backlog and after an explanation of what was required we all took a vote on how difficult we thought it would be as a project, placing the cards down on the table at the same time so as not to influence another player’s estimation by laying your card earlier than them.

Once voted, unless the group has a consensus the person who laid the lowest-value card and the person who laid the highest-value card explains why they thought it was easier (they’ve done this before, for example) or harder (what did the others miss?).

Votes are taken again until a consensus has been reached and then the team passes to the next task or project on the list.

We found it a really useful exercise because it actively encourages everyone to speak and gives everyone an equal say in the decision-making processes associated with managing projects. We really quickly got to the core issues related to each project and at times an interesting spectrum of scores (13, 20, 40 and 100 for one project).

Planning poker cards (PDF)

Our conclusion

Our next stage is to complete the scoring on the remaining <cough> 60+ projects, and work with our boss to prioritise projects. That should give us an overall score (estimate x priority) which will enable us to more accurately plan when we should schedule these projects and in which order. For example, you don’t really want to be tackling three really taxing projects at once.

Oh, and it makes the task of planning much more fun.

If anyone wants a copy of the cards I made (in PDF format) drop me a note in the comments and I’ll upload them for you.

More resources

Luis Goncalves, co-author of the excellent book Getting value out of Agile Retrospectives has written a really useful article about planning poker:

Planning poker and scrum poker: everything you need to know

JavaScript doesn’t suck!

Interesting interview with Douglas Crockford (Senior JavaScript Architect at Yahoo!) on the SitePoint website entitled JavaScript doesn’t suck.

Having been reading up on Agile practices recently, I found this final piece of advice interesting:

… If you had fifteen minutes of attention from everyone who’s writing JavaScript in the world today, what one thing would you teach them to do better—or not do—with the language, to improve JavaScript on the Web?

The number one thing is, be aware that you can and must write good programs. One of the principal measures of the quality of a program is its legibility. We should be writing programs for other people to read. And I recommend code reading as a standard process of all development activities, so a team would do weekly code readings at the least, whether you take time out to read each other’s code … I think the benefits that come from that are tremendous.