Violating Your Defintion Of Done To Get Things Done

When using an agile development approach such as SCRUM, your definition of done tells you when a feature is done to be released. Such a definition of done often contains stuff such as:

  • All code that is written complied to code conventions.
  • Code is decently documented/written such that it is easy to understand.
  • Automated tests are added and pass.
  • All code has been reviewed.
  • User documentation should be exist.

This definition of done prevents bad features from being released. A user will see a feature as bad if it contains too many bugs to be really usable or if it is poorly documented such that he does not know how to use it. A developer will see a feature (the code) as bad if it is hard to maintain. While some believe that the only focus should be the user, both are equally important.

In the real world we are however often faced with deadlines, and as the pressure builds up to release a feature it becomes harder to stick with your definition of done. Another problem that could prevent you from adhering to your definition of done is simple human error. Both of these are dangerous and should be avoided whenever possible.

The human error can be minimized and maybe even completely eliminated by having a decent build chain. Automated testing, code coverage, checkstyle and static code analysis are all tools that can measure the quality of your code, integrating these into your build and preventing developers from merging if any of these signals an error will greatly reduce the chance of forgetting something.

Doing this will not allow you to rush a feature into release either. Sales, Marketing and Services may not be so happy with this, as they just want to sell and implement the new feature. When a date of release was promised to a customer, there is little Development can do about this, though situations like these should be avoided. It is clear that in extreme situations we want to release a feature that does not fully comply to our definition of done.

The real danger with this situation is that finishing the feature will be delayed as it is not considered top priority anymore, new features are. This leads to a poorly tested, documented and structured feature that will contain more bugs, and a higher cost for maintenance. If this only happens occasionally you can easily recover from it, but the risk exists that estimations for new features are based on this ‘forcefully released’ feature. As the time to release is was not the same as the time to actually finish it, new estimations could be too low causing the same effect with new features.

Eventually you could end up with a feature rush where could is written as fast as possible to meet impossible deadlines. Bugs will pile up, and more time needs to be invested in maintenance. Sales, Marketing and Services start complaining of the amount of bugs that exist in the features, and the lack of new features being developed. Once this situation has been reached, it is a long and hard way to get back out of it.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.