RubyFuza 2017 Presentation – Building a Learning Culture

Here are my slides from my RubyFuza presentation this year – building-a-learning-culture.

Here is a video of the FubyFuza talk – https://www.youtube.com/watch?v=ibeWsrLfiyk

 

Advertisements

Building a learning culture

Over the last couple of years, I’ve been focusing on how to push the skill / ability level of the teams that I’ve been working in.  For the last little while that has been focused across multiple teams.

Doing this from inside a team is “easy”.  Time can be spent pairing with anyone willing to pair with me.  To inculcate an attitude of understanding, of questioning, of challenging, and of trying new things to understand what it could look like.  In my experience, keeping an open mind and having respectful conversations enables much learning and growth in any developer – which in turn is more valuable for the company. And I keep on learning new things from developers of every experience level along the way.

Things are different when faced with the challenge of growing a learning culture across multiple teams and not being in any given team.  The following are some of my thoughts and experiments around building a learning culture in an organisation of 4 teams and growing.

Why promote a learning culture?

The software industry has a shortage of skills. It always seems hard to find good software developers to hire.

We have an ever-growing pool of new developers.  A quote going around is “Every 5 years the number of programmers in the world roughly doubles.  So half the programmers in the work have less than 5 years’ experience.” (1)

We are in an industry with a wealth of knowledge that can be consumed – but practical application is needed to truly understand the nuances.

We are in an industry where the learning gained from experience does matter.

Axiom: Experience is valuable.

However

“True learning involves a permanent change in the way you see and act in the world.  The accumulation of information isn’t learning.” – Benjamin Hardy (2)

True experience is more valuable

True experience involves a permanent change in the way you see and act in the world. Experience is not truly valuable unless it is learnt from.  True experience is most valuable when it can be understood in terms of principles and values that were effective (with a good experience) or were broken (for a bad experience).

Experience should be viewed around a common understanding of the values and principles being applied.  The values and principles should be based on the needs of the organisation.  Experience should be respected, discussed and challenged in line with these values and principles.

How can we harness experience to speed up learning?

Given that experience that we learn from is valuable.  How do we better harness the true experience in any given room / team / company?  How can we learn from our experiences and share those learnings with those who have not yet had them most effectively?  How can we extract the years of learning out of the experienced developers’ heads so that we don’t need to have 10+ years to learn it?

What about shared values and principles?

Hypothesis: Teams that value the same things in software will build software more effectively.

Lemma:
If we know vaguely* where you are going
We can all pull vaguely in the same direction

*Vaguely is important.

If we get too precise it limits a team’s ability to innovate and effectively solve the real problems they face.
If it is too ill defined, the teams have no direction and can waste effort duplicating work or going in different or unexpected directions.

Lemma:
Any decision we make should be based on a mental model that can be expressed.  If you can’t express the reasoning, then the reasoning is flawed.

If you don’t like something in a code review – understand why.  If you can’t express the value or principle that is being violated maybe you don’t know why and are just being opinionated.  Understand your opinion first, before expressing it.  It may be that the values and principles are still being met, just in a different way that you aren’t used to.

We need to move from conversations about how to conversations about why.  What are the intentional trade-offs and design decisions that are taking us in this direction or got us here? The how is important – but driven by a deep understanding of why.  This allows us to ensure there is no cargo culting of solutions and no sacred cows being ignored. How do we elevate the conversation from technology details to software truths?

Build a collaborative learning culture.

If we are self-aware and understand the decisions that we are making, then we can discuss these decisions with our teams and build a common understanding of what is a good decision for the team.  The team needs / context outweighs the individual’s needs.

If the team can understand the decisions it is making collectively, then teams can discuss their decisions with other teams and we can build a common understanding of what is a good decision for the organisation.  The organisation’s needs and context outweighs the teams’.

Context

It’s hard to justify why something is good or bad without context.

Without context – if the software does what was asked for, then it is good.  It doesn’t matter if it is spaghetti code.  It doesn’t matter if it is unmaintainable.  It doesn’t matter if it is inefficient.  Being right enough matters for now.  If the software never changes then it is good.  If the software changes, then we might have wanted to optimise for changeability and the current code is no longer good (enough).

Some things that we have tried

