Cooking With Kanban

A friend of mine used to be a chef, but he became a software developer. At the time he had just started on my team, and as an agile tester I used to help coach developers on testing. The idea being this was a team activity and everyone can test. The team where using WIP limits and BDD techniques to test first, and make sure all bugs found where fixed minutes later.

Now usually explaining the value in this takes some time to either new starts or to folks who are usually used to just firing work at testers and moving on. But this guy picked it right up, and LOVED the system. I had never seen someone take to the process so quickly. A lot of folks (myself included) tend to get stuck in their old ways of working. Learning is hard.


I was talking to him about it and he made me realise something. Kanban is EXACTLY how kitchens work. The goal of a kitchen is to get high quality food to the customer. Each team member whether chef or wait staff work together in a none silo’d environment to enable this to happen. This is exactly what we are trying to do as a software team.

An order comes in from the waiter, and the kitchen gets to work. They have systems in place to deal with each area. Eventually the food goes out to the customer. A wonderful example of this is in the film “The Founder”. The film focuses on how McDonalds become what it is today. A great watch, which I recommend. (Although you may end up hating the main character).

There is a scene in the film, where the owners of McDonalds explain their speedy delivery system. What they did was genius. They drew each area of the restaurant on the ground with chalk. Then got their staff to pretend to work on the various areas. By doing this they saw which area should be next to which, and how stream lining each section would best work. Cook the meat, prepare the bun, add the sauce etc etc. This is kanban in action. Visualise the process, test it to find waste, and make small changes to improve the process.

For coaches doing this is super important. Working with the team to visualise everything in your process is key, then you can start tweaking it to make it work. But also make sure nothing you try is permanent. In the McDonalds example they used chalk, as they knew they would need to make changes. It is important to be able to test your process. Make it part of your regular retro, run experiments by adding/removing lanes. Find what works for you.

So next time you are having a problem. Maybe your team is constantly fire fighting bugs, or maybe there is no way to prove value in your work. Try and think more like a restaurant. How can you work more like a chef? How can you improve your process? Give visualisation a go.


Impact Maps Are Fun

Do you work in tech and have to deal with pesky business analysts or project managers? Are you a project manager and have to deal with flakey development and testing estimates? Have you spent months working on a specification document only to spend more time arguing with everyone else? Worry not, there is an answer.

I suggest trying an impact map.

OK you may say, but I have already written a spec doc, is this not a waste of time? Well let me ask, who you are sending this spec doc to? Is it hitting the head of dev and possibly the head of test? Whats the usual plan after that? The head of dev allocates it to a dev team and they start writing code. At the same time the head of test allocates it to a test team and they start writing tests? This is the usual working way. But the main problem I have with all this, isnt really the handovers, or the time delay, or the confusion in requirements, it is, where is the customers needs in all this?

OK the argument could be that the needs are outlined in the spec doc, possibly in the inital page. But the more hands the doc goes through the more complexity gets added and the further away we are from getting the customer their needs.

So how can an impact map help?

Well the start of the impact map is the goal. The goal is a small simple outline of what the customer needs. Non techincal just a simple problem. It easily answers the question, why are we doing this? If any of the impacts or deliverables dont feed back to that goal, then are they really needed? Probably not, so why waste time developing, testing and building them?

Next we outline who the customer actually is, the user of our system. Here we may actually find out we have multiple users. That’s ok, once they all link back to our goal. Maybe the software we are building will have both internal and external uses, so we may have different requirements for each user.

This leads us nicely into part three of the impact map. The actual impacts. So what change can we make that will help our user achieve their goal? Don’t think technically here. Instead of saying “add a button to a screen that allows the user to access the next page of the app”, say “allow user to navigate the app”. This means that instead of getting bogged down in technical details, we are just outlining the problem that needs to be solved. The details can come later. If there is still a spec doc somewhere, now you can get impacts from it. You may actually realise that some of the things that where in the doc don’t tie back to the goal. Awesome, you have just removed waste.


Ok now you should have something that has a goal, a few actors and some impacts. Whats next? Well now we come up with deliverables.

This is where we can break down the impacts into smaller features or goals with customer value. The output of this could be epic stories. These can then be broken down into smaller stories. I suggest using specification by example to help break down these larger stories. Once you have smaller stories, you now have a backlog that your team can start working on.

Not only will this make sure every story you work on is adding value to your customer, it will also remove some other pesky problems with spec docs. There will be less misunderstanding over requirments, as everyone was in the impact mapping sessions and it’s visable to all. Also instead of having to deliver everything at once, you can now just focus on areas which will add the most value to customers first, then add the rest later.

