So Agile, they’ll need another word

This last week has been the first of a project planned to take four weeks. It is a great opportunity for me, since the project’s goal is to deliver on an idea I pitched, some months ago, to solve a problem with the way we test.

I have been very pleased with getting this far. When I first proposed what I called ‘a pretty radical change to the way we approach testing’ I wasn’t sure I’d be able to convince people it was the right thing to do. But as it turned out I had no real resistance. In fact so positive has been the response, that many have long forgotten that I got things moving in the first place.

Ironically I was busy constructing this plan when I was being told that I am ‘not perceived as having enough sense of urgency on the day job’ Apparently I should have been more head down and focussed on the job in hand. However I think that criticism was short lived, and short sighted. By planning the changes I wanted to put in place, whilst everyone else was too busy looking no further than the next day, I found myself with a plan and a proposal ready… just as the management team started to wonder what on earth people will be working on once the last version shipped.

My proposal got discussed, and sized. The team lead of the automation team, who will ultimately own the changes gave a sizing of four person months. And he was insistent that he get to pick the four. It’s no good just assigning four random people and hoping for the best. He wanted people he knew would be able to deliver. He also insisted that these people be allowed to focus on the job. This sizing was for four people working full time – not being asked to fit it in around other priorities. This was a pretty tall order, and the fact that we got granted those demands is both a factor of having sold the long term benefits. And the management team having little better planned.

As fortune would have it, I got selected as one of the four. I am certainly the person most interested in seeing the idea succeed. And I’m grateful for the unusual opportunity to actually spend some focused time on delivering my idea. I’ve often thought it would be cool if submitting patents would come with the possibility of being given funding to develop a prototype… but no.

So here we are, end of week one of this four week plan. We are attempting to follow the ‘Agile’ method.

For those unfamiliar, Agile is nothing new as such. it is a rebranding and repackaging of various ideas that have been evolving for some time. It is – in my mind – an attempt to have a software engineering process that fits with real business needs. Gone are the days when clever people could lock themselves away to produce something clever, and just deliver when they thought it was ready. Many of the older software development processes just don’t work in a world of ‘marketing splash dates’ and tactical deliveries. You have to be able to adapt to the market. Being half way through a 2 year development cycle when the market changes could be devastating. One of the main features of ‘Agile’ is that you construct just enough to deliver customer value every ‘iteration’ And those iterations are as short as possible. That said we’re doing 1 week iterations which is very very short.
But the idea is the same. At the beginning of the iteration you plan with your stakeholders/customers, what you will deliver in this iteration. Something they will be able to see, and use. At the end you demo that to them. This helps to keep you focussed on delivering just what you promised, and no more.

I can say after 1 week that it is *really* hard not to get drawn in to considering design and longer term goals. How should we do ‘this’ so that when we get as far as needing ‘that’ feature down the line it will work right, etc. Finding the path between bad design that will make life harder in the future, and over engineering a solution at the expense of delivering this iterations value. But the driving goal must be, that in the modern business world, you must be able to deliver value at any point. If the project got canned next week, we’d have something that would provide some function. It isn’t everything people want. but it’s also not just a pile of unusable code.

The aim for next week is to actually deliver enough to go live on our ‘customers’ website. It will not be ready for full fledged use. It will still have some serious limitations. But it will be able to do some key piece of the project goals. From there forward our delivery will be to update that live system with the latest set of capability. Every week our customer will get a little bit more of what they wanted.

This week when asked how it was going, one of the group replied, “We’re so Agile they’re going to need a new word”.
Which in part is a reflection that with this process you can apply it to greater and lesser degrees, depending on the project. With just five people in one room, and a single month, we can take it to the extremes of Agile development.

Another cool thing about the project, is that I am sitting in an office with four other guys (we ended up getting a fifth person for the first couple of weeks) And they are all super smart, capable developers. It’s unusual to work in this way, it’s not that I normally work with people that aren’t clever. It’s more that normally the way of working doesn’t let you collaborate, as much as just do your own piece without that much interaction.

This week I’ve been blown away by how fast we got something working, and doing clever things. And it’s really energising to work along side people that know how to do things I don’t, and (hopefully) fill my own roll of expertise. It’s an education looking at the code they write. I think nothing of throwing together the sorts of code and solutions I’m familiar with, and they all have different areas that they handle with the same ease. Together we seem to work pretty well. There are some differences of opinion on design, as is healthy. We all help to stop each other getting drawn into considering options and designs that are not part of our current deliverables. And so far we’ve not hit a problem that has stumped us all.

