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 (evolutionize.ca) 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 http://www.kanbanboardgame.com/ 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

TOPW.ca

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.

Over-commitment

When I wrote the “Long time, no see” post in December I was planning to resume writing regularly (at least bi-weekly) but since then I’ve only managed one. I thought I would have some spare time that could be put towards it but other things got in the way.

Does that sound familiar? How many teams start a sprint having planned to complete a number of things, only for that plan to go awry? If your team hasn’t experienced it yet, then it’s just a matter of time before you do… or maybe you’re playing it safe and you have a second planning session mid-sprint.

bury headI’m not saying this is a bad thing – stuff happens and not adapting would be worse. Sticking blindly to a plan and ignoring reality sounds ridiculous and yet many organisations still do precisely this.

So how can we reduce the chances of our plans being impacted? Plan smaller steps; discuss risks and dependencies as part of planning; understand your capacity; and say “no”, or at least “not right now”.

Plan smaller steps

planning onionIf you plan once a year (e.g. an annual budget cycle) then try moving to quarterly planning. If you create quarterly roadmaps that describe what needs to be delivered, then break it down into smaller feedback loops. If you’re a scrum team that plans four-week sprints but finds yourself replanning during sprints, then try two-week sprints. Whatever your cadence, if your plans often need updating then try a shorter timeline. It’s also possible that your plans are too detailed or rigid; there needs to be room to adapt based on learning, discovery and feedback. This is also why there are multiple “planning layers” – the team meet (at least) once a day to coordinate their efforts, share new insights, identify obstacles and make adjustments as needed. The shorter these feedback loops are, the sooner the team can respond.

Discuss risks and dependencies as part of planning

raidSprint planning isn’t simply for the team to decide what “fits” – there should be (or have been in preparation for planning) discussions about the risks, assumptions, issues and dependencies. The somewhat-controversial Definition Of Ready is a good place to keep a list of reminders of the types of things to consider, e.g. if it takes a while to get access to a particular system, then make sure the team knows to start that process ASAP (in extreme cases, it may mean postponing a story until the access is granted). What else might throw the plan off course? It’s not possible to predict and anticipate everything but the team should learn from past “gotchas” and try to avoid repetition.

Understand your capacity

overflowing bucketEven if everything goes smoothly, there’s no point in planning for more than could be realistically achieved. If a team uses story points consistently, then they probably have a good guide as to their capacity. Even without putting a number on it, stable teams should have a good feel for what is possible. The trouble with both those approaches is that teams can believe (or be cajoled into believing) that they can do more “just this once”. Forecasting (e.g. using cycle time) is based on the reality of historic data and is less open to “interpretation” or wishful thinking.

Say “no”, or at least “not right now”

drakeThe previous steps can help improve the likelihood of success, but one other defining factor is whether the team feels they can say “no” to taking “just one more thing”. If they feel they have to say yes to everything then there is no true commitment. (I know commitment is a controversial term; I’m using it as a shorthand for what the team tell those outside the team what they believe is achievable.)

In short: don’t make promises, because things change. Small steps with frequent feedback let your customer/sponsor see progress (which should lead to increased confidence) and collectively you can make adjustments based on new information.

I’m not committing (out loud or even just in my head) to updating this blog every two weeks, but I will try to write when I have time and have something to say. 🙂

Describe Your Ideal Development Process

All too often discussions about how to improve a team’s/company’s software development process are met with “It won’t work here”, so I find it often helps to discuss the ideal process and then look at the next step(s) that could be taken to move closer to it. Yes, you might not get there in its entirety, but that’s why it’s an ideal process and we’re just trying to move closer to it.

This video by Dave Farley is a presentation of what an ideal process might be, so I’m going to step through it and expand on some of his points. Feel free to disagree with what that ideal looks like, but for now, suspend any thoughts of “it won’t work here” and just focus on what you would like it to be.

The Goal of Software Development

  • Solve Problems for Others, with Software
    It’s hard to disagree with this premise:
    Know your customer

    • if you’re not solving a problem, then why are you building something? Now it could be that you’re building something truly revolutionary and your target audience doesn’t know they have a problem yet, but someone has identified an opportunity in the market. Maybe we need a broader understanding of what “a problem” is but if we’re not building a solution then we should probably stop.
    • Dave mentioned that you’re being paid to do it, so it must be “for others” unless you have some convoluted cross-billing system for your personal finances! (Even if I’m building something for myself I tend to use a simplified version of this process but let’s focus on professional software development organisations for this post.)
    • I think “with software” is a reasonable assumption given we’re talking about a software development process but I will just add that one of my favourite solutions to a customer problem was when the team laminated some instructions rather than build a new help tool.
  1. Understand the Problem
    You keep using that wordDave mentions requirements. I find teams often misunderstand what this word means. A “requirement” is just a description of the problem… and the description could be in the form of diagrams and conversations. It does not have to be specified in great detail, written down and signed off – in fact, that’s exactly what we don’t want!
  2. Solve the Problem
    Write some code. I don’t think this needs an explanation.
  3. Confirm the Problem is Solved
    I’ve encountered disagreement when discussing the need for writing tests but (remember this is an ideal process we’re discussing) everyone wants tests to exist. Rapid, reliable, repeatable tests. There was unanimous agreement that flaky tests are worse than not having them.