im_templateSo hopefully next time you either get a giant spec doc, or have to write one, you could try using an impact map instead. I have used them to great value, and hope you will as well.

Further reading on impact mapping can be found here:

Lessons From Bob Ross

Recently my girlfriend has been watching a lot of Bob Ross. I never really knew much about him at the time. I vaguely remember him being on the TV when I was a kid, and also some references to him in shows like Family Guy. 


But I had never really watched him. Watching how he paints is incredibly calming. I was curious about his attitude to life as he uses expressions like, “We don’t make mistakes, just happy little accidents.” Or, “Talent is a pursued interest. Anything that you’re willing to practice, you can do.”

So I did a little research on him. It turns out he was in the military before paining, and used to have to shout at people all day. He decided when he left the military, he would never raise his voice again.

So years of shouting at people to do their jobs made Bob Ross become someone who people now watch to relax as he is so calm. So what can we learn from this?

Well, maybe being calm is infectious? People have actually done studies into Bob Ross and his recent fame resurgence. He has become very famous online, he was one of the most streamed artists on twitch recently. Folks have been using him to help with their anxiety. Bob realised that by being calm and helping others it would improve his own life.

Could we do this in our day to day lives? On the team you work in is it easier to blame others or try and help? Personally I would say it is much easier to blame someone else and pass along the problem. Do you ever catch yourself saying, “Thats above my pay grade,” or “thats another teams problem”.

I have definitely used that last excuse before. But it doesn’t fix anything, and it also doesn’t make me feel any better. I don’t get home from work feeling like I have done a good job.

It also doesn’t allow for collaboration in a company. So instead of quickly getting annoyed and blaming someone else. Maybe we could try Bobs approach and calmly turn the mistake into a happy little accident and use empathy to help solve the problem.


Instead of passing the problem, try and fix it by working with the other team. Maybe it’s a problem between test and dev, can we pair together and see if understanding each others view point can help? Or is it a problem between the front end team and the back end team, could we mix up the teams skills for a week and see what happens when we work together to fix the problem?

Yes, this is much easier said that done. But I think if we start small and try help others we will find our jobs to be much more rewarding.

I will leave you with some wise words from Bob Ross: “Didn’t you know you had that much power? You can move mountains. You can do anything.”

What Is A Test Coach??

Recently I have tried to move into the realm of test coaching. It’s an interesting field. Mostly cause nobody seems to have heard of the role.

I have had phone calls with recruiters looking for QA folk. They get in touch via LinkedIn mostly, and only one has ever asked me what a test coach was. I find it interesting that the people in charge of hiring QA’s don’t know what a test coach is, let alone does.

What I think most moving into the coach role do is just become a coach out of necessity. For example you are the only QA in the company, or there are not enough testers for the amount of work developers are churning out. So QA folk help teams to use collaborative techniques such as BDD and WIP limits. This of course introduces cool side effects like slack time, which testers can use to teach developers fun testing. I don’t just mean manually running through acceptance criteria or test cases (these can with help of the developers, be automated). I mean fun techniques like exploratory testing, which can be a very rewarding activity.


Once the developers understand HOW we test, they can easily sub in for an over worked QA. This then frees up the QA to get into a more coaching role. If you are the only QA in a company, or maybe one of very few over multiple teams, you can start helping other teams. Get one team working well together and testing upfront, devs testing other devs work. This means you can jump team and do it again. To me this is the role of a test coach. Someone who can teach others to test and once done, they can leave the team to work without them.

OK so what happens if your company has too many QAs? Maybe there is a tester per developer. On paper this looks AWESOME, right? But what can happen is the wall between dev and test remains, and in fact is harder to smash as developers can think it doesn’t matter how fast I get through work, there are LOADS of testers. But in reality even with more people trying to find problems, nothing beats helping to stop them from being started. So how can a coach help here? Well, the role of QA is quite quickly becoming, automation engineer. Which is cool, but in my opinion if you are writing code, you are a developer! A coach can enable automation engineers to become developers. They can do this using the above techniques and encouraging pairing.

I don’t understand the point of having some folk writing test code, and others writing production code. Surely coding is coding, and if paired up with devs, testers can become devs quite quickly. So now we have not just a multifunctional team, but multifunctional people.

Doing this you may hear something to this effect, “testers and developers are DIFFERENT people, they THINK different, testers will NEVER be able to code, and developers will NEVER want to test”. I believe this to be totally untrue.