I haven’t been this happy at work for a long time. I’m actually finding it hard not to keep on working during evenings and weekends. However another key feature of Agile is ’sustainable pace’. It’s no good relying on people working every hour, they will burn out. As enthusiastic as we all are, I’ve been keen to remind us all that this project may be used as a template for others. And we owe it to future projects not to succeed only by working ourselves to death. We prove what we can do working just regular working hours.

Perhaps the strangest part of this agile project, is the acceptance that requirements are shifting. There is no hard and fast list of what we must deliver at the end of 4 weeks. There are key capabilities which form our first areas of focus. But at the start of each new iteration we review what, out of the possible options, is most important to deliver next. The expected output of the project will be the most important parts of a working system AND a list of the things we wanted to do, but were prioritised lower than what we delivered, possible enhancements that may form the basis of a separate project.

That’s probably more than enough of the subject for now. However I will post updates as we go through as to how we are managing this Agile project. And if we have hit the much touted problem with Agile, that of hitting a point where you realise you’ve designed yourself into a dead end by virtue of not thinking far enough ahead.

Also I may post about Rational Team Concert.. for now I will just say it’s awesome. (Yes I work for IBM, no I’m not paid to say that, nor is it praise I’d have for many other Rational tools).

Check it out at jazz.net

Re-inventing the wheel

I have for some time been playing with woodturning on a lathe I got from my father. He gave it to me with a box of bits, some scraps of wood, some chisels, sharpening stones, oils… and a book. Keen to get going I leaped into action setting everything up and having a go. Convinced that the best way to learn it was to try. And I certainly have learned some things. I’ve had the lathe for several months now, and in that time I’ve have started to identify things that are going wrong with my ‘instinctive’ approach and started to consider the things that cause it: insufficiently sharp tools, bad technique, etc.

I would characterise my early wood turning attempts as beating the wood into submission with little more than a blunt instrument. Fortunately wood is softer than metal so you can achieve… results with this ‘approach’. The poorness of technique can largely be masked behind a vast amount of sanding, although never truly masked. Having looked around on line for tips and tricks etc, I increasingly found people pointing to books that are full of useful advice, and the idea of watching people to truly learn. So it was just this weekend that finally picked up the book that was in that box of bits…

Wouldn’t you know it, it’s full of valuable information! If only I had remembered that re-inventing the wheel is a bad idea in the first place. At work I frequently follow processes designed to help people avoid inventing the brute force and ignorance approach, in favour of teaching them what a wealth of experience and practice has learned. And I have been frustrated that people still insist on treading their own path, and repeating all the same mistakes. Yet somehow I ignored the fact that the same applies to *any* craft.

I’ve read all about all the mistakes I made, and I will tell myself that it is helpful to of truly experienced what those mistakes are like first-hand, however I could of saved myself some considerable time and aggravation by just reading the book first. This week I hope to have time to practice the various correct technique swith the tools I have, so far I’ve just tried some initial attemps at using the skew chisel as intended. And even in my early, unpracticed attempts, the difference in finish achieved is remarkable.

As I mentioned in a previous post, I often debate over where to spend my money for most effect, I’ve now decided that there is no value in spending on more tools until I’ve learned how to use the ones I’ve got properly. It should be obvious, and if I’d stopped to think about it, or someone had prompted me about it, I’m sure I’d of instantly realised the value in reading about best practice and picking up on what lifetimes of experience has taught in the field, and yet left to my own devices I fell into the same old traps.

This reminded me that for some time a colleague at work has been talking about a book called ‘The Art of Software Testing’ by Glenford J. Myers. It is full of great insight, sound advice, and solutions to common issues. And it is several decades old. Yet at no point have I ever been given this book, or pointed to it. No one that I worked with or for mentioned useful information in the area. My friend found the book quite by chance. It seems that education is something people often forget once they move into ‘the real world’. And I think that it might be fun to see if I can produce some physical examples of the difference in quality achieved with education and insight over brute force and ignorance, perhaps duplicating one of my earlier wood turning attempts with a replica once I’ve mastered some basic technique. I am hopeful that I can create a compelling and visual example that I can post here, and use to illustrate the point, next time I am convincing people that there is a good reason for using ‘best practice’ approaches to work.

My favourite quote from my book on woodturning, which applies much more broadly, is ‘Practice without a basic grasp of the fundamentals, simply makes you quite good at bad habits.’