Agile essentials 5: Just in time

Only build stuff when you need it. Make decisions as late as you can. A decision isn’t final until you have finished building whatever is based on that decision, and even then..

The principal that you should only build something when you need it is kind of obvious. For one thing, if you aren’t going to use something right now, what are the benefits of building it over some other thing you could be doing? For another, if you build a thing when nobody is going to use it, how do you know what shape it needs to be?

There is only one benefit I can think of to building something before it’s needed, and that is when you have absolutely no idea how to do it and you’re a little worried it might be impossible, or at least very hard. However, I’d still try to do it as close to when the thing is needed as I dared, so that I have a better idea what shape it needs to be.

Apart from building things, decisions are the other thing I think you need to do just in time. This is a dangerous aspect of Agile for me. I am not a detailed planner by nature. The fact that a lot of Agile wisdom says don’t plan in detail ahead of time is music to my ears. However, the temptation is to take this advice as “don’t plan anything”. I’ve actually heard and seen this extreme view and it works out very well for developers but, unless you’ve found a way to convince your business they want to work like this, I think it probably gives software developers a bad name.

I probably experienced the most successful version of just in time decision making I’ve seen on my most recent project. The way we worked it was to identify the next few requirements we were going to work on and discuss them in workshops with the whole team, designing on the fly, creating a common understanding of what we were going to do. Workshops were free form and we sometimes needed more than one for a requirement. On a couple of occasions we realised we couldn’t work on the requirement yet because there were other things we didn’t know. Crucially, all of this took place ahead of time, before a developer had tried to start coding.

All the same, we only worked one sprint ahead. This meant that we always remembered the workshop(s) when we were building features. Several times, this meant that we looked at the recorded requirement or acceptance criteria and we were able to question them based on our recollection of what had been agreed.

In a perfect world I think it would have been better to work on one feature at a time, only having workshops when we were ready to build and working one feature at a time. However, availability for meetings and dependencies between features sometimes meant we needed to have workshops when we could. It didn’t work out badly at all.

Our approach didn’t have perfect results, and I think it’s important to stress that. There were still occasions where some developers sat down to build something and raised enough unexpected questions that we ended up back in the workshop room. There were even a couple of occasions where a feature had to be refactored because of a later requirement we hadn’t realised would be connected. Of course, this is why it’s a good idea to leave decisions as late as possible – had we decided everything ahead of time there would be a lot of rework and redesign.

I think this raises another important aspect of decision making in software – your decisions, even once made, have to be flexible. Sufficient evidence that another way is better has to be considered. That said, I can think of one decision we made at the start that we have since come to regret. Other than throwing the entire project away, I’m not sure there’s anything we could reasonably to to remedy this regret. Pragmatism says the software works and the regret isn’t so bad. Optimism says one day soon we’ll find a way to address it without too much pain.

As for my wider discussion of essentials in an Agile environment, I guess the point of this post is that your chosen Agile methodology should allow you to take decisions and build things when you think they are necessary for the thing you’re building, and not before. If there is some deliverable in your process (like a project plan or a design document) that is forcing you to make decisions earlier, and you can’t see a good reason for making that decision early, I think this is a red flag that something needs improving with your processes.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s