In fact most software testers have a computer science degree and did not have a clue what a QA was until one day they got a job as one. When you do hear something like that, just ask to trial paring for a few weeks, and see if the team learn anything. What I have found enabling pairing, is a happier team. Yes, you get greater quality, but you also get testers who thrive as developers, and stop feeling like second class citizens to the teams developers.

Once you have coached your way through the teams, what next? You can start looking for waste in other places. Maybe security reviews are taking too long, or releases are difficult. Can you as a test coach help there? Of course you can.

This is what test coaching means to me, but it seems to be quite a new concept in terms of companies. What does it mean to you? How can we help more companies to see the value of a coach, and not just a box ticking QA?

Where To Start Part 3: Team Evolution

Part three of my where to start with BDD post. The first two parts can be viewed here:

So at this point your team has started using WIP limits and BDD.
Does your team now have a surplus of one role, maybe there are 2 or 3 testers who are not covered in you WIP limits as they are not developers.
Maybe its time to evolve a little and try blur some of the roles, or how about experimenting with your WIP limits?

Let’s talk through these two ideas.


In an earlier blog I talked about having WIP limits set to the number of developers in the team. So when a story is in test the developer is in slack time.

This is where we can start blurring the roles a little bit. Personally I like to invite the developer to test along with me. If our examples have already been automated then we don’t have to worry about testing them. Now we get to do some fun creative exploratory testing, this is great as a paired activity. Once developers see how you are thinking, they can then start doing it themselves.

For exploratory testing I tend to think of the least technical person I know and pretend to be them using the system. This is my dad (sorry dad). He has managed to find the most interesting bugs and get the best viruses over the years, and his answer is always the best for a tester, “Ohh yea I clicked on that cause I could”. If your system has a flaw no matter how small or silly you think it is, a user WILL FIND IT.

But pairing works both ways. After the 3 amigos session when a tester is in slack time, why not pair up with the developers. You could start doing a joint TDD exercise. The tester writes the tests and the developer writes the code to make the tests pass.

Eventually you could swap that up completely and have the developer write the tests and the tester write the code. You will have a true multi-functional team, where everyone can do everything.

So how does experimenting with your WIP limit work?

Well how about decreasing it. So if you have 4 developers, make the WIP limit 3. This frees up a developer to help the team. This means someone is always free to jump on code reviews, or to do some of that tech debt you can never find the time to get to. You can swap up that developer each story. It also encourages more pairing, as two developers can work together on a story.

There are loads of different things to try, use retros to see how they are working. Just don’t make too many changes at once, it will be hard to know what worked and what didn’t. (I’ve made this mistake before)

If you have any suggestions, or have run some experiments on your teams let me know.

Just make sure your team keeps evolving by trying new things. To quote Eddie Vedder, “It’s evolution, baby…Do the evolution”


How I Can Help You Today?

I once had a boss who in my first ever performance review meeting shocked me. Now I had been through some review meetings before starting in this company and I always DREADED them. As this was my second job out of college, I was still afraid of the process. But this guy sat me down looked at the “goal settings” page and said, “ignore that, its HR bullshit, how can I help you today?”

This blew my mind. The last company I was in, all my one to ones had been micromanaging sessions telling me I wasn’t doing my job well enough. All that did was ruin my already low self esteem as I was fresh out of college and to be honest terrified. One simple question changed all that, how can I help you today?

Honestly I didn’t know how to answer him. I was expecting to be told the work I was doing wasn’t good enough and that I needed to just get better. I kind of just sat there for a minute or two and then said something like, “how can I improve what I am doing?”

Instead of telling me what I was doing wrong, he told me what I was doing well. Then said maybe you should improve in X area. Then recommended a book for me to read, and booked me in on some training in that area. So when we caught up the next month, I was able to show what I had learnt and how I was able to improve my work. Also because I was totally disarmed and not afraid, I was perfectly willing to approach him with any problem I had.

He also taught me how to self learn. He did this by introducing me to the wider testing community and brought me to a conference. It was here I learnt that it’s not just the companies job to train you, you need to train yourself. So I started reading blog posts and attending meetups, and looking for new ways to improve and new things to try. This all started with that one little question and a genuine interest into my personal growth.

It also made me realise that junior folk will not know this. They have to be taught how to self learn. It is important as it not only helps the company but builds up the person’s self esteem. Instead of making me feel bad and dread a catch up meeting, I looked forward to them. It made me enjoy my work, which is super important. Your job should be fun for you.

It reminded me of something my granddad used to say when he rang me, “are you wanting for anything?” It was not do you need something, but, what do you want and how can I get it for you? It was a level of kindness that everyone should strive for.

