Dec. 9, 2016

Notes From The Toronto Agile Conference 2016

A summary of the "Host Leadership" talk by Doc Norton and the "Technical Debt" talk by Declan Whealan at the Toronto Agile Conference 2016

The Toronto Agile Conference (TAC2016) was hosted at the Toronto Hilton on Monday November 14, 2016. As is often the case, the “hallway tract” was my favourite — I tend to gain the most by talking to other practitioners and swapping stories.  That being said, the forever-student in me always takes notes in the sessions and I thought I’d share a couple of them.

Keynote: “Leadership starts with an Invitation” — Doc Norton

Doc Norton is a great speaker, he has a casual presence that feels like conversation.  The topic was “Host Leadership” which was first introduced by Dr Mark McKergow and Helen Bailey in their book Host.  The concept contrasts our more traditional view of “Lord” vs “Servant” leadership.

  Standing room for the @DocOnDev on his keynote 'Leadership starts with an invitation'

To begin with, let’s review the 7 pillars of servant leaders:

  1. A Person of Character
  2. Who Puts People First
  3. Skilled Communicator
  4. Compassionate Collaborator
  5. Has Foresight
  6. Is a Systems Thinker
  7. Leads with Moral Authority

Now, imagine having a conversation with someone you consider a lord-style leader and asking them about this list.  The first six points are all things we often pride ourselves in regardless of our leadership style.  No lord-style leader thinks of themselves as lacking in character or foresight.  So although these are good traits, they don’t really distinguish servant-style vs lord-style leadership.

The seventh property is even worse: it isn’t really a personal characteristic but something that is given by the team.  Moral authority is something obtained through the granting of the team.

All of this is problematic, even without introducing the complication that consensus driven management doesn’t work in all situations.  By contrast, host-style leadership introduces six roles that a leader should play:

  1. Initiator: someone who gets the ball rolling
  2. Inviter: someone who invites people to participate
  3. Space Creator: someone who sets the environment / climate
  4. Gatekeeper: sometimes we do need somebody to say “no”.  Limitation on direction and participation can keep teams focused at the high level.
  5. Connector: the hub who puts people together
  6. Co-participant: the leader who keeps their hands dirty doing work

Doc Norton told a story about moving to a new neighbourhood to highlight the difference in the host leadership style.  His family moved into a newly constructed neighbourhood and the developer threw a community picnic for everyone to meet their neighbours.  Norton and his wife decided to continue this on and threw a euchre party later that year.  Part way through the tournament he noticed that people were missing from the main floor.  After wandering around he discovered a spontaneous poker game in the basement.  His initial reaction to this was lord-style leadership: it drove him crazy that people were playing poker at his carefully orchestrated euchre tournament.  Eventually he realized that the purpose of the party was for the neighbours to get together, not what game was played and he “let go”.

Setting up the party, he and his wife initiated the idea, made the invitations, set-up their home and the rules of the tournament.  They brought people together and they themselves participated in the games.  The key difference here is that once realizing the purpose he let go of the command-and-control and let the party organize itself.  Now there is a yearly poker tournament.

Lord and servant style leadership are points on a spectrum.  Host style leadership really is a series of roles across the whole spectrum.

“Moving from Technical Debt to Technical Health” — Declan Whelan

Declan Whelan opened his talk (slides: ) with the statement: "I am very qualified to give this talk, I've created a lot of technical debt”.  Besides being funny, it is an excellent statement on all of us in the development community.  Technical debt is all about discipline and we all succumb at some point and need to be vigilant.

For those not familiar with the phrase, technical debt is the cruft we accumulate in software usually due to deadline pressure.  Those decisions we make that complicate the creation of software in the future.  This isn’t about bugs, but about design decisions and shortcuts that make our future self’s life miserable.

Useful diagram for conveying slow down caused by technical debt

