Questioning the Concept of "Best Practices": Practices are Contextual, Never "Best"

A very popular term within the business 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:

• Reviews. Consider model reviews, an activity which many people would consider to be a best practice. And you know what, they're right in some circumstances. For example, on a traditional software team reviewing source code, models and documents is a best practice because it's a technique which enables you to validate your work early in the lifecycle when problems are less expensive to address. But, model reviews don't seem to make much sense on agile projects. When you have adopted Agile Modeling (AM) practices such as Active Stakeholder Participation, Model With Others, Collective Ownership, Apply Modeling Standards, and Display Models Publicly you discover that model reviews don't add much value to your team. Why does this happen? Model reviews compensate for poor communication, poor collaboration, and for individuals (or small groups of individuals) working on their own without regular input from others. Traditional teams suffer from these problems: they often have specialists such as business analysts, database designers, testers, and programmers who create artifacts and then hand them off to the next specialist(s) downstream from them and they often allow specialists to work on "their" artifacts in relative seclusion from the rest of the team. This approach is fraught with risk, and model/documentation reviews compensate for those risks. If you choose to work this way then model reviews are in fact a very good idea and clearly are a best practice for these teams. Agile teams, on the other hand, don't make these mistakes. Agilists are often generalizing specialists with a wide range of skills, they don't need to hand off work to others instead they collaborate with them to get the job done. Agile teams communicate and collaborate openly, they share artifacts and work on them together, they typically don't assign ownership to individuals and thereby don't risk the "owner" going off in a different direction from the rest of the team. Because agile teams don't suffer from the problems with model reviews compensate for they find that model reviews aren't a best practice and are arguably even a bad practice or worst practice.
• Modeling everything up front so as to "get it right". Agilists are discovering that you're far more effective to model storm just in time (JIT) because your team's understanding of the domain changes over time: you can ask more intelligent questions based on your greater knowledge and your stakeholders can provide more intelligent answers because of their better understanding.
• Building teams of specialists. Agilists are finding that specialists do far too much work, a use case modeling specialist will create really great use cases whether you need them or not, and have problems interacting with other specialists: the Java expert doesn't appreciate, or understand, the implications of what the database expert is trying to achieve, and vice versa. It's better to build teams from generalizing specialists, people with one or more specialties who have a general understanding of the process they're following and of the domain. These people have the ability to apply the right technique for their current situation, instead of just the technique that they know (i.e. user stories), and thereby are more effective.
• Detailed plans. Many traditional teams will develop detailed plans early in the initiative and then invest considerable amounts of time updating the plan to reflect actuals. Agilists take a rolling wave approach to planning: we create a high-level plan showing the major dependencies and the development cycles/iterations, and then at the beginning of a cycle as a team we identify the tasks we need to perform to accomplish our goals. Just in time planning by the people who will do the work is a far more effective way to work.

Towards Contextual Practices

The Situation Context Framework (SCF) 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.

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 tool kits such as Disciplined Agile (DA) .

Suggested Readings

• Active Stakeholder Participation: An Agile Core Practice
• A Disciplined Agile Approach to Data Warehouse (DW)/Business Intelligence (BI) Teams
• Agile Database Core Practices
• Agile Documentation Core Practices
• Agile/Lean Data Governance Core Practices
• Agile Requirements Core Practices
• Agile Modeling Core Practices
• Agile Testing and Quality Strategies: Discipline Over Rhetoric
• Architecture Envisioning: An Agile Core Practice
• Best Practices (William Caputo)
• Effective Practices for Enterprise IT
• Choosing the Right Software Method for the Job
• Document Late:An Agile Best Practice
• Executable Specifications:An Agile Core Practice
• Iteration Modeling:An Agile Core Practice
• Just Barely Good Enough (JBGE) artifacts:An Agile Core Practice
• Model a bit Ahead:An Agile Core Practice
• Model Storming: An Agile Core Practice
• No Best Practices (James Bach)
• Phases Examined
• Prioritized Requirements:An Agile Core Practice
• Stakeholder Rights and Responsibilities
• Requirements Envisioning: An Agile Core Practice
• Single Source Information:An Agile Core Practice
• Software Process Improvement (SPI) Practices
• Surveys into Agile Development and Data Management
• Test-Driven Design (TDD)
• Translating Scrum Terminology
• Why Agile Software Development Works: Improved Feedback

This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) - Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context.