Now I am human and by no means perfect, but i try to ask that simple question when someone asks me something, “how can I help you today?”

I will leave you with some wise words by one of my favourite musicians Frank Turner:
Be more kind, my friends, try to be more kind”.


Clear The Clutter

A family friend of mine used to be a  serious hoarder. I mean TV show worthy level hoarding. I was once asked to go help her clean her house, so she could move.

Every single room in the house was packed. There where maybe two seats that where not covered in books, magazines, news papers, hats, coats, shoes, if you can think of it, it was probably somewhere in that house.

My dad rented a skip and we set about removing the junk. Our friend usually had to be removed from the scene as she had a habit of picking stuff out of the skip and bringing it back into the house. She thought that one day she might need it. Thankfully after a few weeks the house was fully cleaned out and our friend was able to sell it and move.

This story popped into my head when thinking about old tech debt and bugs every company seems to manage to build up.

Why do we keep them? Ever go through those still open bugs and stories? How old are they?
If its 2 years old, why is it still there? Cluttering up backlogs and making it more confusing to see what real work needs doing?

How can we class it as a bug, if its out in production for years and nobody complained about it? Maybe fixing It could even ruin our current customer experience.

I once went to a talk where the subject of old bugs came up. This company went about closing all their open bugs, this managed to upset their customers. It seems that since the bugs had been in production for several years they where actually being used as either features or work arounds had been build and now stopped working. So fixing an old bug had actually changed how the customers where using the software, hilarious.


Are we just like my friend holding on to these stories and bugs thinking one day we will need them? Clear out the clutter, ask yourself this question: Is this stuff adding any value?

If the answer is no, DELETE IT!!!

If it’s really important it will come up again, but I’m sure if nobody has looked at it in a year or two it wasn’t very important anyway. Now you can focus on a cleaner backlog with stories that will actually add some value and make some customers happy.

Plato’s Cave

Recently I have been listening to a podcast by Blindboy Boatclub of the the Rubberbandits. For anyone who doesn’t know them, they are an Irish rap duo famous for wearing plastic bags on their heads and singing songs about owning horses.


Blindboy has recently become famous for his views on psychology and politics. He will show up on various Irish talk shows wearing his bag and discussing issues with politicians on various subjects, mostly about the state of male mental health in Ireland.

You can find his podcast here:

If you don’t know him I highly recommend you check him out. His podcast is a wonderful listen and makes my Wednesday commute to work a delight.

Recently he was talking about something that made me think. He was talking about Plato and his allegory of the cave.

I had never heard of it before and maybe you haven’t either. So let me try explain it:

Imagine a cave where people have been imprisoned from birth. They are chained in such a way that they can’t move their heads and can only look at a wall in front of them. Behind the prisoners is a fire, and between the fire and the prisoners is a walkway with a low wall. People can walk behind the wall hold puppets up above it so the puppets cast a shadow onto the wall in front of the prisoners. The prisoners can only see the shadows in front of them and are not aware of what is happening behind them. The sounds of the people behind them echo off the walls in such a way that the prisoners think that the shadows in front of them are talking.

All these prisoners know is what they see in front of them. If they see a shadow of a book, they fully believe thats what a book looks like and their whole world is just 2d images. In reality of course a book is a 3d object, but they have never seen anything else so have no idea.


If we stop here for a moment, we could relate this to teams working in isolation. Now I think everyone realises at this point that its good to have multifunctional teams working together, testers, developers and BAs all work together for a common goal. But what can then happen is the team becomes the prisoners. Yes they are all working for a common goal, but they don’t know what the goal is, or why they are working on it. Their reality is just what they see and they may be afraid to question this. Or worse they may not know they can question it, thus working on something with zero value. 

But fear not Plato goes on to give us some hope. One of the prisoners escapes. That freed prisoner goes on to discover the truth about reality outside the cave. This however takes time and is painful as he has to relearn everything about his world. Eventually the prisoner goes back to the others to explain to them about reality. The bad news is it on his return to the cave to help free his fellow prisoners, they refuse to believe him.

This could be where you fit in. Maybe you are on a team much like our imprisoned cave dwellers. You could start to question your work and your teams goals. Much like the freed prisoners journey, this might prove to be difficult at first. You may have to learn some new skills, also your team mates might not believe you at first.

Unlike the cave prisoners though, you can help show how putting value first will help your team. You could even start this be sharing what your team works on with other teams. Maybe organise a showcase weekly or monthly, for a member of each team to share their work. This will allow everyone to have a better understanding of what each team does. Also make sure your team has a very clear goal that will make the company some money when complete.

