Philip Taylor, Product Owner, explores Agile methodology and how TrustQuay has adopted this way of working as a development solution with 5Series.
Hands up who is familiar with the seemingly ever-present 'How Projects Really Work' poster in offices of yesteryear? Maybe you still have it pinned up on the corkboard in the breakout area?
You know the one, 'How the customer explained it', 'How the project leader understood it', 'How the analyst designed it' etc.
I've often wondered, how did this poster come into being and is there an element of truth in it?
Although exaggerated for comedic purposes, what was it about software delivery projects that helped create this poster and allowed it to resonate with everybody who viewed it? Was it down to the lack of communication and regular feedback amongst the delivery team and the customer? Was it down to the software delivery approach? Is it purely a myth?
Perils of the waterfall
At TrustQuay, like many other organisations, we are striving to make this poster a distant memory. We aim to achieve this by adopting an 'agile' approach to software delivery, having previously followed a 'waterfall' methodology.
For those of you not familiar with the intricacies of software delivery methods, what do I mean by 'waterfall'? Think of those project 'gannt' charts, where each stage of a project is dependent upon the preceding stage completing. For example; gathering requirements, writing the requirement specification, developing the code, testing the code, performing user acceptance testing and finally deploying the finished outcome.
I'm sure many of the readers of this blog post have experienced software projects such as this. Let me paint the scene (again, exaggerated for comedic purposes).
Following numerous requirements gathering sessions over a number of weeks involving an army of analysts and subject matter experts, a requirements specification is written covering every minute of detail that was discussed during these sessions. After a number of weeks locked (metaphorically speaking!) in a darkened room, the analysts emerge, akin to Indiana Jones finding the lost ark, holding aloft a 1000+ page requirements specification. They deliver this to the customer who is then required to read the 1000+ document and sign it (preferably in blood – no longer talking metaphors here!) confirming that they agree (and understand!) the content.
This is handed to the development team who then busy themselves delivering on every aspect of the spec for the next 6 months. Meanwhile, the analysts are off on their next project, gathering requirements, getting locked in a room, etc. Once development has finished, the quality assurance analysts get their hands on the developed code and test it within an inch of its life, being their usual diligent selves and ensuring that the code honours each and every aspect of the specification.
A number of months down the line, the client receives the completed code ready for their acceptance testing. With great anticipation (after all, they've been waiting for a number of months now) the customer installs the software in their UAT environment, lights the blue touch paper and….."Errr, excuse me, but this isn't what we agreed to?"…....the aforementioned poster starts to mimic reality. Trying to understand and document all the foreseen requirements for a software implementation turns out to be really difficult. Wouldn't it be more beneficial to receive feedback regularly through the development process to ensure alignment?
The adoption of Agile
TrustQuay adopted an agile approach to delivering 5Series at the start of 2018, to counteract some of the common complaints with a waterfall software delivery method. The most outwardly visible sign of TrustQuay adopting an agile methodology is the number of 5Series releases being issued each year. We aim for a new release of TrustQuay 5Series 7 to 8 times per year. Prior to our adoption of Agile, a new version of 5Series would "hit the streets" once or twice a year
Agile has a concept of operating in 'sprints'. That doesn't mean we have to don our running spikes when arriving for work at TrustQuay, rather than a sprint represents a timeboxed effort. Our sprints are two weeks in duration. At the end of each sprint, we conduct a 'sprint review'. This is where the various development teams and key stakeholders are presented the work accomplished in the sprint, and feedback is gathered and acted upon, questions such as "have you thought of X", "why doesn't it operate like Y" are asked during the sprint review and acted upon if that feedback proves to be correct and adds value. We also are keen to hear feedback from outside of TrustQuay, and frequently have sprint review sessions with our customers. We strive to release a new version of 5Series following 3 sprints of development effort and a concentrated testing phase known as 'hardening'.
This frequent release of the software is one of the 12 principles of the agile 'manifesto' - 'Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.'
Competitive Advantage
The increased number of releases means our customers are not waiting an age for new exciting features to be released in the software, and in addition, we receive feedback regularly and quickly on new features. Allowing us to iterate over the design, refining and improving on the initial delivery and delivering software in increments of value.
By Microgen adopting an agile approach to software delivery, the analysts, customers, and developers are working in close collaboration and we welcome 'emerging requirements'. The agile manifesto promotes 'Working software over comprehensive documentation'. That doesn't translate to 'skip documentation', far from it, and when we adopted agile we were keen not to throw the baby out with the bathwater and wanted to keep the value-added components of our previous process. Therefore, documentation, procedures, and processes still have their place in our world. However, we favour collaboration and discussion to identify requirements and adjust accordingly if new requirements emerge during the development process.
As with anything in life, change can be daunting and unsettling. However, when transitioning to agile we found some unexpected benefits. Deeper levels of trust were built within the team and also with our clients. In addition, prior to the introduction of an agile way of working, the development team found that the workload came in 'peaks and troughs', with heavy demand once a specification was delivered from the analysts to lower demand once handed over for QA. Given the nature of agile 'sprints', the development team has a consistent backlog of work resulting in increased productivity, and the benefit to our customers from this is reduced time to market - giving them a clear competitive advantage.
Win-Win
The adoption of agile has been a positive experience for the development group at TrustQuay. Software is released more frequently and the feedback loop is therefore shortened. We can adjust and make changes based on that feedback, and that has to be positive not only for TrustQuay but even more importantly for our customers. I'm not promising that some elements of the poster mentioned at the beginning of this blog post will never materialise again in this brave new agile world, but we've gone a long way to consign the principles behind it to history.
Want to know more?
If you would like to understand more on how our 5Series software solution can give you a competitive advantage or would like to chat with me or the wider product team about this, just send an email to us at info@trustquay.com.
Philip Taylor is a Product Owner at TrustQuay Financial Systems and all this talk of ‘agility’ and ‘sprinting’ has him heading to the sofa for a rest.
You can find Philip on LinkedIn