Assessment and the definition of done

One key, yet often overlooked, Scrum concept is the definition of done. It is key because it makes you be explicit about what value means in the context of the project.

The definition of done is an instrument, not a recipe to take from a book. For example, in many projects I saw, the definition of done included some notion of testing the accuracy of functionality. Functionality is important, but what if you also care about performance as well? Or usability? You just add a rule in the definition of done.

If it is important enough, it should be part of the definition of done. And if it is in there, you must allocate time to do it. This also mean that you should put in the definition of done only those things that are important enough to be required.

Now, is the coherence of your architecture important enough? If yes, it should be part of the definition of done.

If you add it there, you have to ensure it, too. There are at least two ways to approach this problem. I know projects, for example at Google, in which every little commit must be reviewed by someone else. This is great for capturing problems in the small, but it can hardly be a solution for checking the architecture as a whole.

The other approach is to automate the checking process. Or at least part of it. Then you check it continuously. You then assess what you get, and take corrective actions.

And you do that every day. Because it is important.