Shared Values

Wow, time really does fly when you’re having fun – it’s 6 months since my last post!

I wanted to put a quick post up as I went on an amazing course last week run by Dave Laribee called Leading Lean\Agile teams – I’d highly recommend it!

I picked up a huge amount from the course and I fully intend to blog about it but there were so many good tips and techniques that I simply haven’t been able to get it all in a single post. So I thought I’d pick some specific areas and blog them individually.

So number one – Shared Values. I actually did this exercise when I was at uSwitch and it’s a way for individual teams to create a shared vision that they can all focus on while they’re working through their iteration and I found that it helped with team unity & shared buy-in.

So yesterday I held our latest iteration retrospective as normal and I ran the shared values exercise as the last item.

The team’s all got together around flip charts for 8 minutes and randomly wrote down words which reflected the values are important to them within their job. It was good fun and it really got the energy going in a room.

Once the 8 minutes was up, I got one of the members from each team to read out the values from their board – and we saw some of the old favourites like “quality”, “fun”, “innovation” as well as more unusual ones like “attractiveness”!

Next we used dot voting to get a shared set of values for each team. For anybody who doesn’t know how this works, each team member gets a number of votes to cast (e.g. 3) and they use their votes to place dots next to the values from the list which are most important to them. Once everybody is finished the 3 values with the most votes are the winners.

Finally, we took those values and used them to construct a value statement for each team, which we printed out & put next to their ScrumBan boards as a reminder of what they want to strive for everyday as they work. One good example was:

“As a team we will use our initiative to deliver consistent software with a high attention to detail”

As a first attempt I think we did well and I definitely felt that we got some great results so hopefully it will give the teams a better feeling of shared ownership over their process and attitude.

Until next time…

Getting rid of ExpectedException in TDD

Although my personal programming preference these days is towards BDD, I’ve spent the last few months teaching my new team traditional TDD because a) they’ve done a little bit of it before and b) we decided together that it’s a slightly easier entry point than BDD (I use a custom framwork for laying out my BDD so it’s a bit more involved).

So I’m back writing TDD and I’m a bit rusty but one thing that has bugged me in TDD for a while is the way NUnit provides built in support for catching exceptions – I’ve always found the ExpectedException attribute really hard to work with. Here’s a very simple example:

I don’t know about anybody else but I find this format very hard to follow and I’ve definitely had frustrations in the past with more complicated examples or when I’m trying to test more than one thing (i.e. Exception type, error message etc).

So I’ve recently been getting interested in some functional programming techniques and having done a bit of rudimentary reading I put together a helper class to handle these exception assertions as well as making them more readable/usable:

If you’re not used to functional programming this may look quite complicated at first glance but if you can imagine that the Action<T> parameter in the GetAssertionFailure method just represents an action that can be called on an object of type T (e.g. a method called FindLocation). And once you pass an object of the relevant type to the helper, it just invokes the method you’ve asked it to, catches the exception and then returns it wrapped up in a custom object.

Long story short it means that you can now write your exception test like this:

You can see the use of a lambda to represent the call to the FindLocation action with the invalid parameter and you can see how easy it is to access the returned exception and then implement separate asserts for each of the elements you want to check.

Feel free to shoot it down as it probably could be improved upon (I’ve been thinking about if I could infer the typeof(T) from the passed in parameter) but for now it makes our code cleaner & easier to read to so it’s been a good step forward.

Until next time…

TeamCity build agent(s) disconnected

More of a note for myself for the future but we’ve just moved office this week and it’s become apparent that our TeamCity continuous integration server hasn’t performed a build for the last 5 days (over the weekend). Despite the TeamCity tray notifier reporting that TeamCity was connected & working correctly, upon closer inspection the build agent was in fact disconnected. Looking at the TeamCity build agent administration screens didn’t help either as it’s not immediately obvious what needs to be done to reconnect the build agent.

It turns out that when we moved the server to the new building there were still some teething problems with the network and the build agent didn’t register itself correctly on server startup.

Restarting the build agent service (or rebooting) easily resolved the issue & we’re now back up & running (with only 1 build error thankfully!)