From Anywhere

We work remotely from all over the world. When we need to get together, we use our office in Toronto, Canada or Lenexa, Kansas.

Chat and Hangout

We all work from 9 am EST until 5 pm EST no matter where we are to maximize our communication. All conversations happen over HipChat in open rooms and video conferences via Google Hangouts.


Once up and running, everyone joins their team’s Scrum stand up for a quick update on the goals for the day and any blocks the team might be facing.

Scrum of Scrums

At 10 am each team’s Scrum Master joins the Scrum of Scrums Hangout for a quick cross-team update on their progress and any blocks that they are facing that they need help with. Generally, by 10:15 am it’s a wrap and the entire company is in synch for the day.

Measuring and Learning – Retrospection

Each team retrospects on how they are doing once per week. They measure their happiness, the team’s velocity and if they are running an epic, what we call a sizable project, how they are doing with its delivery date. They also come up with one improvement that they will make this week. We always improve how we work. A summary of their retrospection is shared with all teams in HipChat so that we can learn from each other.

Meta Scrum

To keep each other in the loop with our epic progress, the Product Owners from each team meet every week at the Meta Scrum. There, they share their team’s key performance indicator results, what their epics are costing, if they are on track, as well as costings and schedules for new epics that they want to start. The meetings are open, and everyone is invited to attend and observe, and the meeting is video recorded and shared with all so that anyone who can’t attend but wants to follow, can at their leisure.

Customer Day

We want everyone to know our customers and their pain points. When new people join, regardless of what roles they hold, they spend their first two weeks supporting customers and then one day in support each quarter after that. We have one day every quarter supporting customers no matter what role we hold to make sure that we are current and empathetic with what our customers want.

Quarterly Goal Setting

Once a quarter, we open a Google Doc and create a structured agenda to review where we are going, and we invite everyone from the company in to contribute. There can be a dozen or more people all adding their thoughts at the same time. Crazy, but it works! It takes about a week but by the end of it every team knows how they did last quarter and what they need to get done this quarter.


Sometimes we can have a big problem, what we call an escalated issue, and when this happens, we quickly pull together those that are best equipped to help and all other priorities that they had are put aside until the issue is resolved.

Making the Right Thing – Jobs to be Done

It is a common understanding that software development has a pretty horrible success rate. Most projects fail and most of the time the blame falls on development, either directly or by implication. This is wrong. Software projects fail because software projects build the wrong thing. They build the wrong thing because someone comes up with the wrong stuff to build that doesn’t deliver on the real job it was hired to do. “Wrong” is typically based on someone’s idea of what is needed, this idea is not data driven or user-centric, and, or, the scope of the project is of some massive and complex scale that won’t be realized for months or years. Everything but the kitchen sink is piled onto the idea, all of which is either not described thoroughly, or is over-described and you can’t see the forest for the trees. How can software development succeed when the start of the development cycle begins with requirements that doom it to fail before it has even begun?

Successful software begins with actually setting out to build the right thing and making sure that it is described in such a way that it is clearly understood by those who will construct it, and, that it is of the smallest scale possible that will result in a shippable, and testable iteration. In other words, a very small step is clearly described and it has a real purpose and it has a measurable criteria to validate if it works. And once shipped the iteration is closely tested to determine if it achieved what it is supposed to, and the lessons learned from the iteration, whether successful or not, are applied to the next iteration. And so on, until the software is complete. Always learning, and getting better with each iteration made. Build, measure, learn.

How do you do this? How do you make sure that you are building what matters? Everything starts with a problem that we are hired to solve, a job that needs to be done. Something is needed to solve some problem that someone faces. And the problem is the source of the issue, the cause, not an effect. To get to the cause, you have to continuously ask WHY? The Toyota 5 Why’s.

For example:

  • I need new shoes. Why?
  • My shoes are not comfortable. Why?
  • My feet hurt after a couple of hours of walking. Why?
  • All shoes hurt my feet after a couple of hours. Why?
  • There must be something wrong with my feet. Why?
  • I have a problem with my feet.

We could very easily have started out by saying that the problem to be solved is “I need new shoes.” But after digging further, we discover that the reason I need new shoes is because my feet hurt, but, my feet hurt in all shoes that I wear, which finally leads to the problem to be solved of “I have a problem with my feet.” We almost bought new shoes, and they would have never fixed the problem.

If that’s the problem to be solved how will we know that we succeeded in fixing that problem? How do we measure success? It is very common to describe what we think needs to be done to fix a problem as the measure of success, which in this situation it could be “Get Orthotics from Doctor”. But this isn’t a measure of success. It is a task that we will do that we think will solve the problem. The true measure of success in this situation is that “a 2-hour walk doesn’t hurt my feet”.

