Message to myself

I received a magic letter few days back. It was a letter I sent to myself 6 months ago - in retrospect to SoCraTes2012

I publish the letter today, at the first day of our little SoCraTes copy - Aulanko Open Space.

"
Dear Me!

Being 2 days at Socrates 2012 I've learned

• that I really don't know how to test-drive
• that there's a bunch of professional craftsmen who are passionate to write quality software
• that people are more important than processes/schedule/invited spakers
• that [for me] the poeople, i.e. community, is by far more important than big names!

"

On leadership

I was asked to be a guest lecturer (one of three or four) on a Software Project Management course at Aalto university. In particular, the topic of the day is 'managing people' and I shall talk about my experiences as ScrumMaster.

The first thing that came into my mind was Tobias Mayers' great blog post 'Delete [ScrumMasters]', which did resonate quite extensively with my thoughts. I do believe being one of the rare individuals, though. And that's what I'll talk about.

Note: Carlton Nettleton describes what ScrumMaster is in this blog. He questions whether there even exists one person to fulfill all the roles.

I know I have a lot to learn to fully be qualified as SM on Nettleton standards - specifically since I've experienced this. Was it good/bad - I don't make such conclusions. And I'm not going to talk about that either - what which are the challenges and my road on fulfilling the role.

Instead, I'll be talking about leadership. What does it mean to be on a role where I have no what-so-ever thoughts of my own.

I'll talk about what leadership means to me.

And I'll talk about what it means for me to experience the day-to-day problems on group dynamics, communication and team work.

And I'll talk about the joy being on such a position brings.

And I'll talk about the learning we experienced as a team.


It's a talk filled with joy.

That is, I'm going to talk what does it mean, to me, to be a hiking guide. ScrumMaster - hiking guide. So different that they are the same.

Friday morning, this week. Aalto university - somewhere.

On Learning

Some time ago, just few days before I started my new job at Ambientia, I was talking at JCN 2012 conference in Helsinki about BDD. The title of the talk was 'Introducing BDD'.

Finally I realized something I hadn't thought of before, at least to this extent. That is, the topic of learning.

While hiking, it is especially important to stop and reflect where we are - trying to locate ourselves on the map.
A group of hikers learning the basics of orienteering.

Learning has been on top of my mind lately. Partly because of the supervision studies, in which I learn a great deal about myself, partly because of me lecturing/guiding/facilitating at the university of Turku and partly because, I just love to learn. Or like my little princess puts it 'Daddy, may I learn that?'

A little quiz for a start. What is one common factor in TDD, BDD, ET, Sprint Demo, Sprint Retro in agile teams? Given the topic of 'Learning', it might be self-evident. Yes, we tend to learn while performing those practices. That was simple - and for me the more interesting question is, how do I feel that TDD and ET are the same? What is the characteristic that makes me think they correlate?

Where do we learn? (The following excerpts have a lot of conceptual ambiquity, please bear with me. I'll get to the point soon!)

• TDD - one part where we learn is when we turn a failing test into a passing one, we learn - in reflection - that the system did something as expected
• BDD - if we're lucky the process we're working with has many feedback loops incorporated into it. We learn - in reflection - whether we're building a feature fulfilling a business need.
• ET - We learn - in reflection - things about our system, how it behaves and how the system could be used and improved.
• Demo - We learn - in reflection - whether implemented features are what the business/customer needs
• Retro - We learn - in reflection - as a group. Of our behavior, of our team. Of us.

That is, the common idea in all aforementioned practices is that we take our time for reflection. We reflect on what happened (observations), how it made us feel (feelings), what we think of it (ideas), what are our hopes regarding it (hope) and what we'll do about it (action).

Often I go through all these phases so fast, that I don't even notice they are different phases. And I'm working on that.

I see that happening even when I'm test-driving my code. I often run really small experiments - fail in it - turn back and try another route. And while reverting my changes, I reflect on what happened. And I learn when exploring the system while working on it. Taking steps I hadn't though of. And when I see something strange, I stop to wonder.

In my talk, I did not describe a process of BDD. I had a story of one learning organisation.

And THAT makes me wonder.

If learning happens in reflection - what could I do to help me learn more efficiently? And more importantly - what do I need to learn to make a whole organisation learn?