In a prior LinkedIn post titled “Regulated Agile” Hmm, what’s that? I discussed the “need for speed” in traditional financial services institutions (FSIs) as they in an effort to provide differentiated products. The competitive market tilts in favor of FinTechs since they’re not encumbered with legacy infrastructure and regulation. In their competitive fight the FSIs have adopted various agile practices – lean, XP, scrum, iterative, etc. – yet get stuck with a hybrid process often referred to as Wagile or WaterfallScrum. Development teams have embraced and benefited from agile practices the most. Accordingly, agility has been frequently defined as ability to rapidly deliver acceptable code within incremental time frames. The frequently used acronym of MVP (“Minimum Viable Product“) reflects the notion of getting something to market quickly, and in turn connotes agility and efficiency.
With annual expenditures to debug software failures at 620 million developer hours and $61 billion dollars per a Cambridge University study one must wonder if we are racing past the facts. How effective are we, if our efforts require such massive rework? Where is the trade-off between efficiency and effectiveness? How do we balance the “need for speed” with the needs beyond the development team, i.e. customer centricity, compliance and audit?
Need implies requirements, including the needs of the many who are afterthoughts in the software development and delivery process. Software and System Requirements are multi-dimensional in that “Requirements Management” spans elicitation, review, analysis, validation, enhancement, versioning.
Furthermore, “Requirements Management” implies a hierarchical dimension since a project requirement is most often a component of composite application which is delivered as a product or program. In that composite applications reflect the collection of code, they equally reflect the collection of requirements. Herein comes the concept of systems thinking. Today’s Financial Services IT systems are so complex that they require multiple teams to develop and manage them.
As lean, agile developers we are trained to value “working software over comprehensive documentation” (one of the four values in the Agile Manifesto) and per lean principles we must identify and remove waste, i.e. manual practices. Automated testing and code promotion have effectively eliminated tremendous amounts of manual effort in the Software Development Life Cycle (SDLC) yet other manual activities such as documentation system remain.
It befuddles me that significant roles, e.g. audit and enterprise architecture, are 1) often overseen and undervalued and 2) seen as antithetical to agile implementations; after all, their deliverables memorialize systems and provide the basis for the “learning organization,“ a concept of lean software development. Regardless of the expressed need and adherence to an institutionalized practice of documenting systems, key stakeholder (compliance / audit) require documentation, especially the “functional lineage” or traceability. Traceability implies the linkage and dynamic association of requirements to code (bases) to test and project should be classified and coordinated to programs for fulfillment. The vertical alignment, if you will, is the association of system components to the required and desired product according to functional and non-functional requirements. Can we pass the Sarbanes Oxley 404 litmus test: was this piece of code was used at this point in time to produce this deliverable (report that will be signed by the CEO for the attestation of earnings)? How can we do that in an agile stream?
A robust requirements management tool, such as DOORS Next, organizes requirements – regardless if they are elicited through traditional or agile practices – into collections but more importantly fosters traceability and re-use. These two factors serve as a very powerful way to balance the need for speed with the information needs of all stakeholders.
The financial services sector relies heavily on documents and documentation. Documents such as the 17 CFR Part 23, NY DFS Rule 500 or Proposed Rule Rel. No. 33-10515; Small Entity Compliance Guide dictate what we must do to fulfill industry mandates as we serve our customers. As evidence we must produce documentation showing that we have implemented the mandate. How great would it be if we could decompose these monolithic documents in components and dynamically reconstruct the evidence back into documents within our agile process? What if we reconstituted requirements or better yet adhere to the concept of “requirement reconstituted.“
The attached graphic shows how DOORS Next, a robust requirements management tool, can ingest machine readable test into a collection of requirements to be worked.
The outline structure of these documents facilitates the transformation into a collection (paragraph) and a requirement (i.e. sentence). Each requirement then reflects a series of attributes, state, traceability, link relationships and most importantly ownership. State is a critical in determining the completed work and open tasks to reach a state of compliance. Work can be prioritized, scheduled and managed through Kanban boards. All information is displayed in a configurable dashboard and tags support the dynamic search. That which is most compelling is the ability to produce reports at any point in time and version them.
Moreover, a robust requirements management tool like DOORS Next can visually represent the association and fulfillment of a specific requirement or a collection of requirements. The graphic shows the functional traceability and specifically how regulation has been decomposed and fulfilled. The green checkmarks show the fulfillment; if any component changes icon will dynamically change. Of course, there are tabular views and reports.
Effective adoption requires a shift in the mindset that organizations must move in unison by adopting automation technology and the discipline associated with training. No one player gets to the Super Bowl; rather, disciplined teams do. Winning teams embody star players, who know their role and responsibility to others, unified in a common goal. If you would like to explore this topic further or learn how to manifest these concepts within your organization let’s connect on LinkedIn.