go ugly early

I don’t think I had heard the phrase “going ugly” until I read Go Ugly Early by Dwayne Melancon today. To quote Dwayne:

“This concept involves releasing early iterations of your products so you can allow your customers to interact with them and provide feedback. I’m not talking about releasing unstable or buggy products – I’m talking about releasing stable products that have limited functionality, but which telegraph the shapes of things to come.”

Which, of course, is exactly the approach promoted by all of the agile software development methods. Sort of.

In fact, the agile community has amazingly little to say about beta programmes and the like. We talk a great deal about the OnsiteCustomer (aka ProductOwner or ChiefEngineer or ProductDirector) who gives rapid feedback to the developers on a daily basis. But that’s not the same as giving a try-out version to a few key users. If you’re developing something you would use yourself, then trying out your own dog food early is very easy and relatively risk-free. But when the target user is potentially a paying customer, it can be all too easy to perceive the risks as outweighing the advantages. What if they laugh at our half-baked ideas? What if they steal the idea and take it to our leading competitor? Frankly, I don’t believe any of these are real issues. Not compared to the benefits of using early-access free stuff to forge a long-term relationship.

The ProductDirector’s rapid feedback and direction is essential in the microcosm of the development shop itself. But in addition, giving genuine users the chance to genuinely use parts of your new product under genuine conditions can be … genuinely useful – both to you and to them. Your user (or potential user) is being given the opportunity to ensure that your next product fits them like a glove. Most will be prepared to invest a little time to get that. And if they laugh, you’ve learned something about your understanding of the market – and you’ve learned it without investing the whole kaboodle.

Of course, the partial system must be production quality. If it isn’t bug-free and trivial to install you will probably be dismissed out of hand. (Again you’ve learned something – but it was something you already knew and could have avoided.) So this isn’t prototyping, it is real product development, in small chunks. The opportunity only arises because of honest and thorough use of agile practices such as TDD, ContinuousIntegration, DailyBuild etc. (Maybe that’s where the perceived risks come from: this is all new. Waterfalling never gave us the chance to create this kind of relationship with our customers.)

Do you have a story where going ugly early saved your bacon? I’d love to hear it.

a week isn’t long to wait

A very important part of the process of incremental delivery is the weekly commitment. Each week the product owner and the development team should agree on an increment of value. The development team will commit to delivering that value, and the whole organisation should respect that commitment.

So if anyone wants the team to do something different – a few hours’ support, or an urgent feature for a desperate customer – they must expect the team to say ‘no’. Because the team has promised the product owner that it will spend its time delivering the agreed value.

The time to choose what the team does is at the weekly planning. Or preferably before the weekly planning, in conversation with the product owner. If you anticipate support interrupts, get them allocated into that week’s increment. And if you failed to anticipate them, find a way to let the team deliver on its commitment anyway. After all, on average you’ll only have a couple of days to wait.

The way to influence how the team spends its time is to influence the product owner. To directly ask the team to do something that isn’t in the increment is to fail to respect their commitment to the product owner. No-one performs well when asked to steer in two different directions at the same time, and no-one should be asked to decide where their loyalties lie. Agile software methods all place the product owner at the gateway between the team and any parties who may wish to use their time. Entering the team’s room via the back door breaks the fundamental structure of the agile process, and will likely lead to confusion, disaffection, loss of morale and loss of productivity. And all for the sake of a couple of days…