Creating a 4 P development strategy

October 17, 2010

This week saw the first anniversary at my current company – wow, what a rollercoaster ride it’s been implementing Agile over the last year!

I won’t bore you with the details but we’ve come such a long way in that year, most notedly implementing:

  • a new ScrumBan development process
  • test driven development
  • pair programming
  • continuous integration
  • automated deployments
  • automated acceptance testing

So what’s next? I’d be foolish to think I’m finished because even the best development environments still have areas of improvement, ways they can change their code, practices and processes to increase productivity and deliver more value. And with my new boss coming over from the US this week I began thinking about what I want to achieve over the remaining months of this year and into 2011.

In my last post I touched upon a fantastic course I went to in August called Leading Lean\Agile teams run by Dave Laribee (incidentally it looks like it’s running again in November so I’d recommend any Development Managers out there sign up now!). This post isn’t about anything Dave specifically covered in that course but his approach did get me thinking about how I could create a development strategy for 2011.

The underlying structure of his course centred around 4 key areas:

  • Products
  • People
  • Process
  • Practice

So when I sat down to begin my “strategic thinking”, a light went off in my head about how I could approach it. I took each one of these 4 concepts and I began creating mind maps for them, putting together topics and sub-topics where I could see improvements being made and what new practices or technologies could make a real difference. And after only an hour I had a blueprint for a development strategy that I could work with – it just needed fleshing out with finer detail.

And that’s it. No tricks, no secrets, just a simple set of steps that made it very easy to create a comprehensive strategy – hopefully it will go down well with my boss!

And in true Agile fashion, I’ve been retrospecting over this process itself to see how I could improve upon it so next time I think I might involve my senior developers in the mind mapping sessions and I’ll definitely be recommending we do this to my Head of IT Operations as the concepts are identical. In fact I could see this process working within any department so it will be interesting to see how I evovle it throughout my career.

Anyway, enough from me, hope this was helpful.

Until next time…


Shared Values

September 9, 2010

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

March 23, 2010

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

March 23, 2010

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!)

.Net evolution towards Lambda expressions

January 14, 2010

When I was at uSwitch we used to have a weekly brown bag session whereby a volunteer would give their time to do a presentation on a new or useful piece of technology that they could share with the team. I remember one such session which I enjoyed a lot by Mike Wagg about how Lambda expressions came about in .Net as it helped me understand exactly what they were for.

When I joined my new company, I decided I wanted to implement similar sessions to help the guys to do the same here i.e. learn new technologies and share best practices within the team. So I’ve started running (almost) weekly Pret Sessions (because we have a Pret a Manger just nearby & it’s the easiest way to quickly pick up some lunch & still do a session). We’ve had a few sessions on TDD & Web development tools but last week I was asked to run a session about Lambdas so I did my own interpretation of Mike’s topic and thought I’d blog about it in case anybody else found it useful.

So here goes.

The first thing I did was set up a Unit Test project (of course – anyone who knows me knows I’m a TDD/BDD bore!) and then I created a simple class called Delegator_Tests with a single test:

