All I want is 30″ and a remote control …

This was originally posted on my previous blog: Spike the Poodle.

We have a pretty nice television in our flat – it’s pretty big, not widescreen but that’s OK. It’s got just one huge problem: no remote control (it did have, once, but it was lost before it was donated it to me). I’m not lazy (well OK I am) but even so it sucks getting up to change between DVD and TV.

So I was excited when my flatmate announced that she was going to buy a new television for our living room. Scarily, she’s even less technical than I am when it comes to household appliances, so I was roped in as a (willing) shopping partner and we decided Today was TV Day.

We finally arrived at Currys Digital – via Boots, Debenhams, HMV (gotta have a new DVD to go with the new TV), one Currys that was already closing, Selfridges, John Lewis, and Starbucks – only to find that TV prices seem to start at around £500 everywhere. Unless you want to watch television on a postage stamp, that is.

When did televisions get so complicated and expensive? Everything is LCD and HD ready

LCD TVs are great, only a few inches thick, and if like my Dutch flatmate you’re planning to ship them abroad at some point it’s very handy. But they’re EXPENSIVE – we’ve got the space for a big TV, and I’d like to spend my money on something big rather than something thin.

I’m still figuring out what the impact of HD ready or not is. What I really want to know is: can I still use my TV in three or five years?

So we’ve resorted to shopping by remote control (more commonly known as the Internet). It wasn’t an entirely unsuccessful shopping trip – we did come home with 24 hours of Jack Bauer to waste the evening with.

Quality, Test Driven Development and Technical Debt

I really liked Mishkin Berteig’s recent post on why quality is not negotiable, especially the reference to paying interest on technical debt:

“As you accumulate debt, you have to make interest payments to maintain the debt. This shows up in the workarounds, the design cruft, the inelegant solutions, and ultimately in the slow down of the team in implementing new features.”

This is a great way to explain to the business why we’re investing time right now in becoming more Test-Driven.

Evildoers and guitars

I found Eric Sink’s blog recently through an intriguing link on Kevin Rutherford’s blog.

His post Thirteen Guitars about internet vandalism dates back to June, but it strikes a chord with me.

I was searching on Google last night for a place to buy a television. Amazingly, almost all of the sponsored advertisements are for price comparison sites that don’t actually sell anything (in this case, PriceRunner and Kelkoo). Although most spam is filtered out of my email, I don’t have automatic spam filtering on this blog and I’ve lost count of the number of spam comments that have been posted linking to mortgage sites.

As the internet continues to grow, I spend more and more time sorting through the clutter caused by people trying to make money by doing, well, as little as possible.

Judging by the quality of said spam, I’m inclined to agree with Eric that for many Internet Evildoers now, it’s not about the money but simply the annoyance and chaos that they cause. And unfortunately, like him, I don’t have any clue about solutions :(

More on Retrospectives

On Tuesday last week, I attended Rachel Davies’ course on Retrospectives. My overall impression of the course was good, and I came back with lots of new ideas to try. I’d definitely recommend it.

Along with the practical learnings, the key takeaway for me was that it’s not as easy as you think to facilitate a retrospective. You have to get the true picture from different perspectives and guide a conversation towards a meaningful end – while staying neutral (never easy) This is why activities are important, to uncover the things that won’t ever get mentioned in conversation.

My highlights:

  • Lots of relevant information and references for further reading.
  • Seeing the timeline activity in action – using coloured post-its for good / bad / neutral makes it work a lot better than all one colour. Rachel also takes it one step further and uses funky shaped neon post-its for the team to highlight areas of fun and stress. Although this seemed like overkill at first, it does illustrate trends.
  • Emotional timeline – it was great to actually see this work, again it’s something I hadn’t used and wasn’t sure on, but it really did show up the patterns well, even in the example one we used.
  • Watching other people, as always, makes me see things that I’m doing that don’t work so well – for example, how important it is to write down what people are saying and not what I think they are.

Not so great:

  • Powerpoint overkill, especially at the beginning – I found it a bit difficult to stay tuned for the first part of the session, and would probably have preferred handouts (paper or electronic).
  • Difficult to really demonstrate retrospective activities with a group of people who’ve only just met – more simulated situations or role-plays might have been better.

Before I went, one day seemed like enough to become an expert on retrospectives. As always, the more you know … the more you realise there is to know!

Agile Retrospectives – trying the techniques

This was previously posted on my old blog, Spike the Poodle. 

After reading my new (autographed!) copy of Esther Derby and Diana Larson’s book on Agile Retrospectives, this week I tried some of the ideas out in our team retrospective. I really recommend reading the book and trying the techniques, I’d be interested to hear about other people’s experiences with them. Ade Miller also highlighted some ideas this week, including an article from Industrial Logic.

Firstly, we had a clear goal for the retrospective rather than just continuous process improvement, which was starting to get stale. I started the retrospective by asking the team to sum up the Sprint in one word, which actually gave me a great insight (especially since I’d been away for most of the Sprint!) The team had come really close to completing all of the work they’d committed to, closer than in any previous sprints, and everybody felt that they’d nearly made it but not quite. The team seemed to like the exercise, and they’ve suggested using song titles or animals next time. I’m particularly intrigued by the song titles suggestion :)

