This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.

 

Christopher Alexander, in Timeless Way of Building, defined a pattern as “a solution to a recurring problem in a context.” But towards the end of this classic, and essential, book, he says “At this final stage, the patterns are no longer important: the patterns have taught you to be receptive to what is real.” When I first read this I just nodded and said “yes, I know” to myself. What’s real are the issues to resolve.

Mr. Alexander also put forth the idea of a pattern language in A Pattern Language: Towns, Buildings, Construction. The concept being that you could have a collection of patterns that combined to solve larger problems.  The Agile technical community has tried to apply the notions of pattern languages to software development with mixed success. I have never been a fan of them in software development because software development methods change so fast new patterns are always evolving and no stable language exists. However, if one looks at development work from a flow and value stream perspective much of the work required at the conceptual level is reasonably consistent. At a minimum it can evolve.

While many people focus on Alexander’s patterns, his approach to design is even more powerful. Before describing his approach, he states – “Design is often thought of as a process of synthesis, a process of putting together things, a process of combination. According to this view, a whole is created by putting together parts. The parts come first; and the form of the whole comes second.” I remember nodding to myself as I read this thinking “yes, this is how I design.” However, the next word on the page was “But …”  and I knew he was going to tell me this leads to poor design. Essentially, he says that this approach to design leaves the pieces with poor relationships between them.  Being preset, they can’t relate as well as they should.

The solution is to design from the whole. “It views design as a sequence of acts of complexification; structure is injected into the whole by operating on the whole and crinkling it, not by adding little parts to one another.  In the process of differentiation, the whole gives birth to its parts: the parts appear as folds in a cloth of three-dimensional space which is gradually crinkled.  The form of the whole, and the parts, come into being simultaneously.”

DA FLEX is designed this way. The “whole” is the value stream. It’s first split is the business side and how it relates to the development group. Each group is further sub-divided, taking care to relate to the pieces that result from the “complexification.”

FLEX was designed with this approach. It ends up resulting in about 30 main patterns, each with different methods of implementation. The key with the patterns is how they relate to each other. The patterns are not just about how one step of work is done relating to another. The types of patterns are listed in List 1 with the table replicated with some example patterns added to it in List 2.

1. Actions
2.  Roles
3. Artifacts
4. Collections of artifacts
5. Process improvement patterns (which must attend to human psychology, psychological safety, motivation (individual, team, organizational)
6. Agreements
7. Collaboration methods
8. Organizational structure and allocation
9. Workflow patterns
10. Observation patterns (Inherent simplicity)

List 1: Types of DA FLEX Patterns

1. Actions
   • Identifying MBIs
   • Planning
   • Coordination and Synchronization
   • …
2.  Roles
   • Product manager
   • Product owner
   • Developer
   • Business architect
   • …
3. Artifacts
   • Strategies
   • Initiatives
   • MBIs
   • Features
   • Stories
4. Collections of artifacts
   • Portfolio backlogs
   • Product backlogs
   • Team backlogs
   • …
5. Process improvement patterns (which must attend to human psychology, psychological safety, motivation (individual, team, organizational)
   • Kaizen
   • Kaikaku
   • Emergent
   • …
6. Agreements – Disciplined Agile Promises
7. Collaboration methods
   • Planning
   • Visualization
   • Communications
   • Synchronization
8. Organizational structure and allocation
   • Cross-functional teams
   • Focused solution teams
   • ARTs
   • …
9. Workflow patterns
   • Kanban
   • Iterations
   • Feedback loops (individual, team, organizational)
   • …
10. Observation patterns – Inherent simplicity

List 2: Types of DA FLEX Patterns with some examples

There are currently about 100 DA FLEX patterns in various stages of documentation.  I am currently defining and refining them in the Disciplined Agile Value Stream Consultant workshop.