At this point, it is tempting to say that we’re done. We have a problem to solve, we put it through the five why’s and we know the root cause of the problem, we know how to validate it and we know what we must do to solve that problem. But… how badly could we screw this up if we try to solve this problem? Could we make it worse? What happens if we don’t solve it? Does solving the problem matter to us that much? Do we have bigger problems that we should be solving? And last, but definitely not least, what is it going to cost to solve this? Could I put those resources to better use elsewhere?

How badly could I screw this up? “I live in the arctic circle and the only medical professional available to me is a dentist, but she says she knows feet and we could try experimenting with a surgery she saw on a YouTube video.” I think we could really screw this up.

What happens if I don’t solve this problem? “Nothing really. I am really lazy and out of shape, and it is rare that I go for a 2-hour walk and the only time my feet hurt is when I do that.”

What’s it going to cost? “Well I don’t have insurance and the YouTube surgery will cost $10,000. And now that I think of it, it might be better if I joined the arctic circle gym (they have a one month free trial) and saw a nutritionist (a neighbour next door who charges $25 per session) and lost some weight, I am 100lbs over-weight and in terrible shape, which now that I think further about this it could be the reason my feet hurt, and in general why I feel terrible all of the time.”

Now here is where it gets interesting. We originally thought the problem was we needed new shoes, five why’s lead us to sore feet, and that we would visit a doctor and get them to fix it. But, further examination of the risks, benefits, and costs clearly shows that we might have missed the root problem that even the five whys didn’t uncover. This circular analysis is what leads to true discovery of the underlying cause and motivations.

Problem > 5 Why’s > Validation > Risk Of Solving > What Happens If Not Solved > Cost, and back again we go until we get to the underlying problem or motivation. The true job to be done which is typically described as:

“When {situation}. I want to {motivation}. So I can {outcome}.”

When {I am walking}. I want to {be comfortable}. So I can {walk for two consecutive hours without pain}.

Given that our hypothesis is that we can solve this job to be done by getting in shape and losing weight and knowing that this is only a hypothesis we need to manage risk by taking small iterative steps and testing the hypothesis at each step to either discard it, or improve upon it.

With this in mind the sub-jobs to be done are:

  • When {the gym opens tomorrow I will meet with their Membership Director}. I want to {try a gym membership for one month}. So I can {see if I will stick with an exercise program for the entire month}.
  • When {I come home from work I will meet my neighbour the nutritionist}. I want to {get my first meal plan}. So I can {see if I have the discipline to stick with her prescribed diet for one week}.
  • When {I am at the gym every second day}. I want to {do cardio and free weights}. So that I {can improve my circulation, stamina and strength to comfortably walk a little further each week}.
  • When {I visit the nutritionist once per week}. I want to {review my food log to learn about what to eat and not eat}. So that I {lose five pounds per week}.

Each of the jobs to be done above are iterative. Each has an outcome to be achieved in a very short period of time with little to no catastrophic risk if it doesn’t work. And each iterative validation of the job gives us further data and experience to continue to define what needs to be done to achieve our overall goal of being able to walk comfortably for two hours. We won’t start something and wait six months to see if it works. We are going to take very small steps towards our goal and measure and learn, then adjust, as we go.

Further, we can ask two more questions. Is the job that I am going to do over-serving? Am I throwing too much at the problem and risk lowering my return on investment as the law of diminishing returns has kicked in? Or worst, am I overly complicating the solution and risk losing the user because they can’t figure it out? Or I have to charge more than it is worth to the user to cover the cost of my over indulgences and as such they can’t afford it? If we were over serving our overweight test subject may have considered a job to be done of:

  • When {I come home from work I will meet my neighbour the nutritionist}. I want to {get signed up to have her personal chef prepare all of my meals}. So I {don’t have to prepare my healthy meals}.

The above job to be done would work but it would increase the cost of the weekly nutritionist by at least a factor of 10 or more, and very possibly our user would stop using the service because they will find they can’t afford it in time. We are over-serving. Pun intended.

The second question we can ask is am I under serving? Our fictional user may have only considered the job to be done of going to the gym and never addressed the other side of the problem. The poor food choices he is making. And as we all know you can’t exercise your way out of a weight problem. So, in this case, we would be under-serving, and as such, the problem to be solved would never get solved, and in time we will lose our user.

