Done is Done

Episode 8

March 24, 2011

18:36

TBD

tbd

The Agile Weekly Crew discuss what it means to be done with a story.

Episode Notes

Clayton Lengel-Zigich and Derek Neighbors talk about what it means to be done with a story.

What is done?

Works on my machine.

Real data.

Workflow verification.

UI/UX completeness.

Responsibilities.

Whole product thinking.

Planning Meetings & Acceptance Criteria

Transcript

Derek Neighbors:  Welcome to another Scrumcast. I’m Derek Neighbors.

Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich.

Derek:  Today we want to talk about something that a lot of teams struggle with, and that’s the concept of “Done is done”. I guess to start off with Clayton, what do we mean when we say “Done is done.”?

Clayton:  That’s a hard one to sum up in one phrase. There’re a lot of things that go into it, but I would say that it’s basically, if you want to go with more of a book answer, you want to delivery potentially shippable software. That’s an easy definition for that. Obviously you need to expand on it.

Derek:  There’re a lot of exceptions depending on the size of your team, and what team functionality is. You might draw a different line in the sand of what is done. Meaning, maybe I’ve got a Q and A team that is entirely separate from my team so done is done for. My team would be making sure that we’ve done A, B and C, and we’ve handed it off to the Q and A team, and when we’ve handed it off to the Q and A team it’s thereby done.

For today’s conversation we want to talk about “Done is done,”, is that a single team is responsible for the entire chain all the way to deployment. What does it mean to be done in order to deploy? What we see a lot is a developer will say “Oh, this is done.”

“Mrs. Product Owner, it’s out there. It’s totally ready to go. Go check it out.”, and a product owner comes in and they go to the website and say “I don’t see how to…Where do I get to this”? “Oh. Well, you have to enter like this super magic URL to get there.” “OK.” They go in and they pull out some data, and they press a button, and boom the software blows up, and then there’s a defect.

Obviously not done, but thought it was done. Today maybe let’s go over what are some things that hold developers back from being able to give product owners features that are actually done the first time.

Clayton:  Take your maybe less savvy, what you want to call it, developer not doing any automated testing. Those people in my experience…I got into the industry. I’m going to do some feature, and I’m going to spend a lot of time manually going through their entire process. I know how to make a testing, but one way that people go wrong with that is they choose the golden paths. It’s a phrase I’ve heard before.

I know that I need to fill in on these fields, and I know that if I put a two highway number in this field, it doesn’t going to work, so I normally put ten in that field. I know that I need to press the submit button, and I know that when I get to the next page, there’s a bunch of [indecipherable 03:18] , but there’s this little link down here. If I click on that, “OK, sweep, it’s done.”

They’re just lazy in that regard. They don’t think about it in terms of how someone actually is going to use it. I would say for the more savvy developer, that’s actually writing automated test.

It’s really easy to do the same thing when you’re testing. You have different test cases, but you still do the golden path for a lot of those. You don’t think to put in much crazy test cases, maybe you shouldn’t. You don’t necessarily wanting to catch every single edge case, but it’s still easy to do that.

Also, you get the false sense of security of while this feature is tested when you actually maybe deployed of that. The product owner is looking at it. They don’t do the same except that you did in your test obviously. You get the ball of the software.

Derek:  I definitely think that that’s one of the biggest things that…at least in web development. I don’t even say we see this slot in mobile development. It’s not actually deploying to target platforms and do the testing.

It’s the classic, “Hey! This works in my environment. Everything is great,” the works on my machine syndrome, so going along, blistering along, everything is great, and I handed off, and the product owner complaints that it just doesn’t function at all. You scratch your head and say, “How the hell? I’ve worked on this for four hours, and I’ve not seen anything remotely close to what you’re talking about.” You’re completely crazy.

You go to the diversion of the operating system on the mobile device or their particular mobile device where you go to their web browser and you go, “Oh, oh, oh. I forget about that dependency or whatever.” That is probably one of the lowest hanging pieces of fruit that developers can do to get a better done is done and that is, make sure that you’re deploying to a solid target platform.

If it’s multiple platforms, we see this as mobile, if you have to support multiple versions of the operating system or multiple versions of a browser, they are actually doing deployment and a test with those and before you ask that product owner, do the same thing. Because invariably, they will pick the one platform that you did not choose to look at, in order to do their testing.

Clayton:  Going along with that would be appropriate data set. It’s really easy when you’re developing some feature, and you’ve got your two dummy users in your system, and everything’s kosher. Then you’ve got to deploy it to the target platform, or the staging server, even in production. Everything goes great when I looked at it, all the functionality works, but it’s unusable.

A big part of done is done, is that from beginning to end of the whole feature, it needs to be usable in a reasonable way. Not something that requires tricks, excessive waiting, or all those kind of things. You really have to be sensible in that regard.

Derek:  That’s a big part. Even automated testing sometimes even makes it worse, but regardless, it exists even without automated testing. That’s the whole sensible workflow chain. What does this feature look like from cradle to grave?

We get too hellbent on, “We’ve got these great regression tests, so when I go add this new piece of functionality, a feature that builds upon new feature, I’ve already tested the original feature. I’m testing the feature that I’m building that piggybacks on top of this feature, I don’t need to go walk through the visual workflow.”

In reality, the product owner gets to it, and they say, “I did this, and I did that, but there’s no way to get to this other thing short of having to go the long way around the fence.”

The other one I see a lot of times is missing roles. It works great as an admin, but as a guest it doesn’t work. It’s supposed to work because you’ve built this funky thing on. Making sure the UI and the UX are reasonable is a big part of making sure that things don’t come back.

Clayton:  A lot of that, the UI, UX stuff…A lot of developers probably put on their I’m‑a‑developer hat, and they don’t want to get into the front end or UX mentality. Even if you read some basic stuff about UX or information architecture, or whatever those people call themselves these days, even if you knew basic stuff about that, it’s really just a common sense thing.

I know common sense isn’t very common, but there’s a lot you can without really having to exert a lot of effort on your part while you’re developing the feature. Most of those things, in terms of the UX stuff especially, and the workflow, comes from communication with the product owner, and planning. That’s probably one of the biggest ones that prevent developers from delivering something that is actually what the product owner wanted.

Derek:  What I see a lot, especially with people who don’t have as much experience or don’t have confidence, is they’ll have a planning meeting with the product owner, they’ll get some reasonably good wireframe, UX, UI, the designer would get involved to do that.

They’ll go to start implementing the feature, and they’ll know the workflow is broken when they’re doing it. Instead of raising the red flag back up to the product owner, or to somebody else on the team who’s responsible for UX or UI, and saying, “This feels really clumsy. You’re asking me to select 100 items here, but if you try to select more than 5, it takes forever. Isn’t there a better way we can do it”?

A lot of times, developers shirk that responsibility, and say, “I’m not the designer, I’m not a UX guy. I’m just going to implement what was given to me, and what was discussed.” The first thing that happens is the product owner or the designer might even sign off and say, “Yeah, it looks great.” Then they give it to the first user who actually has to select 100 things out of that 1000, and goes, “This is the worst piece of software, I can’t use this.”

The developer instinct is, “I knew that.” If you knew that, you need to speak up. That’s a big part of it as well.

Clayton:  More often than not, you probably run into a situation where you don’t wireframes necessarily or lots of well thought out interface elements, and things like that.

When you get into that mentality, especially when people feel like they’re crunched for time,