A brief history of Newsweaver’s development process
When we first began developing the alpha version of our B2B Email Marketing platform (as it was back then) in 2006, our “iterations” were sometimes only a week long. This was made possible by the fact that the system was not yet in production. Releases have the potential to be both costly, in terms of time and effort, and also risky, given that each new version of the system can bring with it new bugs and new problems. Once Newsweaver went live in 2008 the time between releases increased, and as a result of this so did the length of each iteration. The increase was gradual but consistent and meant that iterations that once lasted several weeks became iterations that lasted for several months.
Bigger doesn’t always mean better
As already mentioned, releases can be difficult. They take time to prepare, time to verify, and time to actually do. As well as this, they bring the real possibility that a serious bug or regression has been introduced by the version that you are releasing. Obviously every effort is made to mitigate these risks but sometimes bugs will go unnoticed until they are encountered by users. Typically there is a direct correlation between the length of an iteration and the difficulty of its release. There are a number of reasons for this:
- Database migration scripts can take quite some time to run and are typically executed during the release. The more scripts there are, the longer the release will be. We've had releases in the past that have needed more than 5 hours for the migration scripts alone!
- The longer the iteration, the more changes there will be. The more changes there are, the higher the likelihood of the presence of bugs.
- If an iteration has already lasted for several months it is very easy to justify extending the end date by another week for one reason or another, meaning users waiting on a particular bug to be fixed now have to wait an additional week before it's fixed as part of the next release.
We have 4 week iterations now, does that make us Agile?
Well no, not on its own at least; but it certainly does help. When we first started doing Scrum around 3 years ago, the first goal was to reduce the length of our iterations from something that was of indeterminate length to the 4 week “sprints” we have today. This immediately reduced some of the problems of before, such as large numbers of long running migration scripts, releases with a very large number of changes, and long wait times for updates and bug fixes for our users. It also had some other benefits, chief of which was that it enabled us to create a product roadmap with more fixed milestone dates – as we now knew that we would be releasing every month as well as how much we can do in a given sprint. A good product plan, as we have now, is vitally important to successful product development. Having the ability to change this plan as quickly as possible in order to respond to changes and to new opportunities is one of key benefits of Agile.
A change of mindset
Our previous method of feature development often saw us develop features “to completion” before giving them to our users, even if this took months to do. The problem with this is that sometimes we’d build a feature that contains all of the functionality that we could think of, only to find out once it’s being used that it doesn’t work quite as our users require or expect it to. In addition to this, our users often have more ideas of how things could be improved – which means further development on the feature. As well as this, we could spend a lot of time building in functionality that our users don’t ever use nor want. Our shorter sprints have brought a change of mindset that basically equates to – “let’s build a feature that fulfils the users’ basic requirements and then improve upon it over time based on user feedback, prioritising the functionality that our users value the most”.
Learning from past mistakes
We have a product plan, we can adapt this plan quickly if required, and we take a more lean approach to feature development. So does that mean we’re Agile? Almost – there’s still something missing; the ability to recognise and learn from previous mistakes, as well as finding ways of preventing them from being made again in the future. This is one of the most challenging aspects of software development and it’s something that we need to be cognisant of at all times. Luckily Scrum helps us here through the use of retrospectives after every sprint. During a retrospective we look at all the things that have gone badly as well as those that have gone well, with a view to keeping the good behaviours and eliminating the bad ones.
So why is it so important to be Agile?
Simply put, our agility enables us to deliver working solutions to our users as quickly as possible. Whether it’s a new, widely sought-after feature, or an entire shift in market focus like our move to the Internal Communications space, we can be confident that we can deliver in a timely fashion. Agile drives us to constantly look to improve our work practices and our code quality, to ensure we deliver solutions of the highest quality to our users. It reminds us that whatever we are doing right now, however good it may be, it can and should be improved upon to ensure that we don’t get left behind in a market that is only going to get more and more competitive.