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

Scrum Anti Patterns

Since Scrum is easy to understand beginners may use some of the practices and repeat them in a mechanistic way without understanding the principles

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.

Scrumtisch March 2018

The Berlin Scrum User Group meets on March 8th at SAP in Rosenthaler Str.

Image of aballer

Alexandra Baller

agile42 Team Assistant

Welcome to our new agile42 Event Space in Berlin

agile42 now offers training and meetings in its new cozy and flexible open space, right next to its Berlin headquarters

Image of apanagiotou

Anna Panagiotou

Report from the Scrumtisch Berlin of January 2018

A report about the February meeting of the Berlin Scrum User Group facilitated by agile42 coaches Javier Pérez and Gregory Keegan

Image of javierperez

Javier Pérez

Javier invested his first years of career working as developer and business analyst in Madrid. When Javier moved to Berlin, he discovered his passion: to help teams and organizations in their cultural transformation towards agility working first as Scrum Master and later as Team Coach.
Image of gregory

Gregory Keegan

Greg has been working as a Scrum Master and Agile Coach for nearly ten years, helping teams and organizations to improve the way they are working.

Certified Scrum classes in Sweden

We want to invite you to our first ever Certified Scrum Product Owner (CSPO) class in Stockholm on February 15-16

Image of giuseppe.desimone

Giuseppe De Simone

Giuseppe is a Certified Enterprise Coach and a Certified Team Coach who is passionate about helping individuals, teams and organizations become resilient and agile. He is one of the only two CECs living and working in Sweden.