Put Practices in Context: #NoBestPractices

There is no such thing as a “best practice”, except perhaps from a marketing point of view.  All practices (and strategies) are contextual in nature.  In some situations a practice works incredibly well and it other situations a practice can be the kiss-of-death.  Two of the philosophies behind the Disciplined Agile (DA) toolkit are that choice is good and that you should understand the trade-offs of the options available to you.  In short, practices are contextual in nature and you should strive to adopt the ones that work best for the situation that you find yourself in.

Let’s work through an example.  A hot button for many software developers are strategies around cost estimation, typically used for budgeting and forecasting purposes.  In DAD initial estimation is addressed by the Develop Initial Release Plan process goal, the goal diagram for which is shown below.  As you can see with the Estimating Strategy factor there are several options available to you.  We’re not saying that these are all of the potential estimating options available, but we are saying that this is a fairly good representative range.  The arrow on the left-hand side of the strategies list indicates that the strategies towards the top of the list are generally more effective for initial planning than the strategies towards the bottom of the list.  Your mileage may vary of course.

Initial release planning

The following table summarizes the trade-offs involved with two of the estimating strategies, in the case formal point counting (such as function points) and an educated guess by an experienced individual.  One of the reasons why the DAD book is so thick is that much of it is tables like this communicating the trade-offs of the hundreds of practices and strategies encapsulated by the toolkit.  As you can see, there are advantages and disadvantages to both strategies.  You can also see that there are situations where each strategy potentially makes sense.  Although you may not like a given strategy, I personally abhor formal point counting, you should still respect the fact that the strategy is viable in certain situations (perhaps not yours).


Strategy Advantages Disadvantages Considerations
Formal point counting
  • Fulfills contractual obligations in some situations – for example, the US Government often requires function-point based estimates.
  • Provides a consistent way to compare projects and team productivity.
  • Often increases the political acceptability of the estimate due to the complexity of the effort to create it.
  • Greatly extends the Inception phase effort.
  • Provides a scientific façade over the estimation activity, even though estimation is often more of an art in practice.
  • Reduces team acceptance of the estimate because the estimate is typically produced by a professional estimator.
  • Historical data won’t exist for new technology platforms or development techniques, requiring you to guess the value of some complexity factors.
  • Provides a mechanism to compare the productivity of development teams, which can motivate them to over estimate and thereby decrease comparability and the value of your historical database.
  • Total cost of ownership (TCO) is very high as it motivates questionable specification practices, which in turn motivate change prevention and other poor behaviors by the development team.
  • Overly long estimation efforts in an effort to get the “right answer” often prove to be far more costly than the actual benefit provided.
  • Beware of misguided desires for “accurate” or “consistent” estimates which prove costly to produce in practice yet don’t improve the decision making ability of senior management to any great extent
Educated guess by experienced individual
  • Very quick and inexpensive way to get a reasonable estimate.
  • Requires that you have an experienced person involved with your project (if you don’t, then you should consider this a serious risk).
  • Explicitly reveals to stakeholders that estimating is often more art than science.
  • Some stakeholders may be uncomfortable with the fact that you’re guessing.
  • Beware of estimates by people who are inexperienced with the platform or domain or who do not know the abilities of team.


There are several reasons why DAD’s goal-driven approach is important:

  1. It makes your choices explicit.  If your team wants to truly own your process then it first needs to know what choices are available to it.
  2. It makes it clear that practices are contextual in nature.  No practice is perfect for all situations, every single one has advantages and disadvantages.  Are you choosing the ones that are most appropriate for your situation?
  3. You can have more coherent discussions of the trade-offs that you’re making.  We have endless religious battles in the IT industry around process-related topics.  This often happens because people choose to focus on the benefits of their favorite practices and to downplay the disadvantages (or worse yet are oblivious to them).  To help your team move to more effective practices it’s important to recognize the trade-offs involved with each, to then discuss them rationally, and then decide to adopt the strategy that is most viable given your situation.  Note that this doesn’t necessarily mean that you’re going to adopt the best practice from the start, but that instead you’ll adopt the best one that you can right now.  Later on, perhaps as the result of a retrospective, you’ll decide to make improvements to your approach (in the case of process factors where the strategies are ranked by effectiveness, your team may choose to adopt a strategy higher in the list).
  4. Improves the effectiveness of retrospectives.  During a retrospective it is fairly straightforward to identify potential problems that you’re facing, what isn’t as easy is identifying potential solutions.  You can improve retrospectives by having these process goal diagrams available to you to suggest potential strategies that you should considering adopting.
  5. You can avoid reinventing existing practices.  Many very smart and very experienced people have found ways to deal with the same challenges that you’re facing today.  Furthermore, many of them have shared these strategies publicly.  If you don’t know that these strategies exist you are at risk of wasting time reinventing them, time that could be better spent adding real value to your organization.
  6. It enables scaling.  Teams in different situation will make different process decisions.  Although teams at scale, perhaps they are large teams or geographically distributed, will follow many of the same practices as small co-located teams they will also adopt a few strategies that make sense for them given their situation.   DAD’s process goals provide the insight that teams need to understand how they can address the challenges associated with the scaling factors that they face.

For a more detailed discussion about the challenges around “best practices”, you may find the article Questioning Best Practices to be an interesting read.  The New Deal for Software Development provides some interesting insights as well.

Have any Question or Comment?

3 comments on “Put Practices in Context: #NoBestPractices

Valentin Tudor Mocanu

IMO/IME,there are some exceptions to the rule, some very few best practices, but anyway even that practices must be adapted into the context. Example: there is no reason from that I know to not try to write the first code clean.
Clean Code first suppose some very small design decisions, rather context independent. A messy first code will affect any software endeavor.

On the other hand, the strategy to maintain the code clean, it is always context dependent.

There some few basic software engineering practices that always should be used IMO, but how and exactly when it is a context problem. Refactoring it is always useful, but when and how is context depended. Iterative approach it is always useful, but what kind of “iterations” will be used it is also context dependent.

Anyway, the more generic best practices such clean code, refactoring and iterative approach seems to be more close to principles as concept then to practices.

More: Agile must be opportunistic by definition, and adapt to the context must be one of its (missing) principles. “I am agile (~ adaptive), but I do not care about how to adapt to the context” type of logic is IMO a non-sense


Actually, why bother writing clean code if you’re purposely writing throwaway code, for example for a spike? Writing clean code has the disadvantage that it’s overkill for short-term, throwaway stuff.

Valentin Tudor Mocanu

Could be true for spikes, but also there, it’s dependent on the spike complexity. That mean for throw-away, non-complex cases we can bother less with clean code, but not also in other cases. In practice, too many people are writing normal code as throw-away code.
There is no deal and no gain from messy code in other cases.

Anyway, these very generic practices are exceptions.

The definition of engineering it is about using domain rules in a opportunistic and creative manner. That mean an engineer must know the rules, but also to be able to creatively and opportunely use them in context.
It is not about we do not need to know software engineering practices and rules, but in fact we need to know more then that: when, how and if we will apply these practices.

It is similar with the surgery… but applied to a “Men in black” world with a big variations in subjects anatomy.

That mean we need to know practices, principles (as a guidance) but also we need process guidance and personal practice in order to be successful.


Leave a Reply

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