Meeting my match

I recently posted on LinkedIn complaining about companies who automatically reject resumes if they don’t detect certain keywords rather than look for experience, and a few moments later I stumbled across ScrumMatch. It wasn’t just Nicos Marcou’s video that triggered my post; I had also been chatting with a couple of iron ring-wearing engineers who bemoaned their toothless professional body. I pointed out that we don’t have an independent body overseeing Agile, just certifications that can largely be acquired by attending short courses, so ScrumMatch caught my eye.

A relatively recent creation, ScrumMatch is “the job platform for Scrum Masters by Scrum Masters”. On one hand they interview Scrum Masters and assess their proficiency, and on the other hand they talk with organisations to see if they actually walk the talk. On their About ScrumMatch page, they describe it better:

ScrumMatch helps true Scrum Masters stand out and helps organizations find and hire true Scrum Masters.
ScrumMatch helps true Scrum Masters find organizations that are serious about Scrum.

As someone who is struggling to find true Agile companies, I thought I’d give these matchmakers a try 🙂

After a minor hiccup (I managed to schedule an interview at 1am!) I had the chance to chat with co-founders Stephen Sykes and Johannes Geske. I won’t go into details but we had a great discussion including how I first got into Scrum (c/o Systematic in the 1990s), a brief case study, then my assessment feedback, and wrapped up with a general chat about Agile. (They’re both really nice guys who clearly know about Scrum, so I could happily have chatted for another hour or more!) They put me in the top 5%, which of course felt good – I know I’ve been doing this a loooooong time and really ought to know my stuff by now, but job hunting is frustrating and makes one start to have doubts.

They are currently victims of their own success, swamped by people wanting to be assessed, but I can thoroughly recommend the process – sign up now and schedule your interview ASAP. I don’t know how they will scale their capacity but I would really like to see companies rely on ScrumMatch’s assessments far more than some arbitrary certifications. I’m interested to hear other people’s experiences with ScrumMatch and/or if you’ve found other useful services.

What’s in a name?

Don’t worry, this post isn’t about Romeo and Juliet – it’s about the ongoing discussions around using the “A” word (Agile), whether the way a team works is Scrum, Scrumban or something else, and whether it really matters what we call it.

I can be a stickler about using words and phrases correctly, but I also know when I’m beaten. For example, “literally” means “in a literal or strict sense; really; actually” – it does not mean “figuratively”, the opposite of literally … except now it does because so many people have misused the word. It makes me literally makes me cry (no it doesn’t) but I know language evolves and so must I.

When it comes to a term like Agile, I wish people would learn its meaning and use it correctly but influential people (e.g. executives) and organisations (e.g. consultants) use it incorrectly, unfortunately people listen. When the people at the top of an organisation say “We are Agile” but clearly aren’t, who is brave enough to correct them? Especially as these tend to be large orgs that still rely on command and control to enforce the company line. But it’s not always the execs fooling themselves – often they have paid a lot of money to big name consultancies to advise them, but the consultants know they get repeat business by not rocking the boat, so they tell the execs what they want to hear. Just cross out some of the old department names and use the new SAFe names, you’ll be Agile; here’s my invoice.

Sadly there have been so many poor experiences with Agile (or should I say “Agile”) that people have become afraid of the word. At least once a week I see an article saying “Agile is dead” or “Don’t use the A word” because the term has been so abused. I’ve seen Agile coaches change their job title to “Change Agent” or “Organisational Improvement Coach” or even “Process Optimization Specialist”. The problem (well, one of the problems) is that you need to be inside an organisation to help it change, but if they shy away from the word Agile then how can you even start to be engaged? (Change your job title, I guess.)

Then we come to the Scrum Master role, which seems to be almost universally taken to mean “meeting organiser” and “impediment remover” – it’s no wonder many companies have removed the role when they see it like that. Even renaming it to “team coach” doesn’t really help because that’s seen as the manager’s remit… but how many managers have the skill and/or time to do that? Especially as the role of Delivery Manager seems to be on the rise, that sends the clear message that their focus is on Delivery, i.e. you will be measured on how many widgets your team can push out the door.

Words matter; titles matter; what you call something or someone indicates how well you understand and appreciate it/them.

Having said that, I’m now going to argue the opposite 🙂 Does it matter if the way a team works is called Scrum, Scrumban, or something else? To anyone outside the team, I would say it doesn’t – let the team find what works best for them, given the constraints and requirements placed on them. Within the team I believe it helps to know not only how you work together but where those concepts come from. If you’re on a team that says they do Scrum, then you should be able to look up Scrum and understand how the team works, in the same way that if they say they do trunk-based development then a quick Google and some reading should help comprehend that approach. The complication comes when they say “We do Scrum… but we don’t do retrospectives” (perish the thought!) or something like that, but even then an annotated diagram is probably enough to make that clear.

Does it matter what the team call it? To most people, I would say no; to the team, I’d say it’s more important to be clear about how you work (team working agreements, explicit policies, etc.) but using the correct names where applicable would also help.

To those consultants and organisations who insist on misusing Agile terms for their own benefit, I say “A plague on both your houses!” 😉

Unlocking Kanban: My KSD Course Experience

