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

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s