Are we Agile yet?

So I was lucky enough to attend an Agile Fundamentals talk hosted by Steven List of Thoughtworks. Like a lot of companies we've been doing our own version of Agile for a while and thought it would be an idea to send a few guys to the talk and revisit the basics to refresh ourselves with the core fundamentals.

Cracking talk - Steven was a great speaker I jotted down a few notes and thought it would be an good to get them on here.

Agile manifesto:

http://agilemanifesto.org/

So you think you're Agile? So did we. Then we looked into the Agile Manifesto:

Individuals and interactions OVER processes and tools
Working software OVER comprehensive documentation
Customer collaboration OVER contract negotiation
Responding to change OVER following a plan

I don't want to go into all the Agile background, founding members, etc, etc and I certainly don't want to turn into the Agile Police but it's worth highlighting that the items on the right are important there's no doubt we need them and will use them if and when required BUT the items on the left are much more important. That is if you want to get the full benefit of using Agile. Any time we lean towards the items on the right it's worth someone whispering "but that isn't the Agile way". Someone should do an app for that.

Which 2 goals do you want?

http://en.wikipedia.org/wiki/Project_triangle



The project triangle. I loved this. What I like about Agile is the bluntness of it all. It's very open and transparent so we're not fooling anyone. If you want the project to be cheap and quick then it won't be good quality. If you want a product quickly and of a high standard then it won't be cheap. Of course you can always go for a high quality product that is cheap - but it won't be quick.

One of these factors WILL ALWAYS SUFFER. Think about the 2 goals your team wants to aim for and stick to them. "Two out of three ain't bad" [Meatloaf, 1977]

Bugs are things you find in the garden

http://www.agile-testing.info/defect-inventories/

Ok maybe I've exaggerated the point but whatever it's called or however we phrase it a bug, a defect, an issue it's all the same thing - a change to the working code. And that's exactly how we should treat them. Write a new user story put it on your board and into your backlog. If it's urgent then prioritise it at the top. Next iteration it's fixed. Job done.

Also Steven discouraged the use of bug tracking software. Or more accurately he suggested if QA or the team want to use a bug tracking system that's fine as long as there is also a user story that address the problem on a wallboard. This mirrored my experience with bug tracking software. Everyones bugs become vital (showstoppers) and any trivial bugs have a tendency to get left untouched.

More us less them

http://jamesshore.com/Blog/The-Crucible-of-Great-Teams.html

Some points in the talk reminded me how good it is to work in an Agile team. I'm not talking the dev team I'm talking about the whole team - product owners, PM's, BA's, testers the whole schabang. Not all of us will have (or want) the full set of roles to make up an ideal Agile team but however your team is setup the main principle is that the team succeeds or fails TOGETHER. It's not John's code, Neal's test or Adam's web service. It's our code. Our product.

It's very obvious to say but working as a team errrm works! Want more productivity, looking to improve quality? Have the team sit together, encourage collective ownership, use activities to help them bond and ask them to find solutions within the team. You might be surprised. As Steve put it during his talk "STOP BEING A HERO".

Home improvements vs code improvements

So I've been a bit of a DIY guru at the moment and managed to get a few rooms from our flat refurbished. Surprisingly it's not that interesting when you're painting a wall (slightly better than watching it dry) and my mind started to wander about similarities with how we approach home improvements and how we can approach code improvements.

Yeah ok bear with me this might all be rubbish you can blame it on an access of paint thinning fumes. These are in no particular order but hopeful someone can appreciate what I'm try to say here:

1. Plan it and do it

So I figured I'd hit the bathroom first... probably the hardest of the 3 rooms I was doing and also the one with the most work. But the number one reason to do the bathroom - I had to get it done. The spare rooms could wait but was no way we could last any longer with a crappy shower and toilet (no pun intended).

Comparison? Whenever our dev team is handed a problem we always break things down into features and prioritise them in order of value - what can't we live without? If we nail this feature will it set us up nicely for the next one?

Team discussions around features are generally pretty short, same with DIY - discuss, plan and give it a go. No messing. You'll soon realise the plan is flawed or the tools you are using don't work.

If that is the case - stop. Don't waste any more time. Catch up with your team and think of a better way to produce the feature.

2. It's all in the preparation

I can't believe how often this was said to me by other people who were lending me a hand - "Make sure you sand that down before you paint it", "If you want a good finish make sure the prep is done well first". And they were right.

I see acceptance and unit tests as preparation for a feature. If you want a good 'finish' get the tests down first. In development there are times when we don't know how to test or even how we're going to solve a problem. That's ok, spike some code and get things straight but as soon as you can make sure you revisit and plug in the tests.

3. Look to improve

The reason I was so busy trying to fix our flat up was because I let things slip - the equivalent of technical debt I guess. Had I kept on top of things while I lived there I wouldn't have had to refurb 3 rooms in one hit.

Same with code - don't let that technical debt build up, tidy as you go. It's very rare a dev team is allowed free reign to clear technical debt so let's be up front and if we see something we can fix, fix it. This does come with a big but... BUT make sure any refactoring or improvements are fully tested ideally with acceptance as well as unit tests. Ensure you are improving code and not causing more issues for someone else.

4. Use external sources

The really bad thing about home improvement is the cost. Wow it's expensive. So I tried to do as much as I could myself but there were things that I just couldn't do. Plastering and plumbing for example. Nightmare - so I gave the job to someone who knew how to do it properly.

