Good Practices Are Small, Cohesive, and Loosely Coupled


A few people have commented that Disciplined Agile Delivery (DAD) promotes a wide range of practices, which they like because it makes their options explicit but which they also potentially dislike because there’s so many practices to choose from.  This then leads to the question of why do we need so many practices?  First, there are a lot of practices out there to begin with and our philosophy is to help people know that they have options and help them to select the right ones.  Second, our experience is that for a practice to be easily consumable it should be:

  1. Small.  Small practices are generally more straightforward than larger practices.  As a result they’re easier to understand and to adopt.
  2. Cohesive.  A good practice addresses one issue and one issue only.
  3. Loosely coupled.  Good practices, like good software modules, have minimal dependencies on other practices.

Practices that are small, cohesive, and loosely coupled are easier to configure into more interesting solutions.  For example, the practice of test-first programming (TFP) is combined with refactoring to form test-driven development (TDD).  The practice of (writing) executable specifications can be combined with TDD, or TFP for that matter, to give you behavior driven development (BDD) or acceptance test-driven development (ATDD).  The combination of iteration modeling, model storming, look-ahead modeling, and BDD can give you a strategy for addressing emergent requirements and design during an iteration.

Of these three aspects, we’ve found that coupling has the greatest impact on your ability to tailor your approach to meet the unique situation you find yourself in.  Just like highly coupled software is difficult to maintain and enhance, processes built from highly-coupled practices are too.  For example, consider the way that Scrum describes product backlogs.  A product backlog is one of several strategies that agile teams may use to manage their work.  In the case of Scrum, the strategy is to prioritize requirements by business value and then focus on implementing the highest priority work at all times.   Unfortunately Scrum has coupled many important practices to the product backlog concept.  For example, initial requirements modeling is often referred to as populating the backlog.  Prioritization of new requirements and exploring upcoming requirements is referred to as grooming the backlog.   There are several potential problems to consider:

  1. The term “populating the backlog” masks the fact that not only are you writing initial functional requirements (for example user stories or features) as part of your initial requirements modeling efforts you’re also sketching things (processes, screens, data structures, …), identifying non-functional requirements, holding modeling sessions, and many other things.
  2. It makes it harder for people new to agile to understand how it works.  Think of it like this, what’s a more descriptive term, “populating the backlog” or “initial requirements modeling”?
  3. It makes it harder to combine practices.  If you wanted to swap out the product backlog for something a bit more sophisticated, such as a work item list, or something leaner like a work item pool, what do you do with the practices coupled to product backlog?  Do you  rework “backlog grooming” to be “work item list grooming”?  Do you rework “populating the backlog” to be “populating the work item pool”?  Even if these things are easy to do, seems like needless effort to me.

In conclusion, we have found that adopting small, cohesive, and loosely coupled practices enables you to adopt and tailor a process strategy that better reflects the context of the situation that you face.    Not only is high cohesion and loose coupling great strategies for software, their great strategies for software process too.

Have any Question or Comment?

3 comments on “Good Practices Are Small, Cohesive, and Loosely Coupled

Great post!

I could add that, in my experience, organizations are very different, they do different things under different conditions – and that would be a good reason for different practices to be around.

Many problems arise from combining and even understanding these different practices – and not the least, understanding why to use one or the other. Often it is simply a matter of tradition or the fact, that these practices are what people know. And if your only tool is a hammer…

So I like how you add to the list and teach developers more practices to choose from.

Duncan McGregor

Something else to add, when scrum is introduced the teams / company probably already had a defined process that they were using and often there is confusion in who is responsible for what.
So if you already have “Initial requirements modelling” then leave it as that and simply ensure that you are following the principles described – call them what you like

Valentin Tudor Mocanu

The backlog could be very useful, but is poorly described in Scrum.

In fact, backlog practice means that incoming work should be Serialized, Prepared and Ordered. The other parts/practices are just some vague substitutions for real engineering practices like Requirements & Solution Envisioning or Look Ahead Modeling and are source of confusions.

A small, and loosely coupled definition of the backlog could be very useful an it is easy to combine or replace.


Leave a Reply

Your email address will not be published. Required fields are marked *