The long way round…

It’s been a long time since I’ve had time to post anything.  A lot has happened, most notably I moved house.  How painful is that! Being offline for 2 whole days really hurt me.  But I’m back with a fatter pipe providing me with copius amounts of bandwidth.

Anyway, during my downtime I read a great article by Alistair Cockburn on “Are iterations hazardous to your project?” And yet again Alistair is spot on.  There are many nuggets in this paper but by far the one that rings home for me is the age old problem of clients not having the time to accept iteration deliverables.  With no feedback, where’s the value.  Agile development is about delivering value.  If you are not doing that, you are doing iterative development NOT agile development.

Another funny thing Alistair alludes to is are the macho agilists.  I’ve come across a number of these and I had to laugh out loud on the issue of iteration length.  Alistair is spot on with macho agilists opting for very short iteration cycles.  Don’t get me wrong, sometimes very short iterations are the right thing to do in certain contexts, but in others i’ve seen them used to by macho boys to demonstrate experience and knowledge over an unworthy (read as less experienced) agile opponents (read as team members) .   

Anyway, I recommend taking 10 minutes out of your day to read this article…

Okay, I finished Agile Project Management with Scrum by Ken Schwaber. Damned fine book that I highly recommend. The neat thing about this book is that is it defines Scrum, start to finish within a single chapter, that being chapter 1. The remaining chapters demonstrate exactly what Scrum is with real life examples of projects applying Scrum: the good, the bad and the ugly. Ken pull this off nicely.

I am still coming down on the side of Scrum with a bit of XP, as opposed to XP with a bit of Scrum. The simplicity of Scrum, its clear and concise rules and practices, fit with the way I tend to run projects. I don’t know enough of about XP in practice, so I’ve decided to attend XPDay this November. Also, we just had the pleasure of Rachel Davies, the now chair of Software Practice Advancement 2007 (formerly OT) come out to our offices to run a number of XP sessions. Interesting stuff…

3 years ago I was contracted by ABN to build what ending up being a sales portal for their Fixed Income Business Unit. The team started out with just me on the sales side. I was both the Technical Architect and Project Manager and the team grew to 15-20 people by the time I left. So why I am telling you this?

I left because the team structure had evolved into something that I couldn’t work within. I loved the people, but when things are better without you, than with, you walk away. In the beginning, as the team grew I mentored and coached, held frequent team meetings to synchronise knowledge and status, we delivered frequently (despite clearcase) and were quite proud of our continuous integration build environment. The business defined value. We delivered it. The team structure was flat. Work was fun.

Then the business threw more work at us. Management reacted by adding more levels of management (sigh!). The team moved from a flat to a hierarchical structure. The once fluid communication with the customer stopped. There was a layer between us and them. My project manager hat was removed. I was purely technical architecture now (”thank’s very much cleve, we’ll take it from here…”). The team stopped having meetings. The team became individuals. The individuals reported individually to the new project manager. The team became dysfunctional in some respects but we had to continue to deliver software. That’s what we do. We just did it in a different way.

During this change in team structure, I fought to maintain the close collaboration we had built up with the customer. I fought to protect the team dynamic. I failed. The islands of developers (read as component groups) were formed.

Currently, I’m half way through a book by Ken Schwaber called Agile Project Management with Scrum. It is the book that I wish I had known about to give to my project management to read, to understand what I was fighting for and why it was so important to both the business and development teams. I basically failed to articulate the guidelines, practices and rules of Scrum in a way that made sense to both of us.

Ken, I take my hat off to you. The more I read about Scrum, its case studies and how ScrumMasters have applied it to the thousands of projects out there, the better I feel. I always thought it was mad to fight complexity (software) with complexity (high ceremony process and/or methodologies). Although outwardly Scrum appears simple (this is good a thing), its conceptual rivers run deep. I am looking forward to learning how deep…

After a day of getting FIT I was able to run the FitNesse wiki and poke around a bit and run some more acceptance tests.  This I found very interesting and quite impressive really.  It was truly simple.  So how do I write acceptance tests for my .NET applications.

The first step is understanding how a java based FitNesse wiki ran my .NET acceptance suites.  Fortunately this was pretty easy.  Under the fitnesse install directory their is a subdirectory called dotnet.  It the dotnet directory there is a .NET implementation of the FitServer that consumes test tables and communicates back results.  All we have to do in our wiki pages to tell FitNesse to use the .NET FitServer instead of the Java one to run our acception tests.  This is done by placing the following at the top of the wiki page that you write the acceptance test in:

!define COMMAND_PATTERN {%m %p}
!define TEST_RUNNER {dotnet\FitServer.exe}
!define PATH_SEPARATOR {;}
!path dotnet\*.dll

That’s it.  Then add the following test table to your page as well

!|eg.ArithmeticColumnFixture|
|x|y|plus()|
|10 |2 |12 |
|12 |3 |15 |
|100 |4 |104 |

The syntax is simple enough. 

• Line 1:  The test fixture to run, with eg.ArithmeticColumnFixture being a fully qualified class name 
• Line 2:  These are public members on the test fixture in first two columns, and the final column is the method that is called to perform the test.
• Line 3-5: These values are assigned to the test fixture members and  the plus() called.

This page shows an example test table as it is rendered within the FitNesse.  Notice how FitNesse displays the .NET settings of the page.

To run the test, click the Test button that is in top left hand corner of the menu items.  (Note that to make a page a Test, select properties from the menu items and choose the Test option box.)

After you run the test, the results are displayed.

This works okay, now how do you write you own.  Take the following steps:

• Open your VS Studio Project with the code that you want to test.
• Write your acceptance test fixture code
• Have your project *.dlls copied into the FitNesse/dotnet directory (Post Build Events in VStudio are good for this).
• Write you test table wiki page and run.

One thing to note.  I was build using VS Studio 2005 and FitNesse was having problems finding classes within my assembly files.  To fix this I had to checkout the latest FitNesse.DotNet from the trunk and build it (You need NAnt). 

• svn co https://svn.sourceforge.net/svnroot/fitnessedotnet/trunk fitnessedotnet

Once done, I copied the required binaries into the FitNesse\dotnet directory and everything worked fine.

This was a strange book.  I simply never got into it.  If you are new to Agile and/or having problems selling Agile into your organisation then its worth a look.  It has a lot of evidence for why Iterative and Incremental Development (IID) works.   Also, if you want a reference to how different agile methods such as XP, SCRUM, Evo, and the Unified Process (UP) compare/integrate with one another then maybe worth a look.  It’s strange, it was a book I didn’t learnt anything new from but it had tons of information and/or content in.  I dunno, maybe its because I was on a course given my Craig Larman (I learnt tons there) last week and everything was a bit too fresh… 

Well not actually with Mike Cohn, but with Mike Cohn books!  Mike Cohn has been around a long time in the agile space, him being an agile alliance founder and all that jazz.  Anyway, enough about Mike and more about his books:

• User Stories Applied: For Agile Software Development (2004)
• Agile Estimating and Planning.

Let me start by saying that they are great books.  User Stories Applied is still relevant today but things have moved on a little since its gone to print but most of what he covers is excellent grounding for anyone new to user stories, as well as those requiring a refresher.  All you need is an ideal day to get through all the key points in the book. 

But Agile Estimating and Planning was really the prize winner for me.  When I started reading it, for the first few chapters where Mike explains why planning fails, I was laughing out loud.  Why? Because I had been on and ran projects that had failed for the reasons he clearly outlines in his book.  Damned I wish this book had been written 10 years ago!

Agile Estimating and Planning does not skirt around the issues but focusses on and provides good explanations, with numerous examples of how and why we should estimate and plan our projects.  Before this book, I had to battle to convince and/or demonstrate by example that the key is in planning and not the plan itself.  As Mike clearly points out, the plan is a snapshot of project progress.  How on earth can this be defined up front before a line of code has been cut and religously followed through to delivery, without continual refinement and change,  I just don’t know.  But people do it all the time.

Now I have the book to refer people to that clearly explains why we should change.  I no longer have to waste time trying to convert people.  Damned if only I had this book on a project that I fell into that the project manager, armed with Microsoft Project Plan, had tasks for every single class, I kid you not, within the system!  This was a big ole system.  You don’t want to think about the weekly status meetings we had on this global project…dull, dull, dull.  Hey Jim, you completed XmlInitParser.java.  Yep, that’s done.  How, about you Bob, you were 45% done on the RmiRetryStrategy.java?  Nah, had a registry problem.  Ten minutes later, a lot of dull implementation details, and finally, should be done tomorrow though.  Kill me now…how can you be 45% done on a class…?  It’s either done or not done!

Anyway, time for bed.  The books are great and well worth a read.  So go read them…