I decided to test a very simple function for the demo so I created a class TDD style called Delegator with a method called AddTest which just took 2 parameters and tested the method added them together (note that my should_be_equal_to notation is just a BDD style extension method inspired by my time at uSwitch – it’s the same as Assert.That(result, Is.EqualTo(3)).

Using the Red/Green/Refactor mantra I ran my unit tests – Fail – of course it did, I didn’t implemented any functionality. I amended the Delegator class:

and re-ran my tests – Pass – Hooray.

I started to refactor by amending the Delegator code to use the delegate notation introduced in C# 1.x. A few of the guys in the group knew about this technique but hadn’t implemented it very often so it prompted some good discussion. In the code:

  1. I created a new internal delegate called Calculate with the same signature we needed for the method
  2. I moved the existing addition to an internal method called AddNumbers
  3. I created an internal variable delegate called add, passed the internal method in the constructor and then called Invoke to return the delegated value.

And re-ran my unit tests – still Pass – Hooray again!

The general feeling from the example was that it seemed like overkill – which or course it is for such a simple example – but I stressed that I was trying to demo how delegates work and we discussed other uses for this type of functionality.

Once everybody was happy I refactored the code again to reflect the changes which occurred in C# 2.0:

  1. I replaced the concrete instantiation of the Calculate
  2. delegate with an anonymous delegate with the same signature

  3. I removed the AddNumbers private method and brought that functionality directly into the anonymous method
  4. I then just returned the add delegate with the original parameters

And of course re-ran my unit tests yet again – still Pass – lots more Hoorays!

This went down ok with the group, everyone seemed to be grasping how we can use delegates in this way. So after a few more minutes discussion we moved onto how this notation evolved to a Lambda expression in C# 3.0:

One final unit test re-run and as we’ve come to expect – still Pass – one final Hooray!

This is obviously even less of a jump from anonymous delegates and so everyone was happier with this. It prompted some final discussion on the lambda notation and then moved towards using generic Action<T> classes to help delegate responsbility even further by allowing lambdas to be passed around through parameters.

So that’s a very quick overview of how the .Net framework evolved towards Lambda expressions. It was an interesting session for me to run and hopefully my guys learned at least the basics – I’m looking forward to seeing lot’s more Lambdas in our code base!

Until next time…

Where has the time gone?

January 10, 2010

So it’s early January and I’m fast approaching the end of my 3 month probation at my new company. It’s been a great start to my step up to Chief Developer and despite being very challenging it’s been a lot of fun.

Hence why I haven’t written anywhere near as many blog posts as I would have liked – I’ve been way too busy actually implementing agile and simply haven’t found the time to write up what I’ve been doing. But in a nutshell we’ve:

  1. introduced retrospectives to understand better the areas we can improve
  2. agreed with the business to introduce fixed 2 week iterations (starting next week)
  3. split our original larger development team (10) into 2 smaller teams to promote better code ownership and provide less context switching
  4. relocated the team members and QA slightly within the space to improve communication across the teams
  5. cleared up our storyboards to reflect the new team structure
  6. improved our user story writing and given more focus to writing acceptance criteria
  7. taken steps towards writing automated regression and acceptance tests
  8. simplified our source control strategy
  9. introduced unit testing – specifically TDD with TestDriven.Net & Resharper templates
  10. built a new TeamCity continuous integration server
  11. introduced lunchtime learning sessions to improve everybody’s skill sets by sharing best practices

So we’re making small steps down the agile road and I think 2010 is going to be a pretty exciting year for us. We’ve got a lot of exciting plans and a lot of drive to see them through so we’ll see how things go.

I will attempt to post more often on here about the specific practices we’re using and I have in fact got 4 posts already in draft which I simply haven’t finished yet so I’ll endeavour to get those out before the end of the month.

But until next time…

Agile revelations part 2

November 21, 2009

My last Agile Revelations post was an unexpected foray into the reasons behind why I love Agile so much. Written on a Friday night, a bit bored, it started me thinking about my career in software development and how I got to this point in my life.

So if you weren’t put off by my previous post and are still interested in what motivates people like me to pursue this most rewarding of methodologies then read on……..

So where was I? Oh yes, I was still in my first development job and I’d just finished reading Extreme Programming: embrace change by Kent Beck – the book which single-handedly inspired me to take on Agile. I’d been in that role for about a year by the time I finished the book and at around the same time I completed my full MCSD in my spare time. And it was lucky because within a month my company had no more C# work for me (they’d decided to re-write in java) so I took a junior C# developer role with a new company.

The development work there was challenging for a relatively in-experienced developer so I found it hard work implementing real WinForms and ASP.Net Web applications into production, but the hardest thing about it was that between projects there was a lot of “sitting around time” where we would be waiting for work (read spec documents as it was a classic waterfall environment!). This was so immensely painful as I hate being bored, having to pester people to give me work to do so in the end I used this time to improve my development skills and learn more about Agile.

The funny thing is that nowadays “being Agile” is such a buzz word and everybody and his dog is claiming that their company is doing it. But at the time it still felt very new (well I guess it was in the UK) and it wasn’t enough to just read buzz word books about XP – I wanted to learn the coding principles behind Agile and understand what made these programmers (apparently) so talented.

So I spent loads of time reading blogs, researching who was saying the most about Agile and XP and (to name but a few) I came up with some very well known writers on these subjects: Martin Fowler, Kent Beck and my own personal God Jeremy Miller.

I quickly realised that an Agile methodogy is useless if you don’t know how to write quality code so I started buying books which concentrated on improving development skills and writing clean code, here are just a few I started out with:

Refactoring by Martin Fowler
Test Driven Development by Kent Beck
POEAA by Martin Fowler
Head first Design Patterns by the Freemans
Applying DDD by Jimmy Nilsson

And that was how I spent my 2nd year in software development. It was an interesting time and for anyone just starting out I would definitely recommend these writers (and obviously a whole load more now – you’ll have to wait for part 3 for those!). The only caveat I would say is that these guys are so good that I did sometimes feel out of my depth, thinking I would never be able to write code as well as them (which is probably still true but I do at least now try!). I think this was probably a very natural reaction but to counter it I would recommend that rather than just reading about the concepts, try to implement them as often as you can in production code. With that said, the best way to ultimately learn is to find an environment with technically excellent, like minded people, eager to learn the same values and able to implement them in production.

Enter uSwitch stage left 🙂

Until next time…

Daily stand ups

November 17, 2009

Hi again

I haven’t blogged for a while as I’ve been manic both at work (implementing agile – obviously) and at home (decorating until 1am most nights) but I thought I’d put a quick post up around a topic we’re talking about here.

So we already have daily stand ups at the moment but I’m re-jigging our teams and I thought it was a good opportunity to put a quick post out explaining what I consider to be a good format for a daily stand up.

Key Ingredients

I think as a minimum they have to:

  1. Be short (approx. 1 min per person)
  2. Take place by your scrum board (wherever you keep the workload – the visible representation of your current user stories)
  3. Involve any relevant members of staff for the current stories being worked on. This for example should include:
  • the Project Manager
  • the developer(s) working on the stories
  • the business owner(s) of the stories
  • the QA(s)
  • A. N Others (see Pigs and Chickens)

What is a daily stand up for?

It’s an opportunity for the participants to update how the currently in progress user stories on the scrum board are going. It isn’t just an update for one person (e.g. the Dev or Project Manager). For example:

  • Developers tell everybody how the development of a user story is progressing
  • Business owners can get an understanding of when their stories might be finished
  • Project Managers can use the scrum board to remind business owners new user stories are coming up and to ensure they’re ready to work on
  • Senior management can see how the team interacts with each other.

What’s the format?

  • A stand up will tend to happen first thing in the morning (although some organisations have two – one in the morning, one at lunchtime)
  • Typically the participants stand in a semi circle around the scrum board, looking at the tasks currently in progress.
  • Somebody volunteers to speak first (it can be different every day, it doesn’t always have to be the same person e.g. Dev Manager, Dev lead or PM).
  • They describe three things:
  • What they did yesterday
  • What they’re planning on doing today
  • Whether there is anything blocking them
  • This will inevitably cause discussion with various other members of the stand up (e.g. a business owner asking why their story is in the blocked column). It’s obviously very useful to do this to flesh out any issues coming up but don’t allow this discussion to get too extensive – if the meeting begins to digress or gets too technical take it ‘out of the stand up‘ and discuss it further once the meeting has finished
  • Once one person has finished speaking move to the person on their left and repeat the process (or the right or even use a speaking token to randomly select people)
  • If a participant hasn’t been working on any of the currently relevant stories it’s perfectly fine for them to say ‘Nothing to say‘ – in my experience business owners typically opt for this if they’ve nothing to add.
  • Once everybody has finished and there are no more questions everybody can disperse and continue with what they were doing.

It’s not a hard and fast set of rules and it’s not a huge variation from what we’re currently doing but it’s nice to have it down so we can refer to it in the future.

And I’m sure I’ve missed some very important points so feel free to pick holes in it – I’ll probably update it.

Until next time….

Hi again

I haven’t blogged for a while as I’ve been manic both at work (implementing agile – obviously) and at home (decorating until 1am most nights) but I thought I’d put a quick post up around a topic we’re talking about at the moment.

So we already have daily stand ups at the moment but I’m re-jigging our teams and I thought it was a good opportunity to put a quick post out explaining what I consider to be a good format for a daily standup.

So what are the key ingredients of a good stand up? I think as a minimum they have to:

  1. Be short (approx. 1 min per person)
  2. Take place by your scrum board (wherever you keep your visible representation of your user stories)
  3. Involve any relevant members of staff for the current stories being worked on. This for example should include:
  • the Project Manager
  • the developer(s) working on the stories
  • the business owner(s)
  • the QA(s)
  • A. N Others (see Pigs and Chickens)

Start with continuous integration

October 2, 2009

Hi all, it’s been a few weeks and there’s been quite a lot going on chez Harrington.

My last day at uSwitch has come and gone and I found it harder to leave than I thought I would. They have an amazing group of developers and managers and it’s still a fantastic place to work but ulitmately I think it was time for me to move on. Incidentally, for anyone reading this, if you get an opportunity to work there then grab it with both hands!

So I’ve had some time off as I don’t start with my new company for another 10 days (after a well deserved holiday in Lanzarote) but I did want to catch up with them before I went away so I headed over to their offices for an afternoon this week.

My first impressions of the company, team and general set up was excellent – a friendly bunch who clearly want to make their software great. The developers working there seem like good guys, skilled and eager to pick up Agile practices and processes and I’m really excited about seeing how far we can take Agile.

So where will I start?

Well, I’m not going to give my entire game plan away (gotta keep the reader interested for future instalments) but I’ve got a whole barrel load of ideas around Subversion branching strategies, TDD (test driven development), BDD (behaviour driven development) and of course continuous integration.

Of these I think (and it’s an opinion shared by a lot of my colleagues) continuous integration is the obvious starting point when trying to make any shift towards agile. Because once you’ve got it installed and running, you’re always aware of when your build breaks due to subversion merging issues. And once you start to introduce unit tests, you’ll get real time feedback if you’ve broken any logic in your code. This is the foundation you need in order to have confidence in your system moving forward, allowing you to continue to work and refactor as you need.

So we’ve ordered TeamCity for our build server and I’m planning on learning more about Rake as our build language as it is clearly more flexible than NAnt and I’d like more of a chance to learn Ruby. On a side note we’ve also ordered ReSharper as our refactoring tool (because Visual Studio is essentially unusable without it).

All in all, I’m confident these tiny changes will give us the start we need to take our first steps down the agile road. There’s a lot more we can do but as the cliché goes, I’m not going to try and run before we can walk.

I’ll keep you updated on how we’re getting on.

Until next time

Agile revelations

September 11, 2009

I wasn’t expecting to write another blog so soon but I don’t like Jonathan Ross whereas my wife loves him so I thought I’d sit down at the computer and put some of my thoughts down on why I like Agile so much.

Right from the start I found I was interested in Agile. It was 2004 and my first dev role was perfect – my company took a gamble on me and with my recently passed MCAD certificate in hand I moved from our 2nd line support department into the dev team – housed in the mysteriously quiet room on the second floor, away from the ‘real’ employees of the company. No-one dared enter there without extremely good reason and nobody ever spoke without getting odd glances.

I had no experience but no major responsibilities either to produce anything other than an (albeit complex) internal test system. It left me with plenty of time to learn as much as I could about C# although without the internet at work or at home (I was a very naive developer for the first year!) I found the going tough. Fortunately I met a good friend and fellow west ham supporter who gave me some pointers on this new idea of ‘Agile’ (although I didn’t know at the time that some of the concepts had been around for at least a decade – and Lean, well who knows how much longer).

So he recommended Ron Jeffries’ Extreme programming adventures in C#. It was a good read although very basic looking back but it was probably the best kind of book I could have started with. It gave me a decent introduction into TDD and the basics behind how to actually create elegant working software rather than the random hacking I had been used to. It certainly piqued my interest so (still with no internet) I went to a bookshop in Leicester Square and asked what the ‘best’ Extreme Programming book around was. They pointed me in the direction of Extreme Programming Explained: Embrace Change by Kent Beck. I spent about an hour in that bookshop reading through the pages, comparing it to all the other ‘Extreme Programming something‘ books until I finally decided to buy it (see how decisive I used to be :)).

Anyway, (you’ll have to excuse my long winded route to this point as the kids are in bed and I’m a bit bored) it only took a couple of train journeys and evenings to get through that read but it sold me on XP and Agile forever. I loved the concepts that it represented – that you should embrace your development in the same way you embrace life. Enjoy your life (development), constantly challenge yourself to learn new and interesting things in life (and development – you get the gist). Get to work on time, work hard on interesting tasks (but taking a full lunch hour to rest your brain) and leave on time so you can go home to your wife, kids or whatever else you have that makes you tick – that makes you the person you are. And there was the revelation. Only a few months of struggle into the world of programming and I’d already found an ethos I could live my life by but also work by.

So I took those concepts and I tried to become a better person and programmer. I’m obviously prone to the odd outburst or off-day the same as anyone, but hopefully my colleagues will agree that I at least try to be like this as often as I can and that I actively encourage others to be so too. Ultimately all I really want is for people to enjoy their life, enjoy their work and produce good quality code they can be proud of.

A good friend I work with at uSwitch has often told me that you ‘can’t constantly overachieve’, that sooner or later you’re going to have to pay back all those late nights you spend in the office just to hit a deadline. It’s ok to do it occasionally, but make it the exception. I’d much rather my staff go home at 6pm, enjoy their evening at home and be back at 9am, the next morning refreshed and raring to go. In the long run they’ll produce much better quality software.

Anyway sorry, I didn’t expect that post to be so long and I promise it will be more techy in the future but it gives you a flavour of who I am and what I’d like to achieve – hopefully there are plenty of like-minded people out there who feel the same.

Until next time