Archive for August, 2014

For me it seemed that at #ALE14, failing was one of the themes.

When I noticed that many people said: yes talking about failing is easy when it’s only a small failure, but what about a real big failure?
That’s the moment I decided to have a lightning talk about the moment I burned down my parents house in 1991.


The people that know me, know, I have been talking very openly about this event for years. I even did a talk at a few agile conferences called: what I learned from burning down my parents house.

Yet at #ALE14 talking about it (almost unprepared) on stage and feeling the reactions, made me very emotional.
Thank you. I’m still get tears in my eyes when I think about the support I felt from the audience .

As a thank you, I want to talk some more about failures.
About some of my failures during #ALE14. I learned from the fire that failing is OK. And although I learned that from a big event, I want to use the small failures I made at ALE14 to talk about how I deal with failures now.

It started with my proposal for ALE14.
I made 3 proposals for ALE14. They all needed more work. Work I did not do: FAILURE I

I don’t know exactly why it happened, yet I also did not follow up on these proposals: FAILURE II

I also got feedback on one of them, feedback I did not understand. I asked a question. And did not follow up on that either. > FAILURE III

As a result my sessions got rejected. (One session got resurrected during my holiday, I guess I was lucky)

Last year I did sponsor ALE13 to promote the idea of PairCoaching. This year I forgot to contact the organizers FAILURE IV
On top they decided not to contact the old sponsors, and when I found out, I left it like that (FAILURE V)

I knew already for a very long time I wanted to go to ALE in 2014, yet I only booked my plane like in the last week FAILURE VI

At the first edition of ALE, I shared a room with Chris Matts and that was a wonderful experience. So ever since I decided to do this again when I can, only know I completely forgot with who I would share a room this year FAILURE VII

After a day or so and a few embarrassing tweets where I had to acknowledge this, I finally realised I found the person thanks to a message on linkedin and I found back I did that with Sergey (For me FAILURE VIII as I should have realised this earlier)

I thought I had the address of our apartment noted in my agenda, turns out that was of the venue FAILURE IX

The address I did found back while being outside the hotel, was not complete and did not work with google maps FAILURE X

In the end I never paid Sergey (FAILURE XI)

And while writing this blogpost, I realised I still did not mail Sergey to fix this FAILURE XII

Also with Sergey we hardly talked when we came at the apartment so my apartment sharing did not get the results as before . that is because we did not really exchange expectations FAILURE XIII

When I arrived in Krakow I was extremely tired and most of the first day, I felt I was in zombie mode FAILURE XIV

At the last day, when I did my 30 second pitch for my talk, I asked people to think about a bad habit, and then I asked them to share it with a neighbour. That was bad. I should have said: if you feel comfortable, it would be nice if you can share it with someone else in the room, that you trust. Asking people to share a bad habit with a random stranger, is good for some people, yet others prefer it do it with someone they know. Thank you Paul Klipp for calling me out on this. > Failure XV

I have not posted the blog post about the ALE14 books yet as I promised. >> FAILURE XVI
And the biggest of it all: I did not call my children on the first 2 days while I was at ALE14. >> FAILURE XVII
I can continue for a while like this, and I already know what the default reaction of a lot of people will be: Yves these are not all your fault. Some of them could be blamed on -FILL IN THE PERSON YOU WANT TO BLAME-

I don’t play that game. I prefer to blame myself. Not because I’m on the SHAME stage of the responsibility model.
I do that because if I look at a situation from a point of view that I failed, I can also see what action I can take to avoid this in the future.
And that is the game I’m playing.

This is why I like to say: “blame it on me”, some people think it’s a joke. It’s not. I like to be blamed. Especially when the critic is concrete. That means I can look at the situation, see my part in it and turn it around.

So, where did you fail lately?

Working together with a person and a team, goes much better when trust is higher.
The agile manifesto says it prefers teams that are physically together .

And for a long time I was convinced that for creating a great team, you had to put the people together. Yet gradually I saw (and worked with) great teams that were not physically together.

It took me a while to realise that what was really needed was trust. And yes the easiest and most know way to build trust, is being physically together all the time.

So let me be very clear, I am in no way advocating to be less physically together.

Yet in this global world, sometimes the best people to work with (best in every possible way) are living in another continent. And then, we have to look at different ways to create trust.

I that sense agile teams can learn a lot from open source teams. Most open source teams work in a distributed way. From what I understand, some (even among the best OS teams) have never met.

The last years I created a few community projects, while not all have been huge successes , I think it’s fair to say that most collaborations worked well and in some we even had huge trust.

 

The strange part (for me) is that I don’t consider all these collaborations work of a team. That is, for some projects, people never really work together, they all work independently. For me that is one of the necessary aspects of distributed work: split the work in small independent pieces.

 

In all cases there was high trust in the core team. And for me, I considered my main task in building trust between me and the core team members.

Would that work be easier when people are in the same room?

Yes.

And haven’t you met the full core team personally yourself?
In most cases yes. yet not always.

The details of the how will be for another post, yet my core aspect in it, is I start by trusting them by default. If I consider I want to work with someone, I need to trust them. And I ask them what they want to do.

But Yves what if they are not trust worthy ? Well their work will tell me.

Yes I had people who promised me a lot, and delivered nothing (or close to nothing). Yet that was clear very fast. And the more a person delivered, the bigger the trust that build in the team.
What about arguments?

Well people who I have never met, will indeed faster think that discussions means lack of trust. For me it’s even the opposite. People I don’t trust, I don’t even argue with them. I stop working with them. There are smarter ways then discussion and arguments, yet every team needs techniques to deal with multiple opinions.

 

These days we have a lot of technical tools that help to enhance communication.

It’s important to realise that we also have trust building tools like:

 

Once you know how to create a team using trust, you can think about distribution or scaling. If you haven’t figured out to build a team with trust, colocation will only help partially…