I’m not one for collecting certifications for the sake of having them on my résumé, but I have received some feedback about my LinkedIn profile that suggest I need to make my experience stand out more. As part of updating my work experience (still a work in progress!) I began thinking about coaching-related courses as a way to refresh and extend my knowledge… and as if by magic, a friend messaged me about some courses he had coming up. TLDR: I really enjoyed it and thoroughly recommend both Evolutionize and the KSD course in particular.

Kanban is one of those things where many people think they know a lot more about it than they really do; personally I have read books, watched videos, engaged in online forums, practiced Personal Kanban, attended introductory sessions, worked with teams who have been coached in Kanban, and even had the opportunity to observe experienced Kanban coaches, I still felt there were gaps in my knowledge. So when I saw that Jerry’s upcoming courses included Kanban System Design, I signed up immediately. KSD (previously known as Kanban Management Professional Part 1, KMP1) is focused on learning how to design predictable work management systems for teams and initiatives. Jerry’s company ( run introductory and more advanced Kanban courses (as well as other topics) but KSD seems to be a good point for me to jump in… and it was only a couple of weeks away.

It was a small class, and the initial self-assessment showed a range of Kanban experience from “informed” (e.g. been to a conference, watched some videos) through practicing (implemented a Kanban board with a team), to “master” – I rated myself as practicing because I’ve been through the initial steps with a few teams but only a couple of time have I had the chance to go further. Jerry used this quick exercise and a question about our expectations as a meta way to demonstrate “Fit For Purpose“.

Pond @ Imperial Palace East Garden @ TokyoI’ve read the story of how David Anderson’s visit to the East Gardens at the Imperial Palace in Tokyo, how they control the number of visitors with a simple ticket system. The number of tickets reflect the garden’s capacity; when all the tickets are in use, they cannot accept more people; when someone leaves they return their ticket, which means a new visitor can take that ticket and enter. This low tech approach is the basis of Kanban: the availability of a ticket indicates room for a new visitor. Applying this to how a team use a Kanban board, they pull in new work when they have capacity for it rather than it being pushed on them.

Covering the Core Elements of Kanban, principles and practices was a good refresher and answered some questions for me. Often when people think of Kanban they concentrate on visualization, especially the “To Do, Doing, Done” boards used by Scrum teams, but our brief brainstorming exercise resulted in a list of other forms, e.g. architecture diagrams, story maps, and dependency network diagrams. After covering the practices, we played a cut-down version of the getKanban board game – it’s available online at The game was a great hands-on way to simulate a few days using Kanban and stimulated some interesting discussions.

In summary, the course was very useful. The content was great; it reinforced or corrected my experience, and filled in a few gaps. The instructor did a great job with the pacing, giving us time to delve deeper where we wanted to and answering all our questions. And my fellow participants helped make it enjoyable by sharing their questions and experiences too.

If, like the people in the cartoon below, you’re stuck, too busy, idle or just looking to learn more about Kanban, check out the courses at Evolutionize!

Agile PhotoWalks

Saturday’s outing with Toronto PhotoWalks (the photography group I started in 2009) was a good example of why I often refer to them as agile photowalks. (If you’re wondering what a photowalk is, then just imagine a group of photographers getting together to explore the streets and parks of the city, walking quite slowly so that we have time to see and shoot anything we find interesting, and then chatting about photography over a drink.)

From the early days of the group, I have always organised and led TOPW events in an agile fashion: walks have a start and end point, and a (somewhat flexible) time for reaching the end. Much like a project with a deadline, how we get from A to B and how much we do along the way are up to the participants. Sometimes the walk’s leader will suggest points of interest, for example there’s an historic building on road X, but when we’re in the area someone might spot a more interesting building on road Y, so we’ll head that way. (Sometimes part of the group takes road X and the others take road Y.) The main thing is that everyone knows the general direction we need to be heading, so if they take a detour they can adjust and still end up at the final meeting point.

What happened on our most recent walk was that the tail-enders (about six of us) had stopped to watch a few minutes of a football match and then took an unintentional detour (ok, we were lost), so when we reach a literal fork in the road we had to decide whether to go south and follow the route the rest of the group took, or go north taking a more direct path and skipping a couple of places we had hoped to see. There was one optimistic suggestion that we could walk faster and stick to the original plan but more realistic heads prevailed and we sacrificed the southern loop in order to try to catch up.

I usually try to stay near the back of the group to make sure no-one gets lost or left behind. The people at the front know the rough plan and can always contact me if they want to discuss options. Sometimes I need to call those at the front to ask them to pause for a few minutes to give the rest a chance to catch up, but the aim has never been to have the whole group (sometimes over fifty people!) walk in a single pack – almost as soon as we set off small affinity groups form because people like to chat or seek out similar photographic targets.

Then, when we reach our destination (usually a pub) we often discuss what we saw along the way – it’s surprising how often people miss something on the left because they were shooting something on the right, for example, so it’s fun to review a few pictures and learn from each other. Once in a while I’ll ask for feedback from a few people (e.g. a table of four to six people) especially those who are new to the group, because I know the regulars won’t be shy about telling me if they have a concern.

As the group has grown over the past 14 years there have been few problems. Membership is open to all but the Open Space “Law of Mobility” (used to be called the “Law of Two Feet”) seems to apply – those who find it engaging and beneficial stay with the group and those who don’t are free to move on.

With thanks to the TOPW members whose photos I’ve used to brighten up this post.