Agile Wars: A New Hope
This is the final article of the Agile trilogy. To sum up, we have gathered everything you need to remember about hybrid solutions, project management artifacts and risks.
If your team is experienced enough, consider going hybrid
Want the best of both worlds? Go hybrid! A major Australian energy provider did just that, combining the predictability of classic software development approach and flexibility of Agile frameworks when rolling out its major business transformation program. End result? They delivered the project just fine, albeit a few months late. Having ditched empathy-inducing customer journeys for a clear-cut project scope, while keeping the just-in-time requirements for Agile delivery pipeline, did the trick. Introduction and rigorous maintenance of a requirements-traceability matrix (RTM) that mapped on to user stories in JIRA introduced another level of project control that ensured both business, non-functional, and compliance requirements have been met. The moral of this story? If you are in a heavily regulated environment, do not go Agile without some system of checks and balances to ensure your BAU operations or a finite project stays on track. Making sure the development of a user story does not start until it gets labeled with a “Product Owner-approved” metadata tag is another step towards ensuring that what gets coded is what the business actually needs.
Our recent projects at NIX Solutions indicate that tailoring your development methodology to use the best of both worlds, Agile and Waterfall-ish, is by far not as bad as it sounds. There is a good deal of hybrid methodology projects done right, with one success story involving across-the-board tweaks to Agile workflow: no mandatory feature demos after each sprint (as each demo eats up the time needed to properly prepare for it), variable sprint lengths, etc. Shifting over to demos after every fourth sprint helped everyone achieve the proverbial win-win: stakeholders could finally play around with something relatively complete vs half-baked features, while both QA engineers and technical writers finally had a chance to give demos some extra spit and polish.
Reinforce it with classic project management techniques
Agile methodology tends to rest on a benevolent idea that teams will self-organize and communication channels will never clog up, with team members wising up each other non-stop about the daily progress. Right… Do not fall for that trap, and have some minimal project-management artifacts in place. Specifically, anything that might derail a project (if it is a project rather than business-as-usual ops that you are doing), risk owners, and any follow-up actions. Bring it up at least during retrospectives, update, re-assess, and mitigate those risks. That never hurt anyone, particularly with Agile projects that tend to turn into a run-away horse with continuous delivery cycles, and yet no final milestone in sight.
Our tried-and-true approach reveals that there is another upside to injecting classic management best practices into your Agile endeavour: if your development stream is large enough, you simply cannot afford not to capture (and share!) workarounds, knowledge articles, or code hacks with other team members. A real-life example is an Agile team of teams, around 5 developers in each of the teams. Being geographically dispersed and yet working on the very same project, scrum masters have to coordinate and share their teams’ progress, be it a Confluence knowledge-base or conference calls. On a recently completed feature, one of the teams had gone to extraordinary lengths to develop the crafty workaround for a security framework deficiency that the vendor’s technical support team promised to fix later if ever, come the distant releases. Fast forward several sprints, and the team in a different country stumbled upon the same issue. Had it not been for information sharing across all teams and classic approach to capturing documentation artefacts, the other team might as well have easily wasted and sunk weeks on trying to develop the workaround already taken care of and captured on Wikis by another team.
Achilles heel
Last but not least. Agile frameworks do not handle non-functional requirements too well (i.e. performance, security, uptime) in the sense that Product Owners, Business Analysts, etc. tend to often leave them out simply because non-functional requirements do not easily fit into the ‘as-a-user-I-want-to-so-that’ user story mould. Think ABS that used Agile for its Census 2016 and was left red-faced because of DDoS attacks as apparently no one on the project board seemed to give non-functional requirements any thought. Do the same, and you are guaranteed to be left with negative publicity and irate users.
Continuously probing for non-functional requirements (NFRs) may have an enormous potential pay-off. A well-documented tender submission big on features and user-friendly UI checked all the right boxes except for the fact that business analysis team failing to consider data-hosting implications, and assuming hosting the users’ personal data in the US or EU would be just fine. Only to find out that the prospective government client could not legally opt for either, and had to comply with users’ personal data being physically hosted in their country of origin, as AWS or a private cloud at a minimum. Bottom line? Time and money wasted on tender research, preparation, and submission.
So is there a safe way across the quagmire of NFRs? Both “Agile Companion 1.0 to BABoK 3.0” and most of leading Agile coaches recommend using technical stories, cf. https://rgalen.com/agile-training-news/2013/11/10/technical-user-stories-what-when-and-how to ensure non-fuctional requirements make it to the list as well. Give them a thought next time you kick off an Agile project!
