Over the last few episodes, I've been talking about Scrum, an agile framework. In this episode, I want to talk about the Definition of Done. The Definition of Done comes from the Increment description - the Increment being one of the Artifacts produced by Scrum. The Definition of Done is a way of coordinating the team and the entire organisation on what completed work looks like.
Or listen at:
Published: Wed, 03 Mar 2021 17:20:33 GMT
Links
Transcript
[00:00:35] Hello and welcome back to the Better ROI from Software Development podcast.
[00:00:40] Over the last few episodes, I've been talking about Scrum, an agile framework.
[00:00:45] In episode 73, I provided you a brief primer on scrum defining the Scrum Events, the Scrum Team and the Scrum Artifacts.
[00:00:56] In Episode 74, I talked about some of the theory and values behind Scrum.
[00:01:00] And in the last episode, episode 75, I talked about some of the common problems I can see with Scrum adoption.
[00:01:10] In this episode, I want to talk about the Definition of Done.
[00:01:16] The Definition of Done comes from the Increment description - Increment being one of the Artifacts produced by Scrum. The increment is effectively the working software produced during that spring, and as part of the definition, it defines the term "Definition of Done":
"The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done."
[00:02:51] So let's talk briefly about the benefits of having this Definition of Done. Think about it as a contract almost to say these things are what we will do as a team whenever we do any work.
[00:03:03] In it, you probably define quality gates - what we will accept as quality in the work that we're doing so that everybody's working to a similar standard. It helps to align everybody's understanding. We're clear on what "Done" means.
[00:03:20] Often we find that teams aren't that clear, even if they've been working together, as to what the word Done means.
[00:03:30] Some people consider it: "I've written the code. It's ready to text. That's my work done." And this is very much a traditional view from a development team.
[00:03:38] Other people consider the work Done when it's ready for release.
[00:03:43] Personally, I think it should go further than that, I'll talk about that in a few moments time.
[00:03:50] But defining it produces that contract that allows everybody to align and everybody to be clear on exactly what's going to be delivered as part of the Sprint and exactly how far along the delivery chain it is.
[00:04:06] It can also be a living definition. This is something the team produces (unless as an organisation, you have already defined what it means) and it can be improved over time.
[00:04:17] So maybe you start with a very light definition of what is considered Done. And then maybe improve it over time, providing more value by increasing its definition.
[00:04:30] Think about it as a charter in terms of the team agreeing to "this is what we are going to do for any work we produce".
[00:04:38] Let's talk about my personal preferences for the Definition of Done" - When the work developed by the team is actually in production, being used, being available for the customer or user who's meant to be having it.
[00:04:53] Many teams won't go that far and don't want to include production in their Definition of Done, they want to take it to be "ready" for production.
[00:05:05] This is normally a sign that there is some form of authorisation process outside of their control that stops them from being able to release into production without having to go to someone else to get that authority, that approval.
[00:05:22] And personally, I see that as a problem. Any time the team has to reach out of itself for anything, whether that's for skills or authority, that slows down the team, it slows down their effectiveness.
[00:05:37] I've seen teams work to a Definition of Done which takes up to being ready for release. And then it taking weeks, months before it's actually then released because they're waiting on approvals. At which point the team have moved on, they're working on something different. So if there's a problem, they can't remember what's happened.
[00:05:58] And they've also tied up investment, that investment in work for weeks, going nowhere until that software is in production and being used. You are not gaining any form of return on the investment you've made.
[00:06:13] So while a new team may not have "into production" as being part of their Definition of Done, certainly you should think about that as an aspirational goal over the course of their work.
[00:06:27] Also, within that Definition of Done, you should have defined quality metrics, you should make sure that there are defined levels of unit tests, of UAT tests, ideally these should be automated. But as a definition of them, you should be expressing that this work should be to that level and should be tested.
[00:06:49] Same with security, the Definition of done should make sure the team meet a level of security and they've validated that the software is secure and will not harm the organisation, the employees or the customers through a fault in security.
[00:07:08] This certainly is never going to be 100 percent true - because its almost impossible to make something 100 percent secure - but they should be making best efforts based on their capabilities and knowledge to make it as secure as possible.
[00:07:23] And this really should be part of producing that incremental work. Because it's very, very difficult to go back after you've produced it, and I'd add security afterwards. It should be included in that Definition of Done.
[00:07:39] I'd also include support documentation, any procedures that the team need to follow to make sure the software continues to work.
[00:07:50] Now, I'm not expecting reams upon reams and reams of documentation because I actually think that's a waste. But there should be enough there that the team as a whole know what to do if it goes wrong. And there should be enough there they should be able to introduce new members to the software to the Increment quickly.
[00:08:10] I expect the Definition of Done to include internal approvals. I expect any approvals to be part of the team. I don't expect it to go outside. Thus, the ability to go straight into production. So, as such, Done needs to make sure that any time that there needs to be any consultation that is included in that and done before it could possibly be released.
[00:08:35] In most cases, that should be at the team's discretion. Occasionally, they may need to make sure they do talk to a subject matter expert, maybe they need to talk to a lawyer, maybe they need to talk to an accountant, but we need to make sure those are part of those approvals if they are really required for specific pieces of work.
[00:08:57] And finally, that Definition of Done should have monitoring and ownership built in at the core, just getting it into production isn't enough.
[00:09:07] Certainly for me, if it's in production, it's done - but the team still need to make sure they're in a position to make sure it continues to work once it's in production.
[00:09:15] It should be the team's responsibility and ownership for the life of that software. They should continue to monitor it, maintain support it until it is decommissioned. It isn't about handing it off to another team to do that work. They should be responsible for it.
[00:09:34] They should be the people that get rung at 3:00 o'clock in the morning if it breaks.
[00:09:40] By having it in the Definition of Done, it makes sure the team knows they have ownership and responsibility for that software. Encourages them to make sure that the testing is accurate. It makes sure that everything is correct. Make sure the security is right. Make sure that their support documents are in place. Make sure that everything is aligned and is correct that it can be.
[00:10:00] Why? Because they don't want that run at 3:00 in the morning.
[00:10:06] If you're starting with a new team, don't take my preferences as the Definition of Dune, it's too big, it's too much.
[00:10:14] Rather, start small.
[00:10:17] In Coaching Agile Teams by Lyssa Adkins, she advises in almost every single situation, and she's right, "Take it to the team".
[00:10:28] It is up to the team to define the Definition of Done.
[00:10:30] And they should be confident in their ability to meet that Definition of Done.
[00:10:36] So if you're starting, they need to work with you to define that Definition. If anything, they should be bringing it to you and say this is our initial Definition. You can also challenge them and ask them to improve over time. But again, it's a challenge. It's up to them to accept any further changes to it - because they're the ones that have to be responsible for that work.
[00:11:00] So don't be afraid to start small and allow it to improve over time. Remember that experimental mindset, that minimum viable product, get it in, get it started and build on it over time. Then maybe one day you'll hit my high preference levels.
[00:11:20] In this episode, I've talked about the Definition of Done - a charter, a commitment of what and how the software should look when the team consider it is Done.
[00:11:36] Any time that software within the Sprint does not reach that category of Done, it isn't Done by Definition. Any work that reaches the end of a sprint and hasn't reached that bar is put back into the backlog.
[00:11:49] Maybe they work on it in the next sprint. Maybe they don't.
[00:11:53] That all comes down to the Sprint Review and the Sprint Planning; they may choose to leave it.
[00:12:01] And that's the important point about the Definition of Done, it is that bar to decide whether or not you are Done. If it doesn't reach it, then work goes back into the pile.
[00:12:11] And then decide whether or not, with the Product Owner and the Team, as part of the group planning whether or not it's important enough to finish in the next Sprint - or whether it's something that maybe come back to later - or maybe its no longer important.
[00:12:27] I talked about the Definition of Done in terms of my preferences. And again, they should be fairly high standards and probably not appropriate for a starting team.
[00:12:38] For starting team, I'd advise you to start it small - start with the basics and build on - making sure that quickly, you get to a level at least of quality, of making sure that it will build, make sure it works as expected.
[00:12:51] You can then start introducing more and more acceptances to that Definition of Done - remember, working with the team, because the team need to be comfortable and confident that they can achieve that level of Done.
[00:13:06] Thank you for listening and look forward to speaking to you again next week.