Differences

This shows you the differences between two versions of the page.

--- 2014:methodology_patterns_workshop [2013/11/14 20:06] – created jonjagger
+++ 2014:methodology_patterns_workshop [2016/06/11 14:05] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
 Back to [[conference:committee:2014-proposals]]\\
 \\
-**Title**:None of the ideas presented here are new; they are just forgotten from time to time\\
+**Title**:Methodology Patterns Workshop\\
 **Proposer**: [[2014:Giovanni Asproni]]\\
-**Type**: Tutorial\\
+**Type**: Workshop\\
 **Duration**: 90 mins\\
 **Description**: \\
-The title is a quote from Alan Perlis' Turing Award Lecture. The idea is to talk about things in sw development that we keep rediscovering all the time, often because we forget our past, but also because we don't seem to look for inspiration in the right places--a case in point are people re-discovering some management principles and re-branding them "agile", but there are quite a few other examples around. This could be organised as a talk, but I was thinking we could come up with a kind of quiz game with some selected participants, and make it something fun. I haven't got a fully formed idea yet, but I'm open to discussions and suggestions. I hope this is a good enough description for now (if accepted I'll have to produce a proper abstract)\\
+I've recently started to work on the idea of 'Methodology Patterns' as an alternative way for teams to come up with a methodology fit for their needs - a one methodology per project as proposed by Alistair Cockburn. The idea is to describe all the practices (all meaning technical like TDD, but also managerial, leadership, etc.) we use every day as patterns and to connect them in a set of overlapping pattern languages which, in turn, can be used as starting point to implement the one-methodology-per-team approach - using patterns and pattern languages to do that is not a new idea, see for example Jim Coplien's 'Organizational Patterns' book, but it has been overlooked in the main methodology debate, which, instead, has been mostly focusing on finding 'The Methodology' to solve all problems.
+The use of patterns and pattern languages has several advantages, among the others:\\
+Patterns include the contexts they work best along with the consequences of using them (many teams do mix and match haphazardly by ignoring the consequences)\\
 \\
+Comparing the effectiveness of different methodology frameworks, e.g., Scrum vs Kanban, even in the same context, is, at best, impractical. On the other hand, measuring the effectiveness of a practice in a given context is feasible\\
 \\
+Pattern languages can provide a guide to choose the patterns that work well (or don't) in a given context, helping the stakeholders to make informed decisions.\\
 \\
+People can focus on thinking of what is really important for the project without fear of doing something bad because they are not following a specific methodology by the book.\\
+\\
+The aim of the workshop is to share the experiences of the participants in implementing the practices they use in their own teams and understand the context as well as the pros and cons of each, put them into pattern form and share any insights.
+This is a follow up of the "Methodology a la Carte" session I presented at ACCU 2013, and has been inspired by some conversations I had before and after the session. Some slides of talks I've been presenting on the same subject can be found here http://asprotunity.com/papers.html\\
+\\
+\\
+\\