Ode to Tobias …

OK, OK … I admit I have been slack in writing in the blog. I actually have a pretty decent excuse though: I was busy sunbathing in Barcelona last week (what do you mean, that doesn’t cut it?)

So I promise to do better this week and find something interesting to say. Especially since it has emerged that spiking the poodle is not a concept unique to our scrum course … and if there are any new ScrumMasters from the Santa Barbara course actually reading this … hello

Weekend in Barcelona

I spent last weekend in Barcelona on holiday. I’m gutted we only had three days, it wasn’t long enough to really see as much of the city as I’d like, it’s a fantastic place (would definitely recommend to anybody who hasn’t been!).

I met my friend who had been attending a conference and we stayed in the Hotel Arts, which is a super-posh hotel so we were pretty spoilt I spent Friday morning lounging by the outdoor pool and clearly didn’t realise quite how hot the sun was, because I ended up a little sunburnt! Unfortunately this meant I was restricted to wearing the same t-shirt for the rest of the week … (joke … but I do have white lines!)

We walked along the beach in the afternoon and I went paddling – the water was COLD! We also went around La Catedral in the afternoon, which was nice except that it is currently covered in scaffolding. We visited the Aquarium – the shark tunnel is amazing, particularly the manta ray that smiled at us from above … very freaky.

Saturday the weather was once again glorious and we started off with Parc Guell … one of Gaudi’s amazing and slightly strange works of art in the city (I now have a model of the mosaic dragon on my desk …) It really is a beautiful place to go, especially recommend climbing to the top of the hill to get a view across Barcelona. We were really lucky that the visibility was so good, and have some great photos to show for it!

We visited Casa Batlla (another of Gaudi’s “hallucenogenic creations” – as described by the Lonely Planet guide!) – fascinating but very strange house. Well worth seeing and the audio tour was interesting if long winded. Worth mentioning Cervezeria Catalana where we had tapas for a rather late lunch, as well as Cacao Sampaka where we gorged on hot molton chocolate … mmm!!

The time seems to go so much quicker in Barcelona, I couldn’t believe it was nearly five by the time we finished … so we walked down La Rambla where there was an odd procession of very tall people We finished off the day with a nice meal, very late in true Spanish style … then following rather a large amount of wine and beer decided to spend an hour or so in the (outdoor) hotel jacuzzi! With more beer … finally made it to bed around 4am but well and truly missed breakfast the next day.

On the last day we went to see Sagrada Familia (Holy Family in English) – the church that has been being built since 1882 or thereabouts. It’s absolutely awesome for the sheer height as well as the fact that amid the amazing pillars and architecture it is a real building site. Yet again Gaudi got his hands on the architecture, and when he was asked why he put so much effort into the design of the tops of the pillars when nobody could see them, he replied that the angels would. After so much walking and sight seeing all I wanted to do was sit down and eat more tapas before leaving for the airport!

All in all it was an amazing weekend and definitely a city to be seen and experienced! Can’t wait for my next trip.

Human quirks make timeboxing work …

I’ve heard dozens of good reasons for time-boxing iterations, or Sprints, since I started reading up on agile methodologies, but found some real food for thought in Craig Larman’s book Agile & Iterative Development.

Parkinson’s law states that “Work expands so as to fill the time available for it” … something I’ve definitely experienced myself very recently! The flip side is that where there is a specific timebox, work can and will fit in (up to a point, obviously!). Personally, I know this is true for me – I work faster and am more motivated if my work has deadlines.

Expanding work wasn’t such a new concept for me, but the second point was something I’d never considered before: “People remember slipped dates, not slipped features”. Deliver on time with 75% of the features, and the project will be remembered as a success. Deliver a month late with 100% of the features, and it will be considered a failure. Strange quirk … but I can identify with it!

Can you estimate tasks as zero?

In an excerpt from Agile Estimating and Planning by Mike Cohn, I came across an idea I hadn’t heard about before: using 0 to estimate really small items.

Although we haven’t started estimating the items in our still-in-creation Product Backlog yet, I am intending to try the Planning Poker technique using the Fibonnaci number sequence to estimate the size of each item. In the book, Mike Cohn suggests including 0 in the estimation scale. Sound crazy? It did when I first read it!

But read on … it does have benefits:

