Tag Archives: Agile Events

Just in time and Envisioning versus complexity

Principles for reducing complexity:

Apply envisioning for accessible information and just-in-time for what is far from certainty.

That is matching with the logic of Stacey Matrix.  Just-in-time is not (always) a silver bullet.  We need process approaches that effectively cover both dimensions #agilemodeling #DAD

Agile design events and decisions options

Which are the concerns that should be considered for taking design decisions in an Agile Context?

Let think first about which are the “design events”, the moments in the life-cycle when design decisions are taken. The best description of these events could be found in Agile Modeling method (and inherited in DAD-Disciplined Agile Delivery):

  • Architecture Envisioning
  • Iteration Modeling
  • Look Ahead Modeling – opportunistically “model a bit ahead”
  • Model Storming – just in time modeling
  • … and Coding

TDD and Refactoring are rather ongoing activities, but main design decisions related to them could be also associated  with the any from the above mentioned events.

All the considered design concerns are generic, but some of them are more important in an Agile context (read Adaptive).  This is the proposed list:

  • New versus change: What existent parts will be affected and what is new? Sub-systems, components, external interactions.
  • Clean Architecture: Which are the changes in the business representations and which are the changes in the boundaries with frameworks and drivers.
  • Separation of Concerns: what we need to separate/decouple for Clean Architecture and for TDD?
  • Technical Debt: What Technical Debt we have to manage in the affected existent parts?
  • Cleanup: How much cleanup we need? How much Technical Debt should be payed now?
  • Adapt: What is the need of adapting (design) for affected parts, in the current known requirements context?
  • Adapt design techniques: which techniques should be used and in which amount? Refactoring or Redesign?
  • TDD: the main needed tests and decoupling decisions

Putting all together, we can model an Agile Design Decision Matrix with events and options.

Depending on the moment of the life-cycle, the magnitude of these aspects should be bigger or smaller, but I do not think that any of them should be skipped.

Adapt or not adapt? Cleanup is needed or is not needed? We need or we do not need auto-test?
All are possible options, and any answer it is a design decision.

Important: The answers to these questions will shape the needed work and must be used to estimate time and cost. Each of these events it is a moment of planning and re-planning.

Agile Design:  Simple Clean (& Tested) Design + Adapt

%d bloggers like this: