How long to change a culture?

A current project I have on the go is writing a C# console app to replace an ageing VB5 application.

For many on the project, this is the first time writing production C# instead of VB. In addition we're aiming at a SOLID design, aided by NUnit, Spring.Net and of course Cruise Control.Net.

A reoccurring challenge we've faced on this project is re-learning how to write software. Its more than just learning a new language, tool or framework, its more like loosing the shackles of apartheid. This analogy may seem a little strong, but it was quite clear to me after discussing with an Afrikaans South African (in his 20's) just how long it would take for his country to be free of apartheid's effects: we concluded at least three more generations.

Whilst I know that the team won't have to be great-great-great-grandparents before we loose the shackles of VB and procedural programming, I need to remember that cultural of change of any sort doesn't just happen overnight!

This was further driven home to me today when ThoughtWorks met with us to discuss an upcoming project. They shared how to aid culture change, they send newbies on a boot-camp that lasts 6-8 weeks!

A user story story

Although I've known about user stories for about five years, I've only now been in the position to practise what I preach.

Having promoted them within my team (particularly following QCon 2007), I'm trying to use them on every project I work on and have to say I am blown away by their effectiveness! Although we captured them onto a wiki, their power immediately became apparent when we started using the real paper/card versions.

First off, estimating (complexity) became immediately easier: we analysed each card and divided them into three piles (easy, medium and complex). Unknowns and design notes were made direct onto each card, for later reference. The cards could also be simply arranged in dependency groups. Pieces of paper divided into piles made the shuffling back and forth incredibly easy and low cost.

We then assigned effort estimates (weeks) to each story and grouped them into possible iterations. Again, the ease with which changes could be made, and the effects so easily seen gave the analysis extra power. I've always previously used Excel to do this kind of work, but whilst it "looks" professional and does the sums for you, it lacks the speed and imprecision of paper!

The power of paper was further demonstrated when we met with a system commissioner, and talked them through our analysis. Each piece of paper could be referred to in turn, to address unknowns and discuss implementation considerations. The story groups could be simply seen, but also easily rearranged.

The ironic twist is that we kept our wiki versions of the story up-to-date as we changed the paper ones. However, we came to the conclusion that whilst the paper stories looked unprofessional (my writing is not the neatest :-), the real paper ones were just so much more powerful.

Keeping CruiseControl DRY

I recently set up CruiseControl.Net to build a number of VB applications. This post describes how I kept the CC configuration DRY (Don't Repeat Yourself), whilst allowing more applications to be easily added and reported on.

My initial set up consisted of a single project that built a set of applications defined by a text file. Whilst this made adding a new application easy, it had a number of problems:

1. Any source control change caused all apps to be rebuilt.
2. The reporting was not at the application level - if one failed to build, it showed up as all had failed.

Version two led to a separate project for each application, but this quickly became messy, as the same elements (e.g. filtertriggers, source control details) were repeated time and time again. Also, editing one project configuration would cause all projects to be rebuilt, as the one file contained all configurations.

This led to version three, which stayed DRY thanks to the use of DTD entities to separate out:

1. Duplicate elements.
2. Projects into separate config files.

Although each project was now defined in a separate config file, it could reuse the entities defined in the main ccnet.config file, thus staying DRY. Adding a new project was still simple, as it just took two steps:

1. Create a modified copy of an existing project sub-config file.
2. Modify the main ccnet.config file so it references the new sub-config file.
   

An alternative approach to this is to use CI Factory. Whilst this does streamline the setup of CruiseControl.Net, I found that once this was done, adding new projects (as above) was easy.

Testing CI Factory did have its benefits though. It led me to consider splitting the Cruise Control service into multiple services, so as to separate the main ccnet.config file into one per group of applications. This may well provide performance gains, as well as remove the problem of changes to one project config causes all to be rebuilt.

Watch this space!

QCon 2007 - What I learnt about process - Part 2

Going through my notes I discovered this useful map of an agile life-cycle. I think it came from Rachel Davies's session on user stories.



As text it reads:

Bird's eye view of life cycle

Exploration

Explore

• business domain
• technology
• process
• scope

Keep as short as possible (< 2 weeks)

Release planning - create roadmap of releases

• May not happen until some initial iterations
• Flesh out plan as you progress
• Deliver high risk / high value items early
• Set concrete release dates but vary features

Iterations

Production - aim is to arrive here ASAP

Planning phases

Customer needs

Implementation considerations

Implementation tasks

Estimated task list

Customer reviews effort vs. necessity

UI Design is often done an iteration ahead,
to help users & team understand what is required

QCon 2007 - What I learnt about process

A post in a series that summarises what I learnt at QCon 2007.

This post focuses on development processes.

For a mind map version, click here

Inspiration came from the following excellent sessions:

• Agile Leadership Tutorial - Diana Larsen
• Usage-Centered Design Tutorial - Larry Constantine
• Modifiability - Martin Fowler
• Operational Manageability - Dan Prichett, ebay Technical Fellow
• User stories and release planning - Rachel Davies
• Test driven development - Steve Freeman
• Agile PM: The Googley Way - Jeff Sutherland
• The Yawning Crevasse of Doom - Martin Fowler & Dan North

Implementing change

• Have retrospective to establish SWOT's to address
• Prioritise cultural changes each iteration / project
• Do simple things well, then focus on clever/hard things

Agree on principles as early as possible, e.g.

• design
• unit testing

Key success ingredients are

• Encapsulation
• Classes should "keep secrets"
• Tell, don't ask
• Prefer private over public
• Leads to more readble code
• Keep the domain model clean of non-domain code/entities (e.g. UI, DB)

• Do the simplest thing that will work (not the same as doing the easiest thing)
• Making code test driven: lowers cost of change
• Test for required behaviour not implementation
• Refactoring is the second leg of TDD (first being testing)
• Growing better developers is best investment that can be made in a team
  

Use risk maps

Bridges and ferries

• Bridges:
• Promote activities that build bridges between developers and the business
• Encourage activities that have feedback
• Minimise "distance between" developers and the business
• Consider co-locating developers and end-users
• Don't build "ferries", that distance or separate developers from the business

User stories

Less is more

• Tool for collaborative planning, i.e. purpose is to encourage communication between stakeholders
• Facilitates collabrative dynamics, via the 3 C's:
• Card
• Conversation
• Confirmation
• Can exist alongside more formal and comprehensive documents
• Aim is to write less sooner, to minimise cost of change
• Sometimes prior analysis should be done to understand problem domain, before moving onto stories

Why's and how's of a story

• System "commisioner" provides "why's"
• End users can provide "how's"

Format

• As a I need so that .
• e.g. As a book buyer I want to find a book by entering the ISBN number, so I can locate it quickly
• OR simply state user goal
  

Scrum

Minimise "work in progress" - "Done" means system and acceptance tests pass

Minimal process

• Artifacts
• Product backlog
• Spring backlog
• Burndown chart
• Meetings
• Sprint planning
• Daily meeting
• Sprint review
• People
• Product owner
• Scrum master
• Team

Builds

Include rollout script for use by Operations.