patterns that connect
- Conventional: formal or heavy approaches, e.g. Rational Unified Process (RUP), CMM, etc.
- Non-Conventional: anything other than conventional.
Formal Versus Agile? You've Got It All Wrong!
As I interpret it, the agile versus formal debate is generally treated as an either or question. For instance, in any given software development situation there may be an assessment that it would have worked better if only an agile approach was used or for a project like this, you must use a formal approach. Only rarely does there seem to be an advocate that suggests integrating aspects of both approaches.
Inevitably, this has resulted in religious arguments about which approach is better, and religious arguments are usually from an absolutist’s perspective.
A funny thing happened on the way to resolving this issue; some folks with poor practices attempt to partake of any legitimacy that the agile approach offers by reinterpreting their practices as agile. Their approach is to elevate any poor practice they have as really being agile. Equally confused, other folks have taken genuine successes from the agile approach and reinterpreted them as luck, hacking, or some other variant of happenstance. Their approach is to reduce any agile success to at best the results of wishful thinking.
What do these two different groups of people, the elevationists and the reductionists, have in common? Both of these groups have a perspective that only allows for two levels of software development: lets call them conventional and non-conventional.
In addition, this re-interpretation can be shown to be an instance of a concept identified by Ken Wilber and named the ¿pre/trans fallacy¿. While this think piece is about software development processes, the subject area that the pre/trans fallacy originally referred to is much more universal and significant, that of human consciousness (e.g. Ken Wilber Online: Introduction to Volume 1 of The Collected Works). The pre/trans fallacy is part of a larger model called the Integral Model [need citation].
A Better Tool?
As with many computerized things, I’ve been frustrated with the commercial state of the art for software to manage information, especially personal information for quite some time. Let me provide some context to better explain.
While I’m often challenged to explain what I do, I can say it involves doing all sorts of actions on information (e.g. creating, manipluating, reasoning with, etc.). Much of my effort is in support of goals in the domains of software engineering or psychology. Given that software engineering by necessity deals with well structured sets of information, (e.g. programming code, design models, architectural models) it’s a natural place to look for mature information managment tools. In addition, there’s a healthy industry around supporting software engineering. Yet despite this, the level of tools for managing informaiton specific to software engieneering is very immature. If you look more broadly, the commercial state-of-the-art for information management is even worse.
How is information management immature? Usign the following scenario, let’s look at some gaps.
Bob is responsible for capturing informal natural language information (e.g. the beginning of the a set of software requirments) and over time hea nd others will transform it into formal models that for use by different types of audiences (e.g. users, customers, software designers, user interface designers).
What are some of the actions Bob and others will want to do with this information? Consider the following:
Refine something, i.e. take a whole and identify it’s parts. This process is very At any point, he’d like to understand relationships b There’s an interesting process that (it’s theorized) we go through when categorizing something. As I model it, it includes the notion of distinctions: e.g. how many Essentially, the boundary of categorization is crossed when we begin to recognize distinctions. An oft used example is snow - while someone from the southern United States may have one word for (and implicitly no distinctions for) snow, an
Reconciling Formal, Agile & No Processes
How to reconcile formal, agile & no processes in a software development environment?
Previously in conflict, considered by some as irreconcilible
Integrated using a model that accounts for development stages/levels.
Fundamental pattern: learn the form to become formless