Author: Federico Kereki, Tech Master

In the previous note (#1 in the series) we said we’d be looking at several analogies between agile methodologies and Jazz music, and we’ll start by focusing on a key point: the need to change! It so happens that Jazz, practically by definition, accepts change.

Modern Jazz musician Pat Metheny (the only person to ever win Grammy awards in ten different categories) has worked in several different music genres, changing his own style every time, and his own experience agrees with the need for change; as he says, Jazz has in its “nature to change, to develop, and [to] adapt”.

What does this have to do with agility? The Agile Manifesto is based upon several principles, but we want to focus in a couple of them:

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

So, a well organized agile group should be able to structure themselves, and to adapt whichever methodology they are using, to better suit the requirements of the process, of the product, or of the client.

What should be the first step? There are many available ways to go, of which the following is just a short list, which can certainly be expanded – and we won’t get started on arguments as if each is actually a methodology, a framework, a technology, or just guidelines!

  • Scrum? Kanban? Scrumban, a mixture of the former ones?
  • Lean? Lean Kanban, another mixture?
  • Extreme Programming (XP), many of whose practices are used in other methodologies?
  • Alistair Cockburn’s Crystal?
  • Open Development, which some people call “Scrum’s replacement”?
  • …and many more

Obviously, you shouldn’t start by changing whichever methodology you use, just for the sake of change. However, you really should give a look at the different available alternatives to check whether it matches your specific conditions and requirements. For example, would a fairly structured approach based on timeboxes be useful for you? If so, then Scrum may be your option; otherwise, you could look into Kanban or maybe a mix of them such as Scrumban. You should take into account (inspect) all your environmental conditions (your developers, your client, the product to be built, other conditions, &c.) and then evolve to the most suitable process.

Most important point: Once you have decided what to do, you should go ahead and implement your selection to the hilt, with no alterations whatsoever! No matter what you may think or believe, there’s usually a very good reason for each part of any methodology, so it won’t do to modify it before you have actual experience and a good rationale for any change. (So… yes, I’m suggesting that you consider change, but not everything, at least at the start!)

After a certain period of experience, you can look back, and see if the expectations that led you to choose a methodology, are actually valid, and just then think if you could change to a new one. Or, as it may be, you may also consider changing some of its tenets… we’ll get back to this!

In Jazz, evolution and change are constant, and throughout its history there have been quite a number of variants, which show its dynamicity; embrace change too, and be willing to consider other ways of working!

P.S. Check out this top list of Pat Metheny, which includes half a dozen of his best known themes, from The Beatles’ “And I love her” to “The Sound of Water”, in which he plays a truly weird “harp guitar”!

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>