chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male

Ch-Ch-Changes (or: My Doppelganger and I)

A few weeks ago I met my doppelganger.

At least, the guy portrayed my 10-year-ago self very well.

I was giving a talk about agile, and giving scrum the treatment I usually give. And the doppelganger raised his hand and said (I’m paraphrasing): “You keep throwing allegations around about scrum, when everyone knows scrum works.”

I acknowledged that it does work, from time to time, and within context, then got back to my talk.

After the talk, the guy came up and we started talking about TDD. I asked if he tried it, and he said no, that would be a bad idea. Why? He told me he went to the source, read all about Kent Beck’s backstory, values and ideas, and realized that TDD as originally intended, with emergent design is really bad. It’s the opposite of thinking thoroughly about a problem, then solving it, which works for him all the time.

Before we started an all-out  brawl, I smiled and said goodbye.

Who moved my authority?

Some people have all the answers. I was one once.

I’ve learned to accept that I don’t have all the answers, and I never will. That wasn’t a smooth transition for a know-it-all, quite shocking really.

If the best answer you have is “yes, but…” or “it works in some cases”, you start to question the authority you’ve developed over the years as a resident genius. Not only that, other people question it too.

“TDD work for some people, some of the time”. Doesn’t sound as decisive as “TDD works, period”.

Would it work for you?


Then why would you bother trying it, when upfront design works every time?

Responding to change

The agile manifesto starts with “we’re uncovering better ways of developing software…”. You definitely don’t know everything, and specifically, where the discovery leads.

Being agile is about making changes to accommodate reality. Maybe the agile manifesto wasn’t just talking about the software development. Even “agile” itself has done that. I don’t think there was a plan originally, but it definitely responded to changes in technology, management methods, communication and education.

I know today a lot more than I did ten years ago, and I’m frightened and excited about what I’ll know in ten years time.

Today kanban is hot, XP is not.  Who imagined that ten years ago?

Where will agile be ten years from now?

Want to meet your non-agile doppelganger in a few years?
Watch our free on-demand webinar, and discover how to build effective agile development processes