{"id":188,"date":"2013-02-01T09:30:50","date_gmt":"2013-02-01T09:30:50","guid":{"rendered":"http:\/\/asprotunity.com\/blog\/?p=188"},"modified":"2013-03-15T10:06:30","modified_gmt":"2013-03-15T10:06:30","slug":"methodology-a-la-carte","status":"publish","type":"post","link":"https:\/\/asprotunity.com\/blog\/methodology-a-la-carte\/","title":{"rendered":"Methodology \u00e0 La Carte"},"content":{"rendered":"
\n

\u00e0 la carte<\/strong> |\u02cc\u00e4 l\u00e4 \u02c8k\u00e4rt, l\u0259|
\nadjective
\n(of a menu or restaurant) listing or serving food that can be ordered as separate items, rather than part of a set meal.<\/p>\n<\/blockquote>\n

I’ve been uncomfortable with the mainstream discussions about software methodology for quite some time. It seems to me that far too many, in the software development community, are in a wrongheaded quest to find The Methodology that will solve all our software development sorrows. <\/p>\n

So far we’ve had (just to mention some popular ones): Waterfall, Spiral, Evo, RUP, DSDM, FDD, XP, Scrum, Kanban, Disciplined Agile Delivery; and also some cross-breeds, e.g., Scrum + XP, Scrumban (Scrum + Kanban), etc. <\/p>\n

We keep finding that each of those methodologies has many strengths, but also several weaknesses that make each of them applicable in some contexts but not, easily, in others. I think this will always be the case. <\/p>\n

Let me explain.<\/p>\n

Let’s first look at what a methodology is. The definition I like the most is this one by Alistair Cockburn, found in [1]Cockburn:2006:ASD:1177327<\/span><\/a><\/p>\n

\n

Your ”methodology“ is everything you regularly do to get your software out. It includes who you hire, what you hire them for, how they work together, what they produce, and how they share. It is the combined job descriptions, procedures, and conventions of everyone on your team. It is the product of your particular ecosystem and is therefore a unique construction of your organization.<\/p>\n<\/blockquote>\n

According to the definition above, all methodologies in the previous list are more accurately described as methodology frameworks—they impose some constraints, and make some assumptions about the surrounding context, but leave many (important) details to the specific implementations (note that they include team dynamics and personal preferences. They are very important, but I’m going to leave them out for now).<\/p>\n

Constraints and assumptions are both a strength and a weakness of every framework. If they are satisfied in the context where the framework is applied, then using the framework can save time, money, and grief. However, if they are not, using the framework can become difficult, if not detrimental. <\/p>\n

For example, think of teams working in fixed length iterations that also have to deal with support issues and point releases outside their standard iteration cycle; I’ve encountered this problem several times with different teams, and the implementation of a solution has never been straightforward. <\/p>\n

Another example is TDD. I’m a strong advocate of TDD, however, it is a practice that requires some level of proficiency, and, in some contexts, it is just too difficult to adopt straight away. Sometimes it is just better to start by writing unit tests without caring about when they are written—first or last—as long as they are there (and, before you lambast me on this, I know perfectly well that TDD is not only about testing, but also about design; however that’s not my point here).<\/p>\n

I can give many more examples, but the point is that, whatever the methodology framework, some of its assumptions and constraints may not be valid in some contexts.<\/p>\n

In my opinion, a better approach would be to create a methodology per project by mixing and matching sound practices, processes and tools—which can be borrowed from existing methodologies, or the literature, e.g., [2]Beck:2004:EPE:1076267<\/span><\/a>, [3]Coplien:2004:OPA:993868<\/span><\/a>, [4]Cockburn:2004:CCH:1406822<\/span><\/a>—to fit the context and the needs of the project. This is what “\u00e0 la carte” is about.<\/p>\n

Mind you, I am not claiming to have invented or discovered anything—this is what effective teams have always done (and it’s an approach I’ve been promoting for quite some time [5]asproni2004exprep<\/span><\/a>)—but I think that we, as a community, need to have a different kind of discussion from one focused on promoting one methodology over the others.<\/p>\n

Some people pointed it out to me that this approach looks like Crystal [4]Cockburn:2004:CCH:1406822<\/span><\/a>. I’ve certainly been influenced by it; however what I’m describing here is neither a methodology nor a methodology family (like Crystal Clear and Crystal, respectively), since it doesn’t impose any constraints or assume any context. All it requires is discipline, mindful choices, and the willingness to improve.<\/p>\n

That said, I think that there still is a place for methodology frameworks like the ones mentioned before. In fact, you may be in the lucky position where one of them works for you straight out of the box; however, if you are not, and you fear you may incur in some form of analysis paralysis, you can choose one as a starting point, then modify it as necessary—incidentally, this is what many Scrum and Kanban teams seem to be doing anyway.<\/p>\n

I’ll be doing more work on this, and I’ll be speaking about methodology \u00e0 la carte at the upcoming ACCU 2013 conference<\/a> in Oxford, UK. <\/p>\n

In the meantime, I’ll welcome your feedback.<\/p>\n

\n
\n
    \n
  1. Cockburn:2006:ASD:1177327<\/span>\n

    Cockburn, Alistair, Agile Software Development: The Cooperative Game (2nd Edition) (Agile Software Development Series)<\/em><\/a>, Addison-Wesley Professional, 2006.<\/p>\n<\/li>\n

  2. Beck:2004:EPE:1076267<\/span>\n

    Beck, Kent and Andres, Cynthia, Extreme Programming Explained: Embrace Change (2nd Edition)<\/em><\/a>, Addison-Wesley Professional, 2004.<\/p>\n<\/li>\n

  3. Coplien:2004:OPA:993868<\/span>\n

    Coplien, James O. and Harrison, Neil B., Organizational Patterns of Agile Software Development<\/em><\/a>, Prentice-Hall, Inc., 2004.<\/p>\n<\/li>\n

  4. Cockburn:2004:CCH:1406822<\/span>\n

    Cockburn, Alistair, Crystal clear a human-powered methodology for small teams<\/em><\/a>, Addison-Wesley Professional, 2004.<\/p>\n<\/li>\n

  5. asproni2004exprep<\/span>\n

    Asproni, Giovanni, Fedotov, Alexander and Fernandez, Rodrigo, An Experience Report on Implementing a Custom Agile Methodology on a C++\/Python Project<\/em><\/a>, Overload 64, December 2004.<\/p>\n<\/li>\n<\/ol>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    \u00e0 la carte |\u02cc\u00e4 l\u00e4 \u02c8k\u00e4rt, l\u0259| adjective (of a menu or restaurant) listing or serving food that can be ordered as separate items, rather than part of a set meal. I’ve been uncomfortable with the mainstream discussions about software methodology for quite some time. It seems to me that far too many, in the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[5,9,6,10,4],"tags":[],"series":[],"class_list":["post-188","post","type-post","status-publish","format-standard","hentry","category-agile","category-kanban","category-methodology","category-scrum","category-software-development"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p2KmbL-32","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/asprotunity.com\/blog\/wp-json\/wp\/v2\/posts\/188","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/asprotunity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/asprotunity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/asprotunity.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/asprotunity.com\/blog\/wp-json\/wp\/v2\/comments?post=188"}],"version-history":[{"count":0,"href":"https:\/\/asprotunity.com\/blog\/wp-json\/wp\/v2\/posts\/188\/revisions"}],"wp:attachment":[{"href":"https:\/\/asprotunity.com\/blog\/wp-json\/wp\/v2\/media?parent=188"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/asprotunity.com\/blog\/wp-json\/wp\/v2\/categories?post=188"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/asprotunity.com\/blog\/wp-json\/wp\/v2\/tags?post=188"},{"taxonomy":"series","embeddable":true,"href":"https:\/\/asprotunity.com\/blog\/wp-json\/wp\/v2\/series?post=188"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}