Design patterns are often described as “solutions to recurring problems within a context.”But the real power of patterns is to see the forces that each pattern resolves. They should be used as a way to help analyze what’s needed to create a quality design. That is the goal.
Given a situation where, say, the Strategy Pattern was not quite present but its concepts could be used, no one who understood patterns would criticize the solution by saying ,“Well, that’s not a Strategy Pattern!” So why do we hear these sorts of critiques in the process world? Let’s think about it.
To understand patterns requires an understanding of why the patterns are good. The insights you gain help you anticipate whether code done one way will be better than another. You don’t have to code and then try “inspect and adapt” to see what happened. That is expensive! Instead, understanding the mechanisms of why patterns work well enable you to apply these to your particular problem.
Process patterns, such as Scrum, should be used the same way. When you understand why Scrum really works, you can use those insights to do Scrum better and you can go beyond Scrum when the situation calls for it.
-AMAZONPOLLY-ONLYAUDIO-START-
This is Al Shalloway. Visit us at www.netobjectives.com.
-AMAZONPOLLY-ONLYAUDIO-END-
If you haven’t read Dan Greening’s work on Agile Patterns I highly recommend it.
http://www.greening.org/articles/Agile%20Base%20Patterns%20HICSS%202016%20official.pdf
More at senexrex.com
yeah, this is good. I’d read it a ways back. So is Coplien’s work. The problem is both of their work is mostly useful to experienced people. It’s why, although I think in terms of Lean and Agile as a set of patterns, i try to describe them in a kind of expert system manner.
See https://portal.netobjectives.com/articles-public/scrum-team-agility-support-system/