Questioning "Best Practices" for Software Development: Practices are Contextual, Never Best

Scott W. Ambler + Associates
Home | Articles | Books | IT Surveys | Podcasts | Contact Us | Announcements | Site Map
Recently reviewed

A very popular term within the IT community is "best practice". It's a wonderful marketing term, how could someone possibly argue about adopting a best practice, but does the concept really make sense? I'm not so sure. There are many examples where a practice that is considered "best" in one context is questionable within another. As professionals, it seems to me that we should strive to understand the context which we find ourselves in, and then apply the practice which is best within that context. In other words, we should really be focused on "contextual practices", not "best practices".


Examples

When you observe what's going on within the agile community it becomes clear that many "best practices" really aren't. For example, consider the following practices:


Towards Contextual Practices

Ideally, we should talk about best practices at all but instead should talk about contextual practices. Depending on the context, sometimes a practice is "best" and sometimes it's not. Calling something a "best practice" implies that it's a good idea all of the time, something we inherently know to be false. Having said that, the term "best practice" clearly has more marketing value than the term "contextual practice", and in this industry we know that marketing typically wins over truth, something that is clearly not a best practice.

The Software Development Context Framework (SDCF) helps to provide insight into the context which IT teams find themselves in. It describes several factors which provides this context. The factors are:

  1. Team size. From teams of a few people to thousands.
  2. Geographic distribution. From people being co-located to being distributed around the world.
  3. Organizational distribution. From everyone working in the same org unit to people working for different organizations (such as outsource service providers, for example).
  4. Regulatory compliance. From being non-regulated to very strict regulation (such as FDA regulations, for example).
  5. Domain complexity. From very simple problems to very complex ones.
  6. Technical complexity. From greenfield single-platform systems to multi-platform systems using legacy systems and data.
  7. Organizational complexity. From organizations which are very flexible and collaborative to organizations which are very rigid/strict.
  8. Paradigm (implied). Are you following a process which is agile, lean, traditional/classical, ad-hoc, or a hybrid combination?

The point is that different teams find themselves in different situations, different contexts if you will, and therefore will tailor their approach to reflect that situation. They will adopt practices which meets their needs and tailor those practices accordingly, particularly when provided with the process goals-based strategy implemented via frameworks such as Disciplined Agile Delivery (DAD) .


Suggested Readings

Software Engineering Best Practices
Disciplined Agile Delivery This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise describes the Disciplined Agile Delivery (DAD) process decision framework. The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation for scaling agile. This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting. Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process. Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams. Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.
Managing Agile Projects Are you being asked to manage a project with unclear requirements, high levels of change, and/or a team using Extreme Programming or other Agile Methods? If you are a project manager or team leader who is interested in learning the secrets of successfully controlling and delivering agile projects, then this is the book for you. From learning how agile projects are different from traditional projects, to detailed guidance on a number of agile management techniques and how to introduce them onto your own projects, we have the insider secrets from some of the industry experts – the visionaries who developed the agile methodologies in the first place. Managing Agile Projects is edited by Kevin Aguanno, a noted speaker and educator on agile project management, and includes contributions from many noted figures in the agile movement.

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.



Disciplined Agile Delivery: The Foundation for Scaling Agile Agile Modeling: Practices for Scaling Agile Agile Data: Practices for Scaling Agile EnterpriseUP: Agility at Scale AgileUP: Towards Disciplined Agile DeliveryAmbysoft Inc. Software Development Practices Advisor Scott Ambler + Associates Follow @scottwambler on Twitter!


Copyright 2005-2014 Scott W. Ambler

This site owned by Ambysoft Inc.