Simon Reason - Unleashing the power of your definition of done
•Download as PPTX, PDF•
2 likes•587 views
Scrum Australia 2016
Recommended
Recommended
More Related Content
More from Scrum Australia Pty Ltd
More from Scrum Australia Pty Ltd (20)
Recently uploaded
Recently uploaded (20)
Simon Reason - Unleashing the power of your definition of done
- 1. Section divider, over two lines Tagline or document title
- 2. Section divider, over two lines Tagline or document title
- 3. Section divider, over two lines Tagline or document title
- 4. Section divider, over two lines Tagline or document title
- 5. Section divider, over two lines Tagline or document title
- 6. Section divider, over two lines Tagline or document title
- 7. Section divider, over two lines Tagline or document title
- 8. Section divider, over two lines Tagline or document title
- 9. Section divider, over two lines Tagline or document title
- 10. Section divider, over two lines Tagline or document title
- 11. Section divider, over two lines Tagline or document title
- 12. Section divider, over two lines Tagline or document title
- 13. Section divider, over two lines Tagline or document title
- 14. Section divider, over two lines Tagline or document title
- 15. Section divider, over two lines Tagline or document title
- 16. Section divider, over two lines Tagline or document title
- 17. Section divider, over two lines Tagline or document title
- 18. Section divider, over two lines Tagline or document title
- 19. Section divider, over two lines Tagline or document title
- 20. Section divider, over two lines Tagline or document title
- 21. Section divider, over two lines Tagline or document title
- 22. Section divider, over two lines Tagline or document title
- 23. Section divider, over two lines Tagline or document title
- 24. Section divider, over two lines Tagline or document title
- 25. Section divider, over two lines Tagline or document title
- 26. Section divider, over two lines Tagline or document title
Editor's Notes
- Last page of Scrum Guide. Not only higher quality We deliver the right thing to our customers – we start to satisfy our customer We become more adaptable - We can welcome change requirements We deliver frequently We start to collaborate …. We start to being more Agile ….. In fact expanding, refining, elaborating DoD does more than just gaining higher quality, it starts to drive the level of Scrum maturity through an organization. This is the power – we just need to unleash it!
- When was last time you updated your Definition of Done? Standing….. Stand Sit if you don’t have a Definition of Done Sit down if you have one but you don’t know where it is Sit if you have never updated since you first created it Stay standing if you have updated more than 3 times in last 6 months Stay standing if you visit your Definition of Done every Sprint Stay standing if you have a perfect Definition of Done and have potentially releasable increments at the end of every sprint Stay standing if you have never had a production incident? If anybody still standing, Then why are you here?! Are we not mature?? If we don’t update it what happens? We may still be getting higher quality by continuous improvements But if we are not visiting our Definition of Done on a regular basis it will be hard to unleash it. We will not be able to harness its power to help us achieve higher quality, to help us become more agile, to help us drive the level of Scrum maturity through our organization.
- So our Definition of Done is all about Transparency So a Card on the Scrum Board is in the Done column, what does it mean? So when we ask are we Done everybody knows what it means It means, all code is checked in, all unit tests are successful, all functional tests are successful, the functionality is deployed to… dev?test?a production deployment slot? It doesn’t matter as long as we are transparent. So when we walk up to the right hand side of the scrum board we all know what Done means and if that is deployed to a Dev environment so be it, we know and we can start to make decisions. But if we didn’t know that, I might think that it means that it is in our prod environment and start to make decisions on when to turn it on. If we are not transparent about what “Done” means then we potentially come up with flawed decisions. This is why we need the Definition of Done and we need to adhere to it, so everybody knows what it means when that card is in the right hand column on the Scrum board.
- Let’s just cut this confusion out! What’s the DoD for that Product Backlog Item? (User Story) Question Ok, what is the answer though? At any point in time the Definition of Done for any stories we are working will be common for all. The Definition of Done corresponds to all Stories for a Product or system. No matter who we ask Acceptance criteria is all about building the right thing. Definition of Done comes in when we want to know, have we built it right. And is everything else that was done, still done. We haven't broken anything. While the Definition of Done usually applies to all items in the Product Backlog, Acceptance Criteria are applicable to a specific Product Backlog Item For a product backlog item to be complete, both the Definition of Done and Acceptance Criteria must be met. In fact typically a Definition of Done will have a statement about Acceptance Criteria, so for a Product Backlog Item to be complete it must meet the Definition of Done.
- So now we know when We say “We are done” everybody knows what it means. Need to challenge every day of the Sprint, is the card Done? And how do we get to Done? Not only during the Sprint, but during the Sprint planning. When should we create out tests, when is the UI experience validated? It’s used Daily – if not we might be setting ourselves up for failure. There’s a bigger a problem, however, Even if we do use our Definition of Done every day, and everything has been completed according to our Definition of Done, we may not be able to potentially release the product increment. We will not be able to hit the button. We are Done, but not Done, Done, Done
- So when we ask “Is it Done”, we expect an answer, “Yes it’s Done, Done” And what we mean here is not “It’s Done, but…” or “It’s Done, other than….” Or even “Well it’s Done sort of…..” What we want is “It’s Done, Done” which means that it is so Done, that there is no other phrase to add after Done err, except Done! And for good measure let’s add a third Done! Because if you add a phrase other than Done after Done, you’re modifying what Done means and that won’t do at all, since nobody will know what Done actually means Done, Done, Done
- So what does Done, Done look like? A perfect Definition of Done includes everything that the organization has to do to deliver the right product to customers. What is yours? Chat to neighbour Shout them out!! Why is the Perfect Definition of Done important? It’s a target that we need to move towards… Will we ever get there, what’s the progression.
- So we have our perfect Definition of Done, a nice long list But not everybody is able to make it?
- So we have our perfect and our Definition of Done. Our Definition of Done contains all the items we can do in a Sprint from the Perfect Definition of Done And what do we do? Remember that to potentially release the right product to our customers we need to do everything on the perfect Definition of Done. What do we do about those items we can’t do? Chat to your neighbour Worse case – we have integration/release/hardening sprints. Issues everyday – loosen our grip Better is we identify that we will always have work to do to be able to release, so we create items on our Backlog like support integration testing, and/or release. Identify work, but maybe hiding the impediment Another way….
- Undone work. Around longtime… Very transparent Similar to above, but you add Undone work for each Backlog Item. Unfinished work not the same as Undone
- What happens if we have a weak Definition of Done? Undone work increases every Sprint. At some point we have to tackle that and we create delay in release, and worse we might not know when we can release.
- Undone work. Around longtime… Very transparent Similar to above, but you add Undone work for each Backlog Item. Unfinished work not the same as Undone
- What happens if we have a weak Definition of Done? Undone work increases every Sprint. At some point we have to tackle that and we create delay in release, and worse we might not know when we can release.
- Our Definition of Done has driven transparency… The more Transparent we are. Everybody knows what Done means. The closer we are to perfect Definition of Done, we minimize the delay of risk. We discover issues earlier, we have higher quality. And through the Definition of Done identifying Undone work, we are able to focus on what issues we have at not being able to achieve our perfect Definition of Done. We start to identify impediments, these are impediments like… These are what I like to call Undone impediments.
- For each Undone piece of work, there maybe a number of impediments that is preventing us from being able to conduct that work in the Sprint. What are these impediments. Chat to neighbour Shout them out Examples test automation
- Some impediments are team based, and can be generally be removed by the team or at least collaborating with other peers. Some impediments tend to be a lot harder and may need support from higher management, and even support from Execs Implementing a CI server might be something that we can do at the team level. So that the build is automated and self-testing and deployable. And we love this because we start to work as a team and have the rituals and process around this that we can organise and manage at the team level. These tend to target lower level in the team and typically more technology based. Or creating a Continuous Deployment pipeline for AWS may also be achievable - again it might be a skills issue, but with correct hiring we can resolve this. We potentially move up, again we might be able to achieve this if our product, architecture and organizational structure enables that. But what if we can not make a continuous deployment because we have fragmented components based upon a more traditional architecture? This typically requires a move up the chain or a move up the organization to get it resolved. So we have impediments at different levels of our technology/product/organization. We can build a hierarchy of our impediments to our perfect definition of done. And as we knock each one off, we minimize the risk and delay of having Undone work.
- As we expand the definition of done in one direction tends to go up the hierarchy of our organisation. So if we can expand our definition of done we will have a tendency to drive Scrum adoption through an organization. We are just not expanding Definition of Done at the team level, an expansion of the Definition of Done will quickly have to tackle impediments at the Product and/or organization level.
- We have to be able to surface these impediments. One reason I believe that we don’t tackle these is because we become very team focussed. We have forgotten about one of the responsibilities of the Scrum Master: The Scrum Master serves the organization in several ways, including: Leading and coaching the organization in its Scrum adoption; Planning Scrum implementations within the organization; Helping employees and stakeholders understand and enact Scrum and empirical product development; Causing change that increases the productivity of the Scrum Team; and, Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization I know the first Scrum Master job I took on, nearly 10 years ago, a big part of my job was to spread Scrum through a department. We didn’t have Agile Coaches, I don’t think they existed then. And maybe, just maybe we don’t need them now if we emphasis one of the most forgotten roles of the Scrum Master. So there are ways to elevate these impediments, Less has an Overall Retrospective, SAFe includes program level retrospectives in the Inspect and Adapt session. But it’s ok raising the perfect Definition of Done impediments, the hardest part of course is solving the root cause of the problem. And just like items that come up in a team retrospective we can’t solve them all at once. However, we do want to investigate the value of resolving this, and decide where a particular resolution sits in our Scrum adoption. So we can come up with a backlog of impediments and just like any backlog I like to start to Map it out.
- If we have a target of our Perfect Definition of Done… We’ve identified Undone work
- And through adding our tasks to an Adoption Map.
- And as we expand our Definition of Done our Undone work decreases
- We can dirve Scrum Adoption through the team, product and enterprise. And that is how you Unleash the power of your Definition of Done
- So let me ask you this…. When you get back to your office… Stay standing if you’re going to visit your Definition of Done, or create one And stay standing if you are going to visit your Definition of Done with respect to your Perfect Definition of Done? And that is the power of your Definition of Done!
- And that is how you unleash the power of your Definition of Done