Going back to code, is there something that can do this feature better than you can? I'm reminded of companies who build their own CMS or blogging system. Why? Use Drupal, Wordpress, Blogger or any other application that has a good reputation within that area.

Don't be afraid to use an expert if it's quicker, cheaper or just a real a bitch to do yourself.

5. ALWAYS add value

Whenever a feature is discussed ask the question:

'What's the best result we can achieve for the least amount of time and money'

That's the reason we look after our property so why should code be any different. I'm no property expert but I'm pretty sure the amount of time and money I put into our home improvements means the value of our property has increased.

Can we always say the same about the features we produce?

Beware Structure Map - use lazy loading!!!

Our team recently discovered a problem when a site we were responsible for crashed whenever a particular third party web service died. We were wrapping the web service call and catching any errors as is good practice but after 2 crashes in 6 weeks it was necessary to investigate further and we eventually traced the problem back to the Structure Map registry.

We figured the registry was set up to initialise an instance of our service wrapper on startup so if the third party site was down and our site restarted (via IIS presumably) it couldn’t create an instance of the service wrapper and the whole site would fall over.

var serviceWrapperConfiguration = new ServiceWrapperConfiguration(
new Uri(AppSettings.ServiceUri));

ForRequestedType<IServiceWrapperConfiguration>()

.TheDefault.IsThis(serviceWrapperConfiguration);

ForRequestedType<IServiceWrapper>().TheDefault.Is.ConstructedBy(context =>
{
var configuration = context.GetInstance<IServiceWrapperConfiguration>();
return ServiceWrapperFactory.Create(configuration);
});

Although this was highlighted due to an external dependency it’s good practice for all Structure Map registries to use lazy loading so once we uncovered the mistake we rewrote the registry to only create an instance when required:

ForRequestedType<IServiceWrapperConfiguration>()
.TheDefault.Is.ConstructedBy(() =>
new ServiceWrapperConfiguration(
new Uri(AppSettings.ServiceUri)));

ForRequestedType<IServiceWrapper>().TheDefault.Is.ConstructedBy(context =>
{
var configuration = context.GetInstance<IServiceWrapperConfiguration>();
return ServiceWrapperFactory.Create(configuration);
});

This was tested throughly by pulling out the network cable on a PC so we lost connection to the third party service and loading the site locally. We were able to step into the website straight away so we're quietly confident this is no longer a problem - worth remembering when setting up Structure Map registries though.

Bored of Arial and Verdana? Use Cufon...

Cufon is a cool way to render fonts that are not native to your users system. It's really handy if you want your headers to pop a bit more or for brands that use a particular font in their logo and want it used across other areas of the site.

When I first saw Cufon the frontender in me said why not just use images. Then I realised it really comes into it's own when rendering dynamic content. It would be much easier to render text and get Cufon to transform it rather than assign images that would need to be updated each time the content changed.

So what do you need to do to get up and running with Cufon? First of all download the Cufon script file from Git (the source also comes with documentation and HTML demos) - http://github.com/sorccu/cufon.

Then you need to grab your TTF font file (other fonts types are supported so check the site for more info) and generate your font script - http://cufon.shoqolate.com/generate/.

All that's left is to use the Cufon.replace method to specify the HTML element that you like to transform, for example:

Cufon.replace('#content-wrapper p.cufon-me');

I created a quick example with a free font called Cube but I did notice some cross browser issues with IE6 in particular. Make sure you include a jQuery file on your page and call $(document).ready. Without it in this example Cufon doesn't work in IE6 (you'll probably need IETester to verify that!).

My first TeamCity build monitor

I'm quite surprised at the lack of decent TeamCity build monitors on the web. Maybe it's because TeamCity incorporate an email and tray notifier with the system but I always find them easy to ignore, easier to ignore than a mahossive build monitor screen at least.

After googling a few keywords around TeamCity build monitors I did find some that were plain overkill, while TeamCity itself comes with a status widget which gives you a pretty standard javascript output for each build.

The TeamCity status widget was interesting, unfortunately it was also really detailed and unappealing BUT it could be modified to display the information I was looking for - something visual that I could put on a screen telling the team when a build failed and if anyone was looking into it.

First of all I enabled the TeamCity status widget for a couple of builds:



Then I played about with some clever jQuery (more clever than I am) to make the page auto refresh whilst rejigging the layout to show only those things we were interested in. Now I've got some cool features to show off!

• Every 10 secs the build monitor refreshes itself getting the latest TeamCity build information.
• If all the builds are good the build information is hidden and a green background image is displayed.
• If a build fails the screen turns red and the failed build gets highlighted. Some of the build data was unnecessary so most of it is hidden away except for the project name and link back to TeamCity.
• Finally if (or when) someone is assigned to a broken build we go and get an avatar for that person from the images folder (the image filename takes the format teamcity username.jpg).

To use this build monitor with TeamCity enable the status widget for each project (under 'Edit configuration settings' > 'General settings') and correct the build_monitor.html file by replacing buildsrv2 with your build server and changing buildTypeId to your own project id. I'm checking 3 different TeamCity projects but you can add or delete as many as you want.

I've tried to make all this customisable so add your own images, styles or enhancements as you see fit. I nearly dived into JsUnit to see if it helps write better JS but that's another blog post. Any refactoring or comments welcome - Download my first TeamCity build monitor here (1.18MB).