My focus has been on building a common understanding of why we do the things we do.  This provides a space for communicating opinions / values / ideas and increases understanding between the things that developers are valuing.

We tried

  • Code appreciation / Code review sessions
  • Code kata and conversation sessions
  • Kata sessions on Friday morning
  • Coaching – though harder to do cross-team
  • Retrospectives – though usually less focused on code

We introduced guilds to encourage cross-team conversations around specific topics.  These included: architecture, continuous delivery, security, databases.

We have an active tech blog, containing knowledge that is useful to remember or to share cross-team – e.g. security fixes made / to be aware of, continuous delivery pipelines of different teams, architectural knowledge base.  This is also a knowledge repository for learning so that new hires can start to get the context of what the rest of the team has already learnt and what their values are.

Code appreciation / code review sessions

This fluctuated through many different forms.  From once a week rotating through a different developer each week across all teams, to sharing just in your team and discussing and then a less frequent cross-team sharing session.

Code kata and conversations

1 hour a week facilitated session on different software topics ranging from TDD to DDD, from SOLID to testing practices and design patterns.  The focus is on practices and discussing and understanding the values and principles that elevate from the exercises.  This is usually in pairs or small groups working on a problem and then we retrospect on learnings as a group.  This started with doing some katas to explore certain ideas but then moved on to many different things and possibly shouldn’t have ‘kata’ in the title any more.

Learnings

We have been successfully changing the conversation from right and wrong and syntax to values and principles and design.  This has been noticeable across the teams.

When we agree on the values and principles, “right” and “wrong” become much easier to articulate.

I have relearnt that not everything is a teachable moment.  Different sessions have different focuses and sometimes in a group environment attempting to ask too many probing questions can be intimidating.

Not everyone will engage.  The key is to ensure that enough do and we focus on what the company needs from building a stronger learning culture and a strong software development team.  Hopefully the rest will pick up from the majority.

Where to from here?  Building a more collaborative learning culture

Everything that we’ve done so far has been to enable a collaborative learning culture.

But it has been focused on bringing the group involved up to a common level and I feel that we are now at a place with enough people engaged and interested.  We need to become truly collaborative in our learning.  This year I hope to see more presenters, more sharing and more growth and understanding across the teams.

The end result will hopefully be a competent, young team that can collaborate effectively around shared values and a common understanding about how to experiment and learn and discuss the right solutions for the organisation.

References:

(1) https://twitter.com/web_goddess/status/804452382536912897) – attributed to Robert Martin. Martin Cronje at Agile NZ 2016 quoted a similar figure.

(2) Via a great presentation by Katlyn Parvin – https://speakerdeck.com/katlyn333/am-i-senior-yet-grow-your-career-by-teaching-your-peers

(3) It looks like Martin is doing similar things to what we’re attempting to do (after moving to NZ) – https://speakerdeck.com/martincronje/agilenz-towards-mastery-establishing-craftsmanship-culture-in-a-team

Retrospective talk

Last TEK day I did a presentation on retrospectives in order to generate discussion and deeper understanding in my company and team around what this thing is supposed to be about.

I’ve had some good feedback since then from people who were initially resistant to retrospectives.  However there is still lots of work to be done – as always in this space 🙂

Attached is the presentation that I talked from.  Though mostly this is bullet points that fire ideas.  Perhaps someone else will find this useful.

Retrospectives: A focus on getting better

Lab: TDD, Pair Programming and Purposeful Practice

The organisation that I currently work for has two really nice practices.  Once a month there is R&R day – research and reading day – come to work and research something that you choose to research.  The other is TEK day – a mini internal conference focused on mini presentations and in the afternoon a lab.  This is also once a month.  Both of these days focus on no client/project work.  The agenda is driven completely by the employees.

At the last TEK day I ran a lab on TDD, Pair Programming and Purposeful Practice.  The goal was to give everyone an idea about TDD as well as one way to pair – ping-pong pairing – and to experience it doing some standard coding katas.

Here is the lab – TDD Pairing Practice Lab – if you’d like to read the details.  It gives a very brief overview of what TDD, pair programming and purposeful practice all are.  (Very brief… I did it the night before and I’m not sure it was sufficiently detailed, but there are several links and it gives you a start on the ideas so you can try them out.)

