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

9 December 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. 

Subscribe to new blog posts

Did you find this article valuable? To be promptly noticed of new blog posts by agile42 you can subscribe to our notification system via email.

Discussion No comments yet. Be first to comment!

No comments yet.




Refresh captcha


Latest entries

Scrumtisch Berlin: August 22nd, 2017

August 2017 meeting of the Berlin Scrum User Group, facilitated by agile42 coaches Noel Viehmeyer and ...


Certified Agile Leadership comes to Vancouver

First part of the Scrum Alliance Certified Agile Leadership (CAL) program will be available in Vancouver ...


Survival Tricks for Remote Developers

Video and slides of the talk presented by Alessio Bragadini at PyCon 8 conference in Florence, ...


Sponsoring Agile Africa

agile42 sponsors Agile Africa 2017 in Johannesburg, 21-22 August


The nature of innovation

Guest facilitator Sonja Blignaut reflects on the 5-day Innovation Sprint with agile42 in August 2017