Given the above, let’s do the risk analysis on the jobs to be done once again:

  • How badly could we screw this up? “As long as I start exercising slowly and don’t do a fad diet of just eating celery there is no health risk.”
  • What happens if I don’t do this? “I could have a heart attack or give myself diabetes, and I definitely won’t be able to walk comfortably.”
  • What’s it cost? “nothing for the free one-month gym trial and then $100 per month after that and $25 for each nutrition session, and I can stop at any time. All is well within my budget, and I am not giving anything else up to do this.”

Are we over or under serving? It seems like we are doing just enough to get the job done and we will monitor our results as we go to make sure that this proves correct.

We started by going out to buy a pair of shoes that we thought would make us feel better. We ended up joining a gym and starting a nutrition program for about the cost of the shoes we were going to buy. And, along with the way we avoided having a dentist operate on our feet.

This process is slow, tedious, and requires that you rip up what you thought was the ideal plan multiple times, but in the end, you have truly come up with meaningful work that is absolutely ready to be acted upon. All of this work happens before a single 0 and 1 are brought together to create the software that you think you need. This is how you build successful software. To many software projects are buying shoes or providing unqualified and expensive elective surgery.

Every software project that is undertaken must have a well thought out job to be done, that has been tested with five why’s, the risk of what could go wrong has been considered versus the tradeoff of not doing anything, the cost benefit analysis has been done and weighed against all other competing priorities, and we tested the jobs to be done to make sure that they are not under serving and as such will never solve the problem, or overserving, making the solution too complicated and expensive. And most importantly a quantifiable and measurable outcome for the software is known and stated, and that software can be delivered in preferably weekly or less iterations, and each iteration is tested and measured against that outcome, the results studied, and the lessons learned and applied to the next iteration.

And to further mitigate risk, no single task, or as we call them “card” within the project can take longer than two to three days before being delivered and validated. And, to make sure that every card is completely ready it should have a well defined job to be done ;“When {situation}. I want to {motivation}. So I can {outcome}.”, or at the very least, refer directly to a parent job to be done that described the situation, motivation, and outcome and it can be used to validate this card when shipped.

That is how you have absolutely ready ready backlog for software development, and that backlog is truly meaningful work that will deliver value to the end user who is hiring it to perform the job they need done. And… one last rule. You have at least two sprints of ready ready backlog that is good to go but no more than four sprints. Your team may just surprise you and kill two sprints in one, and you have nothing in the queue and are scrambling. Why no more than four sprints? Because it is too much inventory and if you are learning from every card you ship you might, and should, change your mind often as to what comes next and how it should be done.

Quick recap:

  • Have a clear job to be done; When {situation}. I want to {motivation}. So I can {outcome}.
  • 5 Why’s to discover the underlying problem and motivation.
  • How badly could we screw this up? Can we deliver and validate in 3 day or less iterations?
  • What happens if we don’t do it?
  • What’s it cost?
  • What’s the return on that cost?
  • Are there better places to spend this money?
  • Are we over serving?
  • Are we under serving?
  • Have at least two sprints of ready backlog, but not more than four.

No Multi-Tasking – Singular Focus

To produce the best possible solution in the shortest period of time, we have to have singular focus on the work at hand. Every time we pull a knowledge worker out of flow and away from their singular task it costs at least forty-five minutes for them to return to the level of productivity that they left off at. Every distraction. Every time.

Every card in addition to the card in motion on the Scrum board, is a source of distraction. This includes cards that are sitting in blocked as nothing in blocked remains quiet for long. There are follow-up questions and on-going discussions to try and clear that blocked card. Blocked cards are noisy.

There are cards up for pre-validation, and there are always clarifying questions to be asked on those cards. More distractions.

There are the cards that are in play with the other members of the team and their questions and pull request peer reviews. More distractions.

And then you have the rest of the company. Support related questions that need to be asked of the developer who created the product. Product Owner questions and epic planning. Quick meetings to review a new issue. And then just the general administration questions and all of the other things that it takes to run a business.

From the list above it is pretty easy to hypothesize that there is likely eight distractions or more per day. Assuming that falling out of flow takes forty-five minutes to return to it and that non-flow time is slower by many factors than flow time, that means that out of an eight hour day you could be dealing with six very unproductive hours. OUCH.

How do you beat this? How do we create the ideal creative environment in which to work. A non-interrupt environment.

Make all meetings as short as possible and have them at the start or end of the day and wherever possible back-to-back. Don’t scatter the interruptions across the day.

Never have more than two cards in play per team member across the active board, which includes pre-validation and blocked. If you exceed this work in process threshold, have the team swarm to clear the cards. Don’t add anything else into the mix until you drop well below your threshold.

