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
- takes too long to get anything done
- ineffective budgeting
- shadow IT
- chunks of work too big
- poor discovery intake process
- work items not sequenced
- working on too many things
- insufficient specialized skills
- unclear requirements
- poor development intake process
- no line of sight to strategies and OKRs
- lack of visibility of workflows
- lack of coordination between teams
- technical debt
- integration errors
- testing lags programmers
- problems discovered late
- Ops blindsided and pulled in many directions
- 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.
Each pattern group represents patterns that solve a particular challenge in a particular context. While there are several groups here, we only need to navigate inside a group to find the challenge that suits us best. This enables storing a considerable amount of knowledge in one place while have a relatively simple high level view.
Chapters in this part
- Understand Your Options illustrates the effect each of the pattern groups has on the common challenges companies face.
- Contrasting Epics and MBIs. Epics are ubiquitous. They’ve been used for so long and in so many ways they’ve lost a lot of their usefulness. We prefer to use the concept of business increments that we will refine to minimum business increments. But since the notion of epics is so widespread, we usually just define them to mean ‘business increments.
- How Using MBIs Tie Strategies, the intake process, ATDD, and planning together. MBIs are more than a container of value required for a business increment – they much of the value stream together.