The 5 Agile monkeys


I was lucky to present recently both at Agile Australia and LAST conference in 2016. One of my speeches was a 5 minute lightning talk about the 5 Agile monkeys.

In case you missed it, here is a short summary.

Sometimes we behave like monkeys. We imitate others, we “talk the talk” – even if we don’t really understand the topic. We pretend to be agile, but we are not really. We use nice words like “business value” and “streamlining processes”, but we don’t really understand what our team is working on.

So I collected 5 behaviour patterns that I observed when we pretend to be Agile, but we’re not exactly it.

Why exactly five? Because I had 5 minutes to present at the conferences.

  1. The first monkey is the Cowboy monkey. This is the monkey that shoots ad-hoc at everything, claiming that he is agile. no plan, no documentation, forgetting that the manifesto statements are not exclusive (working software over extensive documentation, responding to change over following a plan – these are not exclusive statements, it’s about what we value more). These monkeys are often knowledgeable, so don’t try to blame them. It’s more important to include them in planning the work and make their work visible.
  2. My least favourite monkey is The Dogmankey (nothing to do with a dog, lot more with being dogmatic). We tend to forget that frameworks and methodologies are not legal documents that must be followed by the letter. In my opinion, while these methodologies have been created with the right intention, they are too often being commercialised (to sell courses and certificates) and might be applied dogmatically, to have a false sense of control for stakeholders.
  3. The BullshitMonkey To be honest, sometimes I fall into this category. We tend to overuse words like “customer value”, “prioritisation”, “streamlining business processes”. They’re all true and nice, but worth nothing if you just talk the talk and don’t walk the walk. If you don’t understand what your team is doing, it can become just preaching rather than really understanding how that value is created. Understand what your team is doing, what drives them. Understand what motivates them, understand what are those magic wors (e.g. refactoring) mean, and how you can help their work.
  4. The Tool Monkey Another quite common monkey, addicted to software tools, prefers processes and tools over individuals and interactions. You’ll hear things like “we have to fill out the system properly” or “everything has to be documented in our knowledge management system”. You see these monkeys using tools all day, generating reports – without talking to anyone and having any clue, what is the customer value and what the team is doing. In moderation using tools is good. They are just like frameworks – they’re there to help you to deliver customer value, but they shouldn’t drive your delivery. Imagine software tools as hammers and screwdrivers. Use a physical wall if you need to draw, have conversations in face-to-face, not comments in a software tool.
  5. Tech-monkey – I love the tech monkeys. They do all the right things, refactor, doing TDD, stabilising platforms. Awesome people. What they forget sometimes is to finish work. They always find new issues to work on and if you’re not careful a simple user story turns into a one year quest.

While we are all monkeys sometimes, always aim to be better and help your team to satisfy the customer through early and continuous delivery of valuable software.