5 False Friends in Software Development

Agile turns a lot of “common sense” thinking on it’s head. Responding to change is more valued than following a plan. But people think a plan is important and should be followed. That change is disruptive and costly. These are all true and it’s a sign of an experienced Agile developer to navigate through these challenges. So I thought I’d go through a few of these False Friends to show where you need to be cautious.

This wouldn’t have happened if we spent more time in analysis.

Is that true? How do you really know? There’s only so much you can discover through deep thought. And you will never discover all the same things that will be discovered by actually doing something.

The experienced Agile person will always push for action. A little analysis is fine but you should never hesitate to dive in and start creating solutions. If you discover it’s all not what you expected you still have time to take a step back and re-assess things. If you spend weeks or months in analysis you can never get that time back. Dive in!

It’s too hard to do TDD with this type of code.

If you’re talking about visual design you might be right. If you’re talking about the elements that make a game fun or boring you’re spot on. There is a lot that is not good to test through automation. But there is also a lot of code out there that makes things hard when it really doesn’t need to.

The experienced Agile person will recognise the patterns are defined by the test. Some tests are not work automating. But that has nothing to do with the design of the code, the programming language, how close or far it is to custom hardware. Code isn’t ever a bad choice to test. Some behaviours are a bad choice to test.

Implementing this WIP control is really hurting our productivity.

No it isn’t. This isn’t a “it depends” scenario. WIP limits help you discover what’s impacting your flow. You either are interested in improving your flow or you are not. If you think the problem is limiting work-in-progress. Now maybe this isn’t the right time to solve this problem. Maybe there are much bigger problems elsewhere which deserve your attention. But don’t blame the WIP limit. There’s more than enough science behind this one.

Our team has done a great job. No need for a retrospective.

Oh boy. Where do I even start? Let’s see:

  1. A retrospective is not a punishment. But now it’s being presented like one. What happened there?
  2. A retrospective is not all about failures. There is supposed to be time to recognise what is working well for you. A chance to do more of the things that help. Or even share that knowledge with other teams.
  3. Who is making this decision? The team should be doing retrospectives for themselves.
  4. What about actions from prior retrospectives? Did they help? Which ones? Seems like you don’t care what go you to the “great job”

If a Agile process isn’t working for you it’s a chance for a much wider discussion. There might be a good reason to just stop doing that ceremony. Especially if it’s become something that is described with that word. But what was the intention of the process? Are you getting that value some other way? Or is there another issue that’s preventing the value?

Everyone has their assigned task. No need for the daily scrum (standup).

Okay. A daily scrum is not a status update. It’s also not about making sure people are working. It should be about a team coming together to discuss how they can work best towards their shared goal. If there’s

And like with the Retrospective. Who is making this decision? The team should be meeting and discussing in a way that works for them.

There’s just a few I could think of. What False Friends do you know of? Let me know.


Leave a Reply