I agree with Dave’s summary that the Ideal Dev Process results in Great Quality with Minimal Work, but this is where I’ve seen people get confused by “minimal work”. Often they take it to mean that they need to know everything before they start so that they only do exactly what’s needed, but (the video will get to this in a minute) we cannot know everything upfront – sometimes the customer doesn’t know exactly what they want (or need), but even when they do it’s hard to convey that precisely. But let’s assume the dev team perfectly understand the goal; there’s more than one way to reach that goal so we may need to try some alternatives before we pick one. Oh, and of course, everyone writes perfect bug-free code the first time. So let’s agree that “minimal work” means “based on what we know at the time we’re doing it” which leads nicely into Dave’s discussion about continuous learning during the process.

For those reasons (and more) we should be discovering new information throughout the development process. We could be learning more about what the problem is, how to solve it, or how we work together to solve it. Any new information should result in the team deciding how to incorporate it; that may result in changing work which was previously considered finished, but what’s the alternative? If your customer initially said they wanted the screen to be blue but now they want it to be green, would ignoring that result in delivering Great Quality? I won’t get into the practicalities here but on my backlog of blog topics, I have the sunk cost fallacy and what to do if your customer keeps changing their mind.

The ability to incorporate new information requires the willingness and ability to change our minds and change our software.

How do we make it “Easy to Spot the Need for Change”? Frequent feedback from the right people. We should be asking our customers (and end-users) for feedback on whether we’re solving the problem; sometimes that leads them to realise the problem they thought they had isn’t the one we need to address first. We should also be asking the people involved in creating the solution (the dev team but also the people we are working with who are outside the team) for feedback on how we’re collaborating. In both cases that means taking small steps.

Safety netWe also need to make it “Easy & Safe to Make Changes” – we need safety nets to make it easier to spot when we’ve made a mistake and to fix it. Those safety nets can consist of tools, tests, processes and procedures; together they help developers move with more confidence.

Dave goes on to explain why setting up a deployment pipeline is essential, and I completely agree with him – if you build a system by hand then you run the risk of making mistakes, leading to inconsistencies from build to build. This is as bad as having flaky tests – you cannot rely on the results, so no matter how good your code is you cannot be confident in what you deliver to your customer. Automating the integration process also reduces the effort it takes, which means you can build more often, which in turn means you can give your users a new release more often and thus get feedback more frequently.

Part of the safety net needed to bolster developers’ confidence when making changes is another feedback loop: does your new code work with the rest of the system? There needs to be a way to let the team know if a change has broken the system, and then the team need to make it their priority to fix it. If the system is broken, why would you continue making changes before you fix it? You won’t know if your new changes work until you test them and you can’t test without a working system, so all you’re doing is postponing that knowledge, which in turn means you may need to backtrack further to fix your code – that doesn’t meet our aim of Minimal Work.

So the principles of our ideal development process are:

  • minimal work (minimize unnecessary work)
  • great quality
  • ability to change our minds
  • make changes in small steps
  • regularly verify progress (frequently seek feedback)
  • work incrementally (incorporate feedback)
  • creates working, usable system
  • keeps the system working

The video goes into more detail about Continuous Integration and Continuous Deployment, but I think that if we can agree on these principles of an ideal development process then CI/CD is a given.

Finish lineI read some of the comments under the video on YouTube and a major thread was around estimation. Given that the focus of Dave’s presentation was on the development process, I think estimation is out of scope (you can develop great quality software without estimation) but it probably deserves similar treatment, i.e. thinking through what an ideal product/project management process might look like. Estimation is a possible solution depending on the problem, but often it’s assumed that it’s needed instead of asking “Why, what will the estimates be used for? What problem are you facing for which you think estimation is the solution?” Often it’s considered necessary because someone wants to know “when will we be done?” but that should be a question to the customer as part of that frequent feedback loop – “are we getting closer to what you want?”. If we don’t know where the finish line is, how can we hope to say when we’ll reach it? Instead, focus on making small incremental steps and also asking whether taking another step down that path is the most valuable thing to be doing – sometimes we’ve gone far enough that we should park this work and move on to something else.


I linked to it a couple of times in my post, but in case it’s not clear the video I’m referencing is “The Most Powerful Software Development Process Is The Easiest” by Dave Farley of Continuous Delivery.