What did I learn?

I may have introduced too many things at once
I wanted to link ping-pong pairing and TDD together as it feels obvious and I’d been doing it with one of my team members.  Sadly he was on leave so couldn’t add his perspective at the session.  That said, possibly I should have focussed on TDD only first.  And then I could possibly have done another lab later in the year on pairing to add that in.  Doing too many things at once may have confused the process.

It is not just about the devs
Pairing gave the opportunity for non-devs to pair with devs and get a better feel and understanding as to what TDD and unit testing is.   I think it was insightful and helpful to them.  It also highlighted that this could be possible in your day-to-day work – exposing the non-devs to what you’re doing and how and increasing the communication flow between team members.

Requirements are hard
I had a typo or two.  And it was clear in my mind as to the goal of the simple requirements of FizzBuzz, but many questions were solicited around when things became a combined FizzBuzz instead of just a Buzz or Fizz.

Stress it’s about the TDD and code
Some groups spent a bit of time ensuring the console app worked.  The focus for them was meeting the criteria of printing out the numbers when the goal really was the process flow of learning TDD.

FizzBuzz took longer than I expected
We took much of the 2 hours on FizzBuzz.  Which was interesting by itself.  I expected things to go faster and hence included the more interesting StringCalculator kata.

Question 6 wasn’t very meaningful for FizzBuzz
I threw some food for thought in question 6 – how would you write it more procedural / object oriented / functional / etc but on such a simple problem it might not be as easy to see.  In the StringCalculator I think the questions might be more relevant.  And of course this had nothing to do with anything related to the core learning objectives of TDD and Pairing.

No one refactored (much)
It is red-green-refactor, but I didn’t see much refactoring towards beautiful code.  Perhaps I’m switched into a certain frame of mind at the moment as I’m re-reading Clean Code again.  But I suspect I’ll need to do a lab on readability and attempting to be DRY.  As well as when to refactor to new classes, etc.

Would anyone try it?
This was very non-committal.  But I think everyone had fun and everyone had better clarity on what it all meant.  Again – combining pairing with TDD – and asking “would you give it a try?” encountered a lack of enthusiastic response.  Maybe if it had just been one concept it would have been more interesting discussion.

One piece of feedback was that the ping-pong cycle was too short.  We did discuss a little that most likely it may not be as short in a complicated piece of code and the examples we were using for FizzBuzz definitely weren’t complicated.  But there was some concern around that.

Open to the discussion
The best part of course is that I had an open forum to present and everyone enthusiastically gave it a try.  That is awesome.

What would I change?

Ask more probing questions in the debrief.  Generally plan the debrief more deeply in order to generate more insights from and for the individuals.
–          Who refactored their code?
–          Who thinks their code is the most beautiful they could achieve?
–          Who changed their code while keeping the tests running and refactored in small steps?
–          Was it useful pairing with someone?  To learn?  To understand the requirements?
–          What did you learn?  What was really interesting? What was frustrating?

Do less, help more
–          I spent a little time challenging one group’s implementation of FizzBuzz which resulted in them refactoring.  I should have done that more to see who else refactored instead of going from “it works” to “next problem”.

I’m sure there is a lot more – including a bunch of the stuff in the learnings.  But overall I’m pleased with having done one more baby step in moving my organisation to at least understand XP practices.   While at the same time I continued to experiment and learn more deeply as well.

Got Books!

Some vacation reading:

  • Drive – because it is Daniel Pink and I really should read it.
  • Clean code – because I haven’t yet read it!?!
  • Continuous Delivery – because Fadi Stephan recommended it. Paging through it, it looks really great.
  • Applying UML and Patterns – because Herman Lintvelt recommended it in his DDD talk at SUGSA earlier in the year and I’m intrigued. Apparently it has a bad title and isn’t about UML at all – more OO design which is interesting.
  • Rework – because a collegue recommended it as an interesting read, and what the hell. Though it was in the “self-help” section in Exclusives which is a little disturbing.

All I need now is a copy of Kent Beck’s 2nd Edition XP book and I’ll be happily ensconsed in learning.

Hmmm… perhaps I need a kindle – the instant gratification may make up for not having the books to hold in the hand.

And now for 5 weeks holiday to read them all.  Yay!