We’re often asked why we don’t announce deadlines and release certain features before others. We figured we’d take the opportunity to explain our development process: agile management.Our features are designed with one purpose; to solve problems. Deadlines stymie us for two reasons:
- Uncertain scope of functionality: We can never be sure how long a feature will take to develop from the word ‘go’, because we can never really be sure how much work a problem will need to be resolved.
- Uncertain priority of features: Features take varying precedence. Some are more, or less, important than others. We don’t know what we’ll be building next because we don’t always know which problems need to be resolved first, and consequently, what’s going to take priority; for us - and for our clients.
Conventional plan-driven methodologies just won’t do. ‘Plan your work, work your plan’ makes sense if you assume everything will, in fact, go according to plan. But crossing your fingers and hoping it will is an unaffordable luxury when forecasting software development.If you have a problem that is defined, predictable and unlikely to undergo any significant changes, then plot your process and stick to it. If you want chocolate chip cookies, there’s no need to change the recipe. You know the one you have is going to work.We have problems that are unpredictable, and change is almost a certainty. We have to make up the recipe as we go along, so we’ve adopted a different methodology known as ‘Agile’.
What's Agile management?
Agile project management focuses on tireless improvement. With input from our users, and a bit of computer magic from us, we can build quality products that have been designed exclusively for our clientele. It works for us (and our users) for a few key reasons:
- Agile works in iterations. We don’t know exactly what needs to be done to solve a problem, so rather than attempting to sit down and code from start to finish, we take a piecemeal approach, so we know everything’s actually covered by the end.
- Agile works to release the best features possible, in the shortest time possible through prioritizing.
- Agile accepts that deadlines for releases of quality software are unfeasible.
The uncertain scope of functionality
Having an incremental methodology means building a small part of the overall project, adapting to any challenges faced, then building some more. Basically, it’s a principle of learning as you go.We learn from both our own experiences in development, and the end-user feedback we receive. A great, real-world example of this is Rex’s new Email Bounce functionality. Like all our features, it had to be built bit-by-bit. We’d plan out two weeks or so of work, and at the end of the fortnight, we’d mull everything over before coding any more.As per usual, problems compounded along the way. Bounce notifications became a hydra – we’d chop off one head and three grew back to replace it.
The tale of Email Bounce Notifications
Our problem was that when a user sent an email and it didn’t end up in the recipient’s inbox, they wouldn’t know. We had to inform them so they could find other means of contact. We didn’t want messages getting lost.Faulty Email Addresses: We realised that although we had to tell them when emails didn’t go through, it’d be proactive to also tell users (when possible) if they were about to save a faulty address into their contacts in the first place. Prevention is better than a cure, after all.This meant developing something that could check to see if an email address was valid before it was saved to contacts.Filtering for Faulty Email Addresses: On top of this, users might already have these faulty email addresses logged in their contacts. Once we’d developed the system for checking the validity of an email address, we needed to create a way to filter for these existing invalid addresses – simplifying it for users to deactivate them.But what if an email that was only faulty because their server was temporarily offline or their mailbox was full was or deactivated? There needed to be a way to reactivate addresses if the problem was resolved. Further development ensued.Notifications: We also realised that since some agents email thousands of clients at a time, we couldn’t possibly notify them of every single message that failed to be delivered with an email. Each time they sent out a newsletter we’d fill their inbox to the brim with maddening ‘did not send’ messages. There had to be a better way.The obvious answer was a notifications system. If we were to develop this we could also leave it open for other features down the road; like email digests and Rex alerts. A system like this couldn’t be squandered on email bounces alone.Notifications Page: Fingers bleeding from producing kilometers of code - we saw some users would be receiving a hell of a lot of notifications and might want to opt out. There should definitely be an option to turn them off.And even with them off, it’d be nice if they could click onto a page and view all their recent notifications - even if they’d unsubscribed from email alerts.Customizations Page: But some notifications are far more important than others. Just because they didn’t want some, it didn’t necessarily mean they didn’t want any at all. We had to add a way to control exactly which notifications were and weren’t received. Thus; a customization page.Housing the Beast: It then became apparent that if a system this monstrous was running in the background, it could slow everything else down. It would have to be housed elsewhere - outside of Rex’s code logic. If requests to our server were slowed down by processing emails - and whatever other notices we’d be delivering later on – that’d be terrible for our users. And my goodness, was that a drama.
As you can see, email bounce alerts started out small and grew into a colossal tree of branching difficulties - budding every time we pruned it. We could never be entirely sure how much work the feature was going to take to be polished to our standard. We have to constantly reflect on what else should be added to create stuff that really, truly works.If hadn’t, we might have taken the ‘simple’ path. Sure this would have meant you had your email notifications sooner, but every other features we wrote down the road that required notifications would have had far more coding, far more issues to debug, much longer implementation, and far less time doing worthwhile work on anything new.We might have slowed Rex down, or filled up your inboxes with thousands of spammy emails telling you your message hadn’t sent – and no way of slowing the deluge down or fixing the problem.Deadlines, as it were, destroy good software.We’re not striving to develop ‘something’ by a certain time. We’re striving to develop the best ‘something’ we can, whenever we can deliver it. Which leads us to the uncertain priority of features.
The uncertain priority of features
A huge flaw in software development (without using an Agile methodology) is the inherent risk developers take when creating a new product; that they’re building the wrong thing.While users are desperately in need of a certain feature, developers might be working on something completely different – and losing clientele. They could spend months agonizing over a feature - the market place could change - and they release it only to find their efforts were completely wasted.So we don’t fall into this trap, we employ a formula of ‘benefit over process’; benefit for users over our workload. This determines what’s on top of our schedule, and we avoid producing crap people don’t want. Plus, we get our best stuff out as quickly as we can.If a feature will take us on a Dantean journey through the seven circles of coding hell just to build something our clients won’t really need, that’s obviously going to be quite a low priority. Conversely, if a feature is actually easy to develop, with great benefit for our users, we’ll start work on it right away.We shift our priorities in order to get the best stuff out as quickly as we can. Sometimes it’s necessary to stop work on a particular feature, pop it on the back-burner, and focus on something else for a while. Occasionally, if we discover a better way of tackling the problem, it’s even necessary to throw the baby out with the bathwater and start again.By utilizing feedback from our clients we can track what is the most important to them - and hence what we should be concentrating on. We greatly value users’ feedback on our ‘suggest a feature’ page, and our voting system shows us what’s most important to them.
Email Bounce Notifications took priority
We had had email bounce notifications in the works for a while. When our users started voting strongly for it, it took priority. We’d been working on the REINZ and ADL form integrations. We put them to the side temporarily so we could focus on what our clients needed right away.Once we had the ball rolling, we realised the mountain of work that’d be required. Despite being a substantial undertaking, the benefits were huge and so we kept at it. The notifications system would be useful to incorporate into other features later on.However - if a user had brought a serious issue with Rex to light during it’s development, (for example, double clicking the calendar tab caused whatever device you were using to spontaneously burst into flames) - that would take priority. We’d put down our work on the email bounce, and start tackling it right away.Email bounce notifications wouldn’t be lost though. As soon as we’d cooled down the calendar we’d be straight back onto it - sorting them out as if we’d never left them in the first place. Rex actually has several unfinished, low-priority features saved away for a time when we don’t have anything too pressing going on – we’re waiting for a lull to develop them further.
Wrap up
By working like this we can be sure we’re always working on what is best for everyone, and we can deliver the most quality product in the shortest amount of time.We’re not wasting client time on a product our developers can’t feasibly create as quickly as they’d like it. Likewise, we’re not wasting developer time creating a product our clients don’t actually want. We monitor the market so we don’t build a product that isn’t up to date.With iterative and incremental principles combined we end up with a system that doesn’t involve working on a single phase at a time - as is the modus operandi of plan driven development. Instead, Agile works on one or two features at a time, which encompasses all the usual phases, as well as the opportunity for feedback and change.Agile is our method of development. It ensures that we aren’t left behind by competition or the changing priorities of our clients. It ensure you get the best out of us.
.webp)
.webp)
