Practices" for Software Development: Practices are Contextual, Never Best
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".
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
- Reviews. Consider
reviews, an activity which many traditionalists would consider to be a best
practice. And you know what, they're right, on a traditional software
project 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,
Apply Modeling Standards, and
Display Models Publicly you discover that model reviews don't
add much value to your project. 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
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 software process and of the domain. These
people have the ability to apply the right artifact for their current
situation, instead of just the artifact that they know (e.g. use cases), and
thereby are more effective.
- Detailed project plans. Many traditional teams will develop
detailed project plans early in the project and then invest considerable
amounts of time updating the plan to reflect actuals. Agilists take a
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.
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
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:
- Team size. From teams of a few people to thousands.
- Geographic distribution. From people being co-located to
being distributed around the world.
- Organizational distribution. From everyone working in the
same org unit to people working for different organizations (such as
outsource service providers, for example).
- Regulatory compliance. From being non-regulated to very
strict regulation (such as FDA regulations, for example).
- Domain complexity. From very simple problems to very
- Technical complexity. From greenfield single-platform systems to
multi-platform systems using
legacy systems and
- Organizational complexity. From organizations which are very
flexible and collaborative to organizations which are very rigid/strict.
- 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)
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.
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.
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.