Zone senior front-end developer Tom Jeatt examines the agile principle of the Last Responsible Moment and what it can bring to projects in any discipline…
A while back, in preparation for one of our first agile projects, we had a workshop with Alan Kelly, the agile coach, speaker and writer. The workshop in general was fantastic, but one concept in particular stuck with me: the Last Responsible Moment.
The idea behind the Last Responsible Moment is simple. Rather than doing everything you need to do all at once, you do something either at the point at which you need it, or the point at which it would be irresponsible not to do it. This can be carried out by any discipline and at any phase of a project.
Because this is such a simple concept it’s easy to put into practice. All you need to do is ask: ‘do we need to do this now?’
If the answer is ‘no’ then you can move on to something more immediately important. If the answer is ‘yes’ then you should follow up with: ‘do we need to do all of this now?’
If the answer to this question is no, then just by asking one or two simple questions there’s a good chance you’ve better prioritised and reduced your immediate workload. As an added bonus these questions tend to encourage breaking big tasks down into smaller ones — another essential principle of agile projects.
The best time to ask these questions is at the start of each task or feature, but they should be asked again (and again) while the task is in progress. As well as being good questions to ask a client during sprint planning, they’re also good to ask yourself while you’re working on something, whether that’s writing a project document, a test script or a piece of code.
(As an aside, the Last Responsible Moment has been compared to the programming principle You Aren’t Going to Need It. There are similarities, most obviously the concept that you only build things when you need them, but the Last Responsible Moment is an agile principle that can be applied to writing code rather than a programming principle. They do work very well together though.)
What are the benefits of working this way?
There are three major benefits to the Last Responsible Moment.
The first is that you spend less time doing work. This doesn’t mean that you do less work, it just means that rather than spending a lot of time polishing a single feature and covering every possible scenario or edge-case, you use the same amount of time to get more things done. You can then approach additional requirements as and when they become important.
The second is that you won’t always need to do the things you think you need to; sometimes the Last Responsible Moment never arrives. Like most developers, I’ve built features that were never released, or built the same feature more than once, because in the time between development and release the requirements were superseded or the client’s priorities had changed. With the Last Responsible Moment this becomes less likely because the time between development and release should be as short as possible. By asking whether something needs to be done now you may find it doesn’t need to be done at all. This also forces you to question things that you might do simply out of habit.
The third is that we work in a fast-moving industry and it’s entirely possible that if you delay doing something until you need it, there may be a better way of doing it. It might be that a browser feature has gained enough support to become usable, a tool or framework has been updated, or simply that you’ve gained more experience and become a bit better at your job.
What are the risks?
The biggest risk is that you need to be aware of when the Last Responsible Moment is. If you miss it you can end up causing the same problems you were trying to avoid. That said, this isn’t something that has really caused us any problems. There have been occasions where we should’ve done something sooner, but since this approach encourages you to work on small tasks the impact is minimal. As long as you’re disciplined then you’re unlikely to run into difficulties.
You also need to make sure that everyone understands how the process works. The client and the rest of the project team need to be aware that just because something hasn’t been done doesn’t mean it’s been forgotten, it just hasn’t reached the point where it’s essential. This requires a bit of adjustment if you’ve been used to writing gold-plated production-ready code from day one.
How does this work in real life?
So far, so theoretical. But now that we’re a good way into this project I can point to some specific examples where the Last Responsible Moment has helped us deliver a better product. These are mostly front-end specific, but each has its equivalent in other disciplines.
· We have a better front-end build task. As a front-end developer, one of the first things I would do on a new project is create a build task to take care of things such as compiling or transpiling code, splitting large files into smaller ones or running unit tests. Previously I would have created a build task (or used a boilerplate) that did everything we might possibly need right from the start. By doing things more incrementally we now have a build task that only does what it needs to and is perfectly suited to this particular project. This has made it much easier to maintain and extend.
· We’re using CSS grid. Again, a grid system is normally one of the first things I would build in a project. This time, because we were building the site mobile-first I didn’t need it immediately, so I delayed making a decision until we needed to start working on a desktop layout. In the meantime, CSS grid had gained enough browser support to make it viable for a production website, which meant that we avoided creating a dependency on a legacy grid system.
· We’re building features progressively. Revisiting each component or feature multiple times has allowed the UX and development teams to refine each part of the site as features are extended or added. The effect of this has been a much better looking site with a robust and maintainable code base.
· We have more appropriate browser support. We’ve been able to look at browser support in a much more nuanced way. ‘Do we need to do this?’ has often been supplemented by ‘do we need to do this everywhere?’, which led us towards bringing in legacy browser support at a feature level rather than a site level (an assumption that could easily have gone unchallenged), and gave us the opportunity to make the decision based on user research and business intelligence that wasn’t available at the beginning of the project. We were then better placed to quantify the cost of supporting older browsers and help the client make an informed decision about how much time and money they wanted to spend on it.
How does this help me if I’m not working on an agile project?
Although the Last Responsible Moment is an agile principle, it’s not an agile process. Rather it’s an agile way of thinking that can be applied to any project regardless of methodology. All you need to do is ask ‘do we need to do this now?’ and see where that question leads you.