We used a timeline to gather data. I drew the team’s burndown chart on the white board and asked them to record events that had happened on post-it notes and stick them against the relevant part of the chart. What worked well was asking them to think back through the Sprint about what had happened, but since the burndown chart was fairly flat it didn’t really generate a great discussion in itself. I think this activity would work particularly well with a spiky burndown graph.

I asked the team to stick red and green dots on the positive and negative events. The good thing about this activity is that you actually get some surprising results – some of the things that I thought were really bad, and might have devoted more time to discussing, didn’t actually have any sticky dots on. It really did make it clear what the significant events were, however there were a lot!

We spent quite a bit of time talking about what was causing the main issues, and eventually we agreed on two areas we wanted to address: how we manage bugs during the Sprint, including bugs that relate to the current stories as well as new bugs that don’t, and how we can do better at getting things done. We spent too long discussing the issues, but this was partly because we weren’t really sure before the retrospective what our main issues were – next time, I think we will have a clearer goal which will make the meeting more focussed. I also need to get better at timeboxing! We identified a list of solutions for managing bugs better, and then used voting to decide which ones we should use.

I asked the team to choose up to two solutions to try for the next Sprint, so that we weren’t making too many changes all at once. Interestingly, most people didn’t want to be limited to only trying two things and wanted to do them all at once. We compromised and identified three things to try over the next two weeks.

Next time, I plan to focus on what we can do to get better at getting things completed within the Sprint. This has been a key issue for us, and I’ve also spoken to people on other Scrum teams who have the same problem, so I do plan on posting updates on what we come up with! In the meantime I will also be attending Rachel Davies’ workshop on retrospectives, so hopefully our next one will go even more smoothly.

Agile newbies can still add value

I discovered today that even as a relative-agile-newbie, one of the most useful and rewarding things you can do is to try to help another Agile team with their problems. This is a scary concept: letting me and my limited experience with Agile loose to try and advise somebody else on how they can do things.

I’m spending this week working in our Bellevue office, with a group of my colleagues who are just starting out on their first Sprint. They’ve done the CSM course, and they’re just starting to see how quickly Scrum brings problems to the surface.

It’s actually surprising how much value even a relative-agile-newbie can add, particularly within a group of people who want to learn from each other. It’s a great experience, and if you get the chance to work with another team, try it (just make sure they can’t blame you afterwards). I’ve recognised so many things I’ve done, or still doing, that I want to change. I’ve spent time discussing the problems the other team are having, hearing other people’s views on the world, and it makes me think about what the agile principles are, what the Scrum rules are, and how I’m not following them as well as I thought. Things can slip out of your mind and trying to find the tools to solve other people’s problems helps reinforce them back.

The best bit ever is that I think I’ve actually come further than I realised. On the odd occasion, I’ve actually had an intelligent answer. Most of them may have been parroting what somebody else has told me, but this stuff starts to feel like it’s sticking. I’m still a Agile newbie, but I’m becoming an Agile junkie. I’m having fun with this.