DanNorth.net

Adopting agile practices is a step-change for many senior managers and business sponsors. Don’t underestimate the importance of getting them onside early in an engagement, and making it “safe” for them to explore and adopt agile practices. We want to provide our sponsors with timely, accurate information they can use to make effective decisions about the steering of a project. An agile project provides exactly the data to do just this, but we have to ensure that the people receiving it can interpret and make use of it easily and effectively.

For the team on the ground, agile adoption is a shift in thinking from large chunks of activity to smaller, iterative, highly-collaborative working. This shift can take place quite quickly. With a small, motivated team and a high enough proportion of agile “enablers” in the team (about 50/50 seems to work best), a new team can pick up “proper” TDD, pairing, continuous integration, story writing, etc. in a matter of a few weeks.

The business sponsors, on the other hand, have a rather different journey. They are used to seeing Gantt charts showing percentage completion of development activities, and—shame on us—they are used to project managers being, well, at best conservative with the truth. In our defence, we say things like: they don’t need to know the day-to-day dynamics of the delivery cycle. If we are slipping slightly, let’s just gloss over it—we don’t want to go worrying anyone. And anyway, no-one likes their project to be “amber”, do they?

I am lucky enough to have been invited to present at Expo-C, a software architecture conference based in Carlskrona, Sweden. The dates are 16th to 19th May 2006.

At the risk of dropping names, last year’s conference included sessions by the likes of Rod ‘Spring’ Johnson, Rickard Oberg and Jimmy Nilsson, and this year’s line-up includes, well, take a look for yourself.

In a moment of insanity, the organisers have given me a whole day to play with, the Tuesday, – so I’ll be running a number of sessions with an agile theme, rounded off with a retrospective. I’m going to see how little PowerPoint I can get away with. I’m aiming for Zero Slides.

The rest of the conference is packed with seminars, a panel session, tutorials and they’ve even squeezed in some Open Spaces. A small conference that looks like being a lot of fun – spaces are strictly limited and apparently Carlskrona is beautiful at this time of year.

Automated builds have become a cornerstone of agile development. Every time a developer checks in a change, a tool like Cruise Control checks out all the sources, builds everything, runs all the unit tests and reports back with immediate feedback. This cycle has become known as Continuous Integration, due to the seminal paper by Martin Fowler and Matt Foemmel, but this is something of a misnomer. It is better described as Continuous Build. (Their use of “integration” was about integrating all the bits of software that the various programmers in a team would traditionally be working on in isolation from one another, only to bring together and spend days or weeks getting to work. Practices such as pairing and automated builds have all but eliminated this form of integration hell, at least on agile projects.)

However, delivering an application is more than just writing and testing software. The code lives in a container or application server, which runs in an operating system, on hardware, on a network, behind a firewall, connected to other machines, services and components, which may themselves be inside containers or application servers, and so on across your application, across your enterprise and maybe out into the wide world to other enterprises and other servers. (more…)

So, it’s taken me two years to finally get round to writing down what behaviour-driven development is all about, but I’m pleased with the result. The article has just been published in the March edition of Better Software as “Behavior ((I didn’t quite get away with the UK spelling)) Modification”.

I started talking about BDD as an evolution of TDD at the back end of 2003, and played with the idea of a BDD framework, in the form of JBehave, during 2004. I made some noise about it at the Agile Developers’ Conference in June 2004, and then at the end of the year everything went kind of quiet. That’ll teach me to have a day job.

At the end of last year, I finally got back into BDD evangelist mode, and decided to write the story of behaviour-driven development: where it came from, what it’s about, how it has grown and where it is going. Just when I was busy working out what I wanted to say, by a curious coincidence, Brian Marick approached me to write an article about BDD and JBehave for his excellent magazine, Better Software, which I was targeting as my ideal audience anyway. Hurrah!

You know what to do – rush to the StickyMinds.com site and take out a subscription so you can read the article and tell all your friends about it.

I have to thank Brian and his excellent editorial team, as well as the ThoughtWorkers who gently (!) shepherded me through the process of writing and editing the article. In particular, Liz Keogh, Martin Fowler (yes, that one), Joe Walnes and Rebecca Parsons were extremely helpful and supportive. Thanks guys.

Charles Simonyi introduced himself at a recent workshop with the words: “I was at Xerox PARC in the 70s, Microsoft in the 80s, and working on intentional software in the 90s”. He wasn’t showing off, he was just there. He pioneered WYSIWYG, created Microsoft Word, Excel and Access (as a data visualization tool), championed OO and invented metaprogramming.

What this tells me is that when Charles Simonyi thinks he is on to something, it’s probably worth listening. (Ok, I’ll forgive him szHungarian notation.) For the last 15 years, Charles has been on to intentional programming. (more…)