I think this is a software development question, for the persons involved in software development. In software development, they have these kinds of steps of how the work gets done.

And if you're not in software, you might also have some kind of workflow. The work gets done in a particular sequence and in software development, the prevailing wisdom before was that you talk to a customer, and you find out what she's looking for. You might do some analysis on that.

You might do some design, could be architectural design, could be UX research, could be some user interface design, and then maybe some tests would be written and if people are using driven development, they'd write some tests, even though no code has been created yet to pass those tests, the tests would all fail and then they'd write code to pass the tests.

Once the code passed the test, they go back and tidy it up. It's like three hats really, you're writing the test, then you'd try writing code to pass the test. And then you're refactoring, it's known as test-driven development, some people don't do test-driven development in software.

They got kind of a manual approach, a very old-fashioned approach where the developers do the code, write the code, and then maybe the developers do some testing. I hope they do. I hope they're not just throwing stuff over the wall. And then some tester people check that it's all working properly.

To give waterfall some credit, the traditional approach to doing this kind of stuff, you just did it once. You did it twice actually cause you did it once and it didn't work and then you do it again, you could do it twice.

'Done' doesn't just mean met the acceptance criteria

But when you have scrum, for example, you need to deliver an increment every single sprint and that increment needs to be done. So the team needs to have a thing called a definition of done and done does not mean met the acceptance criteria. Doesn't just mean that, there should be other considerations as well.

So there's the definition of done. I don't want to really call it the checklist for how we do things around here, because that might be a bit too process-oriented and maybe a bit too detailed. There's a nice balance between trust and being clear what we need to do, but as such the team would know what they need to do for something to be called on at the end of the sprint so they can show something at the end of the sprint. That's all fine. But what do the developers do in the last week of the sprint? It feels like a loaded question because the assumption that I'm reading from the question is that the developers, in your case, write the code, and then they hand it off to some people who do some testing.

And then those people are busy doing testing and probably raising bugs in the stuff that you created. And so you should be off doing something else. You should run onto the next thing. And it reminds me of a chap that I really respect. His name is Brendan Vochkow from, I think he's from Tennessee, that area of United States.

And he was on the stage there a few years ago at a conference. I think it was agile Indy, Indianapolis. And gave an example of the kind of behavior that you want to see in the team. And he said basically, let's say I'm a developer. The behavior that Brendan looks for is when the developer is 'finished' their piece of work that developer would stick up her hand and say, who's ready to take this away from me.

Collaboration is key

I want to take on the next piece of work. Who's ready to take this away from me. That was really smart, what Brendan said there, because it could be tempting for the developer to move on to the next thing. The best time to actually iron out any misunderstandings or any bugs that there might be and so on is you've just worked on it and so before you context switch onto something else, maybe you need to collaborate with the tester, so making sure that everything's going okay, and that you're working on it together. So you don't move on to the next thing maybe you help the person that you handed all the work to.

You shouldn't be handing work anywhere, you should be collaborating

You shouldn't be handing work anywhere, you should be collaborating, but you just work together and try to understand that together. And that's what we expect in scrum. We expect you to collaborate and not run onto your next thing. There are no roles in scrum. We do have accountabilities, but you don't have like sub roles if you like.

Accountabilities in scrum:

So really what we'd be encouraging is what Brendan would have encouraged when he was on the stage in Indianapolis, which is when you have something and you feel like someone needs to take it away from you within the team, or you want to collaborate with someone on the team to get it to done. You stick up your hand and say, who's ready to take this away from me. And who's ready to collaborate with me to try and get this thing to done. That's what I would recommend. That would be my answer to that question. Also, there's lots of other things you could be doing. Product backlog management in scrum and a really good strong team would be delegated to the developers.

'Developer' in scrum means anyone doing the work regardless of whether you're a tester, analyst or UX or whatever you are. And so product backlog refinement in a really good scrum team would be delegated to the developers and the developers would be clarifying the problems to be solved with the customers and end-users, maybe you can be looking at what's coming up next.

Do we understand that? Do we have a common understanding? You might have one person on the team who has a really good understanding of what that work is, but actually, do they really understand it? When you hear people having an argument, are they arguing about the same thing?

First of all, product backlog refinement, are we talking about the same thing? Do we understand what the opportunity is, what the problem is to be solved. So that'd be my little tip.

What do developers do in the last week of the sprint? They're part of the scrum team, they work to get us to the sprint goal, they collaborate, you don't just hand that off to someone else. You pause for someone to collaborate with you to get that work to done and failing that, there's lots of product backlog refinement that can be done. You could even be writing tests for the next sprint, actually, you could be getting ready.

You don't arrive in the next sprint with your hands in your pockets. So maybe that's refinement as well, having the test written so that when you have a chat then with the customers and users and say, if we do these, if these tests pass, is that what you're looking for? And if they say yes, then, you're in business.

That's my suggestion. Thank you so much.