What’s the difference between “Done” and it technically works on a developers desktop in Chrome?

October 16, 2020 4:42 am

One of the most common questions I get from our tech employees is:

What’s the difference between “done” and “it technically worked on a developer’s desktop in Chrome”?

So I thought this might be a great time to write a blog post about the meaning of “done” at Two Barrels.

So what is the definition of “done”?

“Done” is when the problem a customer, an employee, or the company needed solved has been solved. But is there really such a thing as “done”? or “Done, Done”? I question whether this state of things is accomplishable… When we take ownership of our products, are we ever satisfied with the product to just call it done and move on?

What is the definition of “It technically worked on a developer’s desktop in Chrome”?

That usually just means “I got my part done.”

That might sound like “done” to the person who says it, but to everyone else involved—the people who made the request and who need the problem solved—it sounds like “What you’ve asked me to do technically worked on my desktop in Chrome, so I’m going to disengage from the problem now and see what else I can check off my to-do list in the game of scrum.”

This is a common pitfall in the game of scrum. Scrum is a good way to plot out things to do and create well-defined goals to shoot for—and, sure, the clearer the path is from point A to B, the happier everyone is. But scrum isn’t so great at defining that broader, more ambiguous, but far more important definition of “done” that matters to customers, employees, and the company.

If quotes are your thing, maybe this Aristotle guy was onto something:

The whole is greater than the sum of its parts.

The parts that technically work on a developer’s desktop in Chrome are worth something, but they would be worth a whole heck of a lot more if the developer and other scrum teams from different skill sets came together with the common goal of getting something done.

Is this the tech workers fault?

Absolutely not! Big-picture thinkers tend to make horrible tech workers, just as I’d make a horrible tech worker if forced to zero in on a hard, complex problem that won’t work if it isn’t perfectly executed.

So what’s the answer?

It’s no use manipulating or punishing these Great Immovable Objects (tech workers).

I think the answer is focusing on solving the problem versus putting in an 8 hour day or finishing a sprint. People can easily get stuff to work in Chrome, but the real problem is how do we bring many segments of talented scrum groups together to actually solve the problem, not just make something work on developers desktop in Chrome.

Persistence, Patience, and Process are your only answers. We have to continually ask ourselves if what we’re working on is a solution or just more stuff we think we got “done”.

Some Frequently Asked Questions from Tech Workers in an attempt to call things done without solving an actual problem:

I am using a laptop, so if my work technically works on a developer’s laptop in Chrome, did I get my stuff done?

Nice try, but no. You still aren’t really done without solving the customer’s, employee’s, or company’s problem.

I use a mechanical keyboard and can’t hear what you’re saying, so am I exempt?

No. It still applies.

My work is harder than the work of the other skill sets, so why should I have to deal with the other scrum groups?

You may think your work is more important or more difficult than the work of others, but that doesn’t make a difference at Two Barrels. You could build a quantum computer and that still wouldn’t qualify as “done” if your work didn’t actually solve the customer’s, employee’s, or customer’s problem.

The other scrum teams don’t get it. Won’t they just slow me down and get in the way?

I understand that feeling. The truth, though, is that we’re all less competent by ourselves. We all benefit when we put our egos on the shelf, help others grow, and let others help us grow.

But the last person we tried this with quit after 6 months.

Yes, that’s an uber doozy. That one hurt. And it hurts every time. But we have to keep trying to work across groups and skill sets to get things done. We all know what it’s like to spend 6 months training someone only to discover they lack the skills we expected or don’t work well with others. But we can’t hold that against the next person we hire.

It’s a lot like bad reviews online. The reviewer probably ate 99 amazing meals to that 1-star review that just annihilates a business online, but the bad reviews sting because they are very few and far between. Most people we bring on will just naturally adapt and do awesome work.

Maybe Covid’s to blame?

As reasons go, this one’s as solid as any… but, no, you still have to work with other scrum groups to get the whole project done.

I think I’m underpaid.

This is a common feeling, too, but it also has a solution. We give raises twice a year. Focus on proving yourself and maintaining a stellar work ethic, and you’ll be rewarded.

I didn’t know we needed to take that step.

Well, why start at all if we don’t know the steps we need to take? We only know what to work on when we focus on solving the customer’s, employee’s, or company’s problems.

No one told me to do that!

This is where the importance of self-reflection comes in. Instead of pointing fingers, let’s strive to take ownership of our projects and start by understanding why we are doing this or that.

It’s the Scrummaster’s or the product owner’s fault.

These are always easy targets, but spreading blame won’t make us better at getting things done.

If we just had a better leader, our problems would go away.

I have found that you can’t hire your way out of a problem. All we’d do with that is tip the see saw one way and create other problems.

You said “done” is when I solve the customer’s, employee’s, or company’s problems. If I technically solved one of those people’s problems by simply making my to-do list technically work on my desktop in Chrome, does that count as being done?

This is a great question, but keep in mind that every task almost always still fits into a larger context. If a customer has a problem they need solved, there’s usually a related problem an employee or the company needs solved. If there’s an employee problem, there’s probably a related problem for the customers and the company. If there’s a company problem, it’s probably a problem for the customers and employees also. It’s kind of like Paper Rock Scissors. No matter which you pick there’s something else smashing this one.

So what is “not done”?

“Not done” is when your tasks are completed too late in the sprint for the rest of the scrum teams to do their part.

“Not done” is when your stuff technically works on your desktop in Chrome, but you launch without testing it or getting the appropriate feedback from other teams.

“Not done” is when your stuff is working on your desktop in Chrome but the real problem—the customer’s, employee’s, or company’s problem—hasn’t been solved because the other scrum teams and skill sets haven’t been brought together to holistically solve the real problem from different angles.

Again, what is “done”?

“Done” is when you have solved the customer’s, employee’s, or company’s problems.

Why should we all care?

Because, in the end, we’re all on the same team. When the different scrum teams with different skill sets work together, we make a better end product and achieve better results. Real problems get solved (instead of just technically working on a developer’s desktop in Chrome), we have a better chance of getting things right the first time, and we avoid the frustrating experience of needing to redo things while a project just drags on and on.

So how do we move forward?

Oh, and if you read this far: No one has ever asked me what’s the difference between “done” and “it technically works on a developer’s desktop in Chrome.”

Categorized in: