f3yourmind

The ICC Champions Trophy is on the go in South Africa at the moment (… I’m talking about cricket).  Yes, the Proteas failed in a big tournament (again!) but the Poms will be touring here this summer.  As passionate as Saffers are about their national teams, we also seek revenge, but in a nice way;  I mean face-to-face revenge, not back-stabbing revenge

So with all this cricket frenzy going on, I caught an amazing interview with the captain of the Pakistan team, Younis Khan, on cricinfo.com.  For a person that lives in a country that is literally self-destructing, he views his purpose not just as a captain, but as citizen of a troubled country.  He views his influence on the team as lasting.  Like he says in the interview, when his time is up, he wants to leave with dignity and that which he leaves behind is more important than what he takes with him.

That is what I mean by Ubuntu coding.  It’s more about what you leave behind than what you take with you.  When you leave behind a code base that someone else will enjoy, then you are already more than 50% down the path of helping yourself.  If you left behind a mess, then you breed more messy developers.  I’ve stopped asking “What will I get out of this?”.  I think more about “What will you get out of this?”.  That subtle switch in perspective is enough to make me realise that the value is in what I leave behind.  It also means that my search for quality and fulfillment is in the moment, not some future time which may never materialise.  Now, I stop chasing some future desire and appreciate the quality and importance of now, and realise that I what I leave behind is significant – good or bad.

There is also a comment from Younis about coaches.

In the senior team there should be helpers who are also coaches, like Bob Woolmer was. He was a coach but he helped out with everything – in bowling, in life, in stretching, in luggage, in everything. This is not football, where you need to have that kind of coach. Here in cricket it is in individual game in a team game.

This feels a lot like coaching software developers … individual game in a team game, and that experienced developers need nudges and guidance, and noobs need technical coaching.  And as a coach, you need to help out with everything too.  I recently realised that I don’t help out with many things.  Actually, I don’t want to either.  It’s not that I can’t help, but I just can’t multi-task and be effective at everything.  I am the kind of person who multi-tasks and delivers less than 100% quality on each task, but when I serialize my tasks, I hit 100% quality quite often.

So, here’s my take on coaching software teams.  It’s sometimes like cricket, and sometimes like football too.  You need many coaches.  Coaches that work with technical things, people things, process things, communication things, management things and all sorts of things.  I know that I suck when I try to do people and process coaching at the same time as technical coaching.  It’s the thing that Peter Hundermark made abundantly clear to me over the last few weeks.  Now I know why he says that Scrum masters can’t be product owners, or can’t be part of the team, all at the same time.

That is also the reason why I can’t create miracles.  The people that have had greatness bestowed upon them; Mahatma Ghandi, Martin Luther King, Nelson Mandela, and many others; never created miracles but they allowed the people that they influenced create their own miracles.  Good software coaches are like that too.

So, Younis Khan and I are not related in blood, nor in career paths, but I have learned from an unlikely source with a very similar name.

Trust has popped up in so many of my conversations recently.  It came up at home, at a new school that Lia will be starting next term, in the DDD course that I gave earlier in the month, in Peter Hundermark’s scrum master certification course.  And I got a one line email that said this.

The entire world lives on trust. Every aspect in life moves with trust.

The more I think about situations in life that will prove this statement false, the more it seems to hold true.  Even in design it holds true.  Your most fundamental architectural decisions are based on trust and the implementations of that architecture work because of trust.

It’s true for code too.  If you don’t trust the code on which you build or depend, then you might as well write everything yourself, and give up your place on your team.

I was thinking about the AOP with DDD tutorial that I will be giving at OOPSLA this year, and this trust thing came up.  Here again, aspects and the classes into which they get woven, need a trust relationship.  It may seem like a stretch to make that statement, but I think it holds true again.

So, how do you gain trust?  I am not sure, but I think you have give up something first.  Maybe you need to show your vulnerability first, then it becomes easier to let someone into your space.  Then, perhaps, they will let you in to their space too.  When ego walls are erected, then trust finds it hard to grow.  By ego, I don’t mean arrogance, I mean awareness of your self that you hide from others for fear.  Perhaps, it is only when you show your true interface, that the other will worry less about hidden agendas.

In code, trust lies in interfaces and types, not in implementations.  It’s really about trusting the implementation that makes types worthy.  When you trust the type and send it a message and it behaves as expected, then you trust it.  If you request something of an abstract type and the message was received by an instance of a subclass, then you expect the subclass to behave like the abstract type.  You don’t hope that it does behave consistently, you trust that it does!

Trust is tied in with ubuntu too.  You can’t be part of a community nor allow yourself to be defined and shaped by the people around you, if you can’t trust them.  I think ubuntu coding needs trust as one of it’s values.  It’s already a value in XP, and Scrum, and families.  It needs to be in teams, and organisations, and communities and nations too.

It was a privilege in itself to be invited to speak at Scrum Day but my expectations were blown out the water.  Knowing some of the people behind the scenes made me realise, again, what can be achieved when you put a bunch of talented people into a room with a common purpose.  Although, I am pretty certain that these passionate people didn’t just share a common purpose – it meant everything to them.  And so, to all these wonderful people who gave up their time so we could learn a lot more, take a huge bow.  You deserve it! (PS: Can’t wait for next year!)  And if you’re looking for copies of the slides, then hop over to this page.

A few personal observations about this event:

• smooth! very, very smooth!
• Excellent speakers, excellent content, great questions.
• Nice buzz.  Felt like there was something for everyone – from noobs to old war horses.
• Adoption Challenges!  Seemed like this was a topic that came up in various guises during the day.
• Sharing.
• The magic wand / silver bullet was not in the building.
• Professional event with a warm community feeling.

And a small note on my presentation since I heard the comment “So what’s agile design got to do with Scrum?”.  Short answer: everything!  Absolutely everything.  If you’re using Scrum do build software, then agile design is the best feedback loop that you have.  The fact of the matter is that code does not lie yet it is the most ignored area in Scrum.

Well, I thought it was ignored until Jeff Sutherland, in his keynote, answered that Scrum hands off all agile engineering practices to Extreme Programming.

And read what others have tweeted about #scrumdaysa!