And, unless something is escalated don’t interrupt your developers. Queue cards for them in the backlog and let them pick up the card when they close their current work. And ideally, have developers on the same team swarm on a card. If four developers are working on the same card, you eliminate four distractions. They are all having the same discussions, about the same topic, and building and contributing to the same outcome.

Measure Twice, Ship Once – Pre-Validation

If we have at least two weeks of ready ready backlog of meaningful work to create and we have vetted that backlog within the last couple of weeks, why should we validate it one more time? Ideally, you are in a continuous deployment cycle of build, measure and learn with learning and feedback happening daily. And this fast feedback loop is allowing you to optimize your plan as it unfolds. This means that what was assumed to be correct two weeks ago may be wrong today, or done differently today, and that the backlog that is only a week old may no longer be right. To make sure that nothing has changed or been learned that could invalidate the assumptions for a card in the backlog the person who picks up a card to work on should at the same time grab their next card, make sure they understand it completely and that it makes sense to them, and they should add to the card how they are going to address the problem. What their implementation strategy will be. Once confirmed and updated the card is put it up to their team to verify their understanding and implementation plan. This pre-validation of just in time backlog inventory should be happening on a constant basis to confirm that the work to done is still meaningful.

Ship your current card > Pick the card that you pre-validated last > Pick another card from the backlog and queue it for pre-validation > And repeat.

A Scrum Board is a Shop Floor

An efficient and safe shop has nothing on the floor but inventory that is immediately needed and the tools necessary to process it. Anything else gets in the way and slows the process down while increasing the chance of quality problems (stale inventory), and in some circumstances, it makes the shop a dangerous place to be. A Scrum Board is absolutely no different. The only work on the board should be work that is actionable. Everything else is clutter. All work on the board has to have true meaning and purpose to what you are delivering; it isn’t a repository for to do lists, or might do someday backlog, all of that is noise. Get it off the board. You won’t be able to see the forest for the trees to manage your Scrum.

Continuous Learning – Validation

All epics, and cards that stand alone of epics must be validated to determine if they achieved the outcome that they were intended to. Did they produce the measure of success that we wanted and ideally this measure of success is defined in terms of one of our key performance indicators. Did we move the needle for that KPI in the direction, and the distance, that we said it would go?

Failure to achieve the measure of success that we wanted isn’t a problem. Failure to take the time to learn from the validation and determine next steps to continually improve is. No validation means we have no build, measure, learn cycle, which means we are repeating the same old every day and not improving. Validation takes work, it needs to have points and it needs to be queued in the backlog. It is not an afterthought that we quickly discuss during retrospection. It is the most valuable work that we can do. And the results of it can’t be acknowledged and forgotten. The lessons learned must be queued as ready backlog for the next or current epics. If there are no cards on the board that meet this criteria then we are not continuously learning and improving, we are just wandering.

Hidden Forces Conspiring Against You

The worst problem that a team can have is non-visible work. Work that is being done by team members that isn’t on the Scrum Board. This rogue work sucks the capacity out of the team. These hidden distractions will reduce focus and velocity and this invisible work has no validation and learning component to it. It is a rogue wandering to do list of some sort or other. And, the team, and the rest of the company for that matter have no visibility on the work which means that someone, somewhere, is going to be in for a surprise, of some sort. NO SURPRISES. Either kick the person who is serving other requirements off the team so that they can join whatever team has this mandate, or, make them a chicken so that they can observe but not distract, or, bring them back on as a pig and get visibility and meaning to that rogue work.

Building The Farm Team – Decision Making

To build leadership and decision-making skills and to encourage the growth and participation of everyone we want to push every decision down. Not up. Further, we don’t want any decisions being made that are arbitrary and done in private, regardless of where you are at in the organization, and if fairly junior we don’t want you shouldering the burden on your own, and possibly the company suffering the consequences of your inexperience. For all of these reasons every decision maker should:

  • Ask themselves if there is someone on their team that could learn from making this decision more so than they will, and if so, they pass the decision to them,
  • and regardless of who is deciding, the decision maker must seek advice from whom they deem to have more experience on the subject before they make their decision. No advice. No decision is made. This applies to everyone. No one should ever be surprised that a decision was singularly made with no advice.

The company stands behind the decision maker, no second guessing until the outcome of the decision is proven wrong, if ever. And of course, decisions won’t be right all of the time. Which is fine. We can learn and adjust as we go. What isn’t fine are surprises – decisions made in private with no advice sought or given. Extrapolated from Bakkes Top 10.