Monthly Archives: November 2015
Nov 15, 2015    |      0 comments

Cassette Tapes

Back when I was in high school – in the last 70’s and 80’s – there were four ways to listen to music.

You could listen to the radio. There was music on AM radio, but if you cared about music, you listened to FM radio. In my case, it was album-oriented rock radio.

Or, you could listen to your records. This gave you great sound, but 1) records degraded slightly each time you played them, 2) to get the best sound, you needed to follow an elaborate cleaning ritual, and 3) if you liked your music loud, the record would skip. Oh, and 4) they weren’t very practical for your car.

For your car, you could obviously listen to the radio, you could listen to 8-track tapes, a weird and clunky format that wasn’t very good.

Or, you could listen to a compact cassette – what everybody just called a cassette. Cassettes were small, easy to carry, and had decent sound. The record companies sold a ton of pre-recorded cassettes, which had a limited lifetime, sub-par sound (because they were duplicated at high speed and used cheap speed), and – if you were unlucky – would transform itself into a large wad of crumped-up tape. Interestingly, pre-recorded cassettes generally cost more than record albums.

If you wanted the best sound – and if you wanted to be cool – you had a stereo of your own, you bought albums, and you recorded them onto blank tape that you bought for $3 or so. And – if you bought 90-minute tapes – you could fit two albums on a single tape.

Okay, so, that wasn’t quite accurate. You bought *some* albums, but most of your music came from recording albums that friends. Because this was a bit of a hassle to do, you wanted to use a tape that was good quality. Most people I knew chose a specific brand – and often a specific tape – and stuck with it. At one point – around 1982 or so – they came out with a 100-minute variant, which was great because you could use it for albums that were longer than 45 minutes in length.

In my case it was the TDK SA-X90 pictured above, in a number of variants over the years. In college, I had a tape holder on the side of my stereo cabinet that held 48 individual tapes.

And then CDs came, then MP3s came, and then portable music players came, and cassette tapes went away. Though I found it difficult when I finally decided to get ride of them.

If *any* if that has any resonance with you, you might want to spend a few minutes on Project C-90.

Nov 1, 2015    |      0 comments

Agile Transitions Aren’t

A while back I was talking with a team about agile. Rather than give them a typical introduction, I decided to talk about techniques that differentiated more successful agile teams from less successful ones. Near the end of the talk, I got a very interesting question:

“What is the set of techniques where, if you took one away, you would no longer call it ‘agile’?”

This is a pretty good question. I thought for a little bit, and came up with the following:

  • First, the team takes an incremental approach; they make process changes in small, incremental steps
  • Second, the team is experimental; they approach process changes from a “let’s try this and see if it works for us” perspective.
  • Third, the team is a team; they have a shared set of work items that they own and work on as a group, and they drive their own process.

All of these are necessary for the team to be moving their process forward. The first two allow process to be changed in low risk and reversible way, and the third provides the group ownership that makes it possible to have discussions about process changes in the first place. We get process plasticity, and that is the key to a successful agile team – the ability to take the current process and evolve it into something better.

Fast forward a few weeks later, and I was involved in a discussion about a team that had tried Scrum but hadn’t had a lot of luck with it, and I started thinking about how agile transitions are usually done:

  • They are implemented as a big change; one week the team is doing their old process, then next they (if they are lucky) get a little training, and then they toss out pretty much all of their old process and adopt a totally different process.
  • The adoption is usually a “this is what we are doing” thing.
  • The team is rarely the instigator of the change.

That’s when I realized what had been bothering me for a while…

The agile transition is not agile.

That seems more than a little weird. We are advocating a quick incremental way of developing software, and we start by making a big change that neither management or the team really understand on the belief that, in a few months, things will shake out and the team will be in a better place. Worse, because the team is very busy trying to learn a lot of new things, it’s unlikely that they will pick up on the incremental and experimental nature of agile, so they are likely going to go from their old static methodology to a new static methodology.

This makes the “you should hire an agile coach” advice much more clear; of course you need a coach because otherwise you don’t have much chance of understanding how everything is supposed to work. Unfortunately, most teams don’t hire an agile coach, so it’s not surprising that they don’t have much success.

Is there a better way? Can a team work their way into agile through a set of small steps? Well, the answer there is obviously “Yes”, since that’s how the agile methods were originally developed.

I think we should be able to come up with a way to stage the changes so that the team can focus on the single thing they are working on rather than trying to deal with a ton of change. For example, there’s no reason that you can’t establish a good backlog process before you start doing anything else, and that would make it much easier for the agile teams when they start executing.