There are loads of things that can be done to help find value in our work. Let me know how you get on trying some, or even some interesting ideas you might have.

Don’t Be An Agile Beatnick

How many retros are you involved in?
Usually a lot right? Most teams have one at least every two weeks.

What usually happens? Do you do the usual stop, start, continue?

Do you come out of your retros feeling uplifting and motivated to get some cool new stuff done?

I never used to, the retro used to be a thing that I hate, “ohh this shite again, there goes another hour of my life”.

Turns out my attitude was horrific, I had become an agile beatnik.

Now what is an agile beatnik you may ask?
It is basically Ned Flanders parents from the Simpsons, remember them? If not see the picture below.


They where awful parents, “we’ve tried nothing and we’re all out of ideas”. That was me in retros. I was just complaining and not trying anything to fix problems. What used to happen after a retro, I would continue working the exact same way making the exact same mistakes and complaining about the exact same things in the next retro.

What was I doing wrong here? I was trying NOTHING new. Trying literally anything to fix the problems is better than just complaining.

So what can you do? Well have a think about your retro before hand. Write down all the stuff you want to complain about, and give it a google. You will be surprised that your problems are probably not unique. You may find some cool ideas to fix the problems, jot them down.

Now when you head into the retro stick up your problems, once they are up for discussion you can bring up some sample solutions. Now the fun begins, you get to suggest trialing something new for a few weeks. I suggest making one maybe two small changes and seeing what happens. Making too many changes can cloud the outcome. You wont be able to tell what worked and what didn’t, and this can very easily lead you back down the same old path. After you have decided the change to make as a team, try it as an experiment for a few weeks, at least until the next retro.

Now you are in a much better position. Make sure to keep an eye on the problem you are trying to solve with your new experiment. Also don’t get discouraged if your experiment fails, this is normal, learn why it didn’t work and change it. The important thing is you are trying something.

So try something, try anything, but don’t sit around and say you are all out of ideas when you have tried nothing.

Let me know how your experiments get on.

Why I Hate Story Points

Story points, everybody’s favorite scrum activity. I understand they are meant to be used to help size stories. What usually happens is they are used to determine a team’s velocity.

A sprint goal suddenly becomes lets get 20 story points done this sprint, not let’s deliver stories that have business value.

Also what happens to unknown work that ends up needing to be done, but wasn’t pointed? Well it still has to be done, but if you are judging a team on only story points, then they won’t get any credit for it. So maybe the team failed the sprint goal as they only got 10 points done, but in reality 10 stories only 2 of which had been pointed. Those 8 stories were totally unexpected work, we all know that happens from time to time.

So the standard system seems to be, backlog grooming in which planning poker happens, and stories all get sized by a guess.
A sprint is then planned on how many story points we can do. Where this falls apart is it is nearly impossible to guess how long a story will take from just reading some acceptance criteria.

So what’s my solution? Well in the past I have talked about specification by example as a means to split stories, but where does this fit in a Scrum world?

Well how about in your backlog grooming sessions, instead of just reading the acceptance criteria and voting, use examples.
By using examples here, we can usually see how big or small a story is, the idea being to get a story done in close to a week. So the rule of thumb is usually 4 or 5 examples per story.

Maybe you get a story that has 10 examples, well we can split it here. Now we have two stories in the backlog ready to go. If for some reason some managers still need story points, grand we can just make sure all stories are roughly the same size. If each story has roughly 4 examples then pick your favorite number, 3 for example. All stories are then 3 or smaller.

The idea being to focus on delivering the value of story and not wasting time trying to guess points. Adding up the amount of time spent guessing these numbers will show you how much time we are wasting on this exercise. It reminded me of this Dilbert cartoon.


Eventually your team will get really really good at sizing stories using examples and since all the stories are 3 points anyway, points will fall away.

In a previous blog I talked about the three amigos and discuss and distill. This is basically moving the discuss part of the 3 amigos into backlog grooming to help split stories. You can still keep the 3 amigos lanes on your board, as we can still use the examples as test cases, and here we can double check and make sure everyone understands everything before starting work.

OK you might ask me, well how do I measure my team’s velocity? Well you can measure the cycle time to done.

Say a new feature has 10 stories in it, and these ten stories have been groomed using specification by example. We can then say that each story should roughly take a week. Then the feature will be ready to go in roughly 10 weeks.

By getting better at our story sizing (which happens with practice) we can become predictable instead of trying to guess how long something will take.

Give it a go and let me know how you get on.