Ways of communicating, how we learn

Hi :)

I’m back.

While going through one of my presentations I found this slide with such  important information that I want to go through it again and above all share it with you.

It’s not something new, but I’ll just write it down here, even for my own sake.. for those days when I want this info and I can’t find it anywhere among the zillions of pages in the web.

This is about how we communicate with each other. In other words the so called Cone of Learning (or Cone of Experience).

There are some nice pics in the web, but because I don’t want to go over any copyrights, I just draw this one for us (I like to put it on the  wall for all our teams to see it and

maybe reflect on it) . You can also use it as you please (within the limits of decency ;>)

cone of learning

And this my friends is why we use things like the 3’cs when writing user stories or specification by example when analysing and defining stories.
In my very own opinion that’s why Scrum Masters should always try to coach people rather than just focusing on doing the Scrum Master stuff. We should aim to teach people to do stuff than just do it ourselves.  Doing is the best way to lean and keep knowledge in our big and wise human brains.

So there you go. Lesson to all of us. We should spend our time DOING meaningful things ( as in things that matter to you, things you are passionate about) . It’s the only way we can actually make that little dent everyone talks about.

If you want to know more about it: here , here and lots of images here.

Have a nice day,

Cátia

8 thoughts on “Ways of communicating, how we learn

  1. First off, I must say that the snowfall theme made the article to read. At first, I thought that I was have a visual disturbance due to some health issue.

    The phrase “Scrum Masters should always try to coach people rather than just focusing on doing the Scrum [M]aster stuff” was something that jumped out of me. I assume that “Scrum [M]aster stuff” is referring to facilitating meetings, updating burn up/down charts, and other administrative type tasks. That is an incorrect understanding of the Scrum Master’s service to the Product Owner, Development Team, and Organization. S/he should first be a mentor/coach and followed by the “Scrum [M]aster stuff.”

Leave a comment