I very much plan on using this diagram.  It is conveyed better if you draw it interactively, talking to people about the how much longer it takes to get each version out, or how much less development you can do per time box.  Once you’ve drawn the curves, you connect the difference to show it as an expression of technical debt.

Whelan reminded us of the ultimate cost of technical debt: re-writes.  One example was Netscape — a copy arguably destroyed due to a giant re-write.  He also very honestly admitted that Agile’s focus on speed can make technical debt worse.  Discipline is required to overcome this, but in a speed-of-delivery focused environment this can be problematic.

The phrase “technical debt” itself is revealing.  Just like a low principal mortgage, you eventually end up spending more time due to the debt than the features you want delivered.  This can be hard for non-technical people to understand.  Whelan used the analogy of a dirty kitchen.  When management walks into a filthy kitchen with dishes piled high and rats and roaches scrambling, they understand this.  Software doesn’t really have the equivalent.  Management only sees a slowing in delivery.

The truly depressing part of all of this is it is a solved problem.  We know what causes it, we know how to avoid it and yet we succumb. 

As an exercise we played the excellent game Dice of Debt by Tom Grant.  It conveys the value of increased delivery in the long term by spending a portion of your development effort to improve the software quality.

A couple of references mentioned were the book Your Code As A Crime Scene by Adam Thornhill and the Agile Alliances A2DAM.  The book describers techniques for measuring technical debt and how to focus on the areas in your code with the best return on effort.  The Agile Alliance Debt Analysis Model describes how to analyze, fix and prevent technical debt.


Doc Norton's talk on Host Leadership was a great intro to the topic; introducing the concept of leadership through invitation and the 6 roles.  Declan Whealan's seminar on technical debt gave me new tools to help guide a conversation on an important subject that I often come across in my coaching. These were only a subset of the sessions I attended, maybe I'll detail the others in another post later. 

Image of ctrudeau

Christopher Trudeau

I'm a Software Architect and VP Development with experience in the start-up and Fortune 500 worlds. My industry experience includes telecom, banking, electronic publishing and gaming. I'm passionate about building strong, successful development teams using just the right amount of process. I've built teams responsible for delivering highly available systems capable of serving millions of users.
blog comments powered by Disqus
Image of ctrudeau

Christopher Trudeau

I'm a Software Architect and VP Development with experience in the start-up and Fortune 500 worlds. My industry experience includes telecom, banking, electronic publishing and gaming. I'm passionate about building strong, successful development teams using just the right amount of process. I've built teams responsible for delivering highly available systems capable of serving millions of users.

Latest Posts

Leading and Lagging Indicators: What is the right way to measure performance?

How can you measure and track your performance using leading and lagging indicators? 

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Changing organizational culture at Siemens Digital Factory

Siemens DF extended the use of agile methods the right way, through a thorough adoption of the essence and practice of being Agile

Image of kpogorzala

Konrad Pogorzala

Presenting at the Regional Scrum Gathering South Africa 2018

agile42 present at the Regional Scrum Gathering to be held in Durban, South Africa, 8-9 November 2018

Image of joperold

Joanne Perold

Agile Coach in South Africa. Explorer, learner, experiencer, part time philosopher, working with teams and organisations to be more agile.

Scrumtisch December 2018

The Berlin Scrum User Group meets on December 13th at agile42, Gruenberger Str. 54, 10245 Berlin.

Image of aballer

Alexandra Baller

agile42 Team Assistant

Motivation to Get Better

When Turkish real estate site Zingat realized that their Scrum adoption suffered from anti-patterns, they decided it was time to improve

Image of ayse.turunc

Ayşe Turunç

As an Agile coach, I strongly believe in people talent, in collective intelligence and that happy teams are more efficient. I'm looking forward to put my talent to help teams and individuals to work better together and grow.
Image of ebru4984

Ebru Yalçınkaya

I act as a change agent where the teams, domains need to enhance agility to reach their goals, to create a shared vision if needed. I coach every kind of team , every domain, like management teams or like customer care, technology and sales groups.