Disciplined Agile

Part IV: FLEX As a Patterns Framework

Design Patterns took the development world by storm two decades ago. The reason for this was they highlighted the fact that many common challenges have already been solved for many different situations.  Patterns, defined by their creator, Christopher Alexander, as “solutions to a recurring problem in a context’ provide both a way of looking at common challenges while offering quality solutions to pick from so that they fit you. This avoids one from having to reinvent the wheel or take predetermined solutions that do not fit your situation.

In the earlier chapter we illustrated several recurring challenges

  1. takes too long to get anything done
  2. ineffective budgeting
  3. shadow IT
  4. chunks of work too big
  5. poor discovery intake process
  6. work items not sequenced
  7. working on too many things
  8. insufficient specialized skills
  9. unclear requirements
  10. poor development intake process
  11. no line of sight to strategies and OKRs
  12. lack of visibility of workflows
  13. lack of coordination between teams
  14. technical debt
  15. integration errors
  16. testing lags programmers
  17. problems discovered late
  18. Ops blindsided and pulled in many directions
  19. marketing needs left out

These, of course, are symptoms of deeper, underlying issues. We can try to solve them directly, but it is better to attend to what’s really happening – the true cause of these symptoms. Software development is complex and dealing with symptoms individually is unlikely to cause true, systemic wide, progress.

The reason so many companies have similar challenges is that key Flow, Lean and Agile practices are not done at many organizations. This results in similarities between their systems. Since systems inform behavior common behaviors are not surprising. However, what’s not being done and therefore the challenges organizations have is fairly common, how to fix these challenges depends upon the company they are in.

This is where patterns are useful. Patterns as “solutions to recurring problems in a context” can provide us with solutions that work for a particular company by attending to their context.  Of course, there are many solutions to solving the problem of, say, not having a good discovery intake process. If we organize all of the known solutions we have about how to have a good discovery intake process into a group (we’ll call it a patterns group) we can then when we have a problem, we can look in the patterns group that corresponds to it and then look for a pattern that is intended for the context we have.

If we collect these groups according to the value stream then we can think of our framework as a set of solutions to our challenges.