If all estimates must be within a certain range, assigning non-zero estimates to tiny features limits the size of the largest features.
If the work to do something really is that insignificant, assigning a 0 to it will avoid impacting the team’s velocity. Assigning a 1 may mean they need to undertake some more significant task to make the same velocity in a later sprint.

Assigning 0 could work as long as everybody on the team recognises that it’s a “free lunch” – and like free lunches, the number of 0 tasks in an iteration must be limited – it’s not an excuse to sneak in lots of extra tasks. 10 x 0 ≠ 0 in reality.

I plan to try this – but if it doesn’t work, I also like the alternative of grouping a number of tiny tasks into a something big enough to represent a 1. Either way, it will be interesting to see how the team accept it.

Should we crop the Product Backlog?

I have been following an interesting discussion on the scrumdevelopment group about whether the Product Backlog should be a complete list of every feature that the customer ever wants, or whether it should be cropped to a certain length to prevent wasted effort spent estimating items that will never be high enough priority to get to the top of the list.

It’s especially interesting to me as I’m trying to work with our product owners to construct our first product backlog as we move towards using a more agile approach for a new project, and this was a question that was asked at our organisation.

I’d been of the opinion that the backlog should represent everything our customer would want if they could have it, and that’s currently how I’m approaching it.

Our product owners represent a large number of internal customers. It’s a long term project and the people who are the customers will change over time. The scope of the project is limited, but will expand, as we are building on top of an established system.

Previous experience suggests that many ideas for features are raised by different people time after time, and I believe they should be stored somewhere so that people can see what’s been suggested previously. Reviewing the old ideas helps to refine them, and I want to feel that we are progressing, and not have the same conversations over and over.

I want to be able to show people why the thing they think is important has not made it into the priority list yet, by showing them what is ‘queued’ in front of it. If ideas come up over and over then perhaps we will start to see the ones that need to move higher up in the priorities.

I also believe that all of the items on the wishlist have some value as ideas. Each item represents some level of effort in the thought process or whatever event generated the idea in the first place, and crystallized it to the point where it could be described as a feature.

The discussions on the thread, however, made me question this. On a long term project the value of the “ideas” can decrease over time as the market changes or features become less relevant. Is this “depreciation” really “waste”?

After reading many different opinions, I came to the conclusion that I still want to maintain a product backlog that is a really big wishlist – but ensure our team also recognises some things that could cause us problems.

We will need to take care not to focus too much time and effort on the items further down the list – otherwise they really will start to represent waste – in wasted effort spent estimating or planning things that may not ever happen, or by the time they do will have changed scope.

I was encouraged to hear stories from people who have taken this approach and found it works – that the items at the top are naturally the ones that get the most focus. I hope that by sticking to time-boxed meetings we can also achieve this.

One thing I also intend to do is to ensure that any items that fall out-of-scope, or that we determine really are no longer requirements, are religiously moved off of the product backlog by the product owners.

My one remaining concern is the impact of an ever increasing backlog. Somebody mentioned the “Someday” folder suggested by David Allen in Getting Things Done – the one that tends to grow the fastest with things that never really go anywhere. Yet how many of us are brave enough to just dump it? I’d bet most people are too worried to ever throw away ideas in case they don’t come back when we really need them.

If the backlog continues to increase, it should be an indication that we need more teams – but if it increases too quickly, or if this isn’t an option, what impact on team morale? With everybody having visibility into what we haven’t done, as well as what we have, will this be seen as a negative? This could be a real problem, and it’s one I’ll be watching out for. No doubt there will be many others that I haven’t even considered yet … and I’ll keep the blog updated with progress as we try it out!

Waterfall 2006

For all software developers, if you haven’t already seen the Waterfall2006 site, it’s well worth a read. On first glance it almost seems like a credible site, until you start to read the detail … and having worked with a waterfall approach on many projects, it definitely made me groan with recognition! I’m hoping to see first hand in the near future the difference that agile techniques can make, but in the meantime some of the highlights of the Waterfall site that made me smile:

  • Pair programming – two managers per programmer
  • Registration – “Our software developers have a really wonderful design. They’re almost done entering it into it a UML tool. They’ve told us not to worry and that finishing it will be “trivial” because “all that’s left is the coding.”
  • A Document Testing Framework
  • Skills in Stale Specs

I could carry on, but I’ll spare you … it’s good to know that I wasn’t alone in thinking there must be a better way …