Our world is made up of patterns. Don’t believe me? Then take a look around. What do you see? Patterned wallpaper? Good, that’s a start. Maybe have a look out the window. Here in Berlin, where our firm is located, you can behold a range of whimsical scenes. However, often you see one thing: buildings. Patterns can also be found there. The architect and philosopher Christopher Alexander explained this in the 1970s in his book “The Timeless Way of Building”.
So, we have been busy with the theme of patterns for about forty years. Why write a blog post about it now? Because patterns have substantially influenced software development and they can be transferred to other subject areas, like agile project planning.
Patterns are solutions for concrete problems
What is a pattern? Christopher Alexander himself did not specify a precise definition. However, he did specify the following: Certain patterns must exist in architecture so that people find their neighborhoods comfortable and “liveable”. Patterns are the language that generate the entirety (the architecture). Existing patterns are specified in a pattern catalog. For instance, they are used to distribute parks or cafes in a city ideally. They explain how houses are built, or how light should flow through a room. So keep this in mind if you want to plan your own city.
Patterns form solution concepts for certain problems that can be re-used and repeated in buildings. They are always related to other patterns and can be adapted for each certain context. Their purpose and application are clearly described.
The idea applied to software development so well that Gamma, Helm, Johnson and Vlissides published “Design Patterns” in 1994 – a wide-reaching work by the gang of four.
Why use patterns in software development?
Patterns let you work efficiently because then you don’t have to reinvent the wheel. They are mainly used in object-orientated programming languages and represent code solutions for specific problems. Software architecture and development differentiate between the following patterns, for example:
- Generation patterns: for generating objects
- Structure patterns: for designing software
- Behavior patterns: for complex software behavior
- Analysis patterns: for requirement analysis
- Anti-patterns: how not to do things
Patterns in project planning
So you see: the concept originated in a completely different subject area. Good ideas can be applied anywhere where they are helpful. So in agile project management, too. How does that work?
Imagine an agile project with its teams, its product backlog, its sprints and its artifacts like requirements, use cases or test cases. All these elements can be stored in a previously defined structure:
- Folders where requirements for the domain are stored (product or domain backlog)
- Folders where requirements for sprints and releases are stored (release and sprint backlogs)
- Folders for test cases
- Folders for documents
You might also work in an environment of classical project management. That means: you plan activities for different releases and sprints.
So what happens if you need to add a new team? It also requires its own sprint backlogs. A new folder is necessary where the team’s artifacts are structured and stored retrievably. And of course you have to plan new activities for the team’s sprints. Do you do all this manually? Pretty time-consuming, isn’t it? And there is also the danger of forgetting something.
That is why you can use a proven pattern here. The aforementioned situations are just specific problems in agile or hybrid project management. Solving them with patterns is easy with the right tool.
Use patterns with objectiF RPM
objectiF RPM offers you patterns for different problems, for example:
- Create next sprint for a release
- Create next sprint for a team
- Create release for a team
The pattern Add team to release can also be found here – so the solution to the previously mentioned concrete problem. Each pattern is stored in the pattern catalog of objectiF RPM and described with its purpose, application, configuration and results.
The results of the pattern Add team to release are:
- A team activity and the first sprint activity will be created for the team under the release activity.
- A folder hierarchy will be generated that includes, inter alia, folders for the backlog, evaluations and artifacts for the first sprint.
- Analyses and queries will be created (for example an earned value analysis).
- For quick access, a new theme will be created in the theme bar.
Applying this predefined pattern is easy. Right-click a release activity and select the pattern to be used. Now you can adapt the pattern to your specific context. For example, the new team’s sprints should also be labelled with team names like Team London Sprint. This can be done by changing the placeholders. And then planning with the new team can get started!
Of course, you can also adjust pattern templates or create your own. Try it out for yourself!
Check out the free trial edition of objectiF RPM.
Or learn more about agile and hybrid project management with objectiF RPM.
Alexander, C. (1979). The Timeless Way of Building. Oxford: Oxford University Press.
Gamma et al. (1996). Entwurfsmuster. Bonn: Addison-Wesley Deutschland.