The Audit Path – Staying Agile within an SDLC

In an ideal Agile environment you are a small, quick organization full of smart people who are experts in their field.  This is an uncommon ideal. The more common scenario is a large or well established business that sees agile as a way to become more relevant to their customers.  These organizations come pre-packaged with processes and procedures around software development, security, and privacy.  In short they already have an SDLC (software development life cycle).

 The common Agile temptation is to run your own race, buck against the system in its entirety and assume you can do it better.  That may be so. What I’ve found in Practice, however, is that those teams are required to live within an SDLC to deliver at all.  And while it strains Agile ideals, understanding the critical point of the SDLC can lead to creative ways to fulfill its requirements in better, faster ways.  In short understanding the SDLC and applying Agile tools and processes to fulfilling it can help transform the SDLC as a whole.

The Audit Path – Track Backwards

Understand, not blindly adopt.  Once you understand what your SDLC needs to accomplish, and for what purpose, you can propose more agile solutions to help you deliver quickly and continuously while fulfilling your SDLC requirements.  I have found the easiest way to identify the critical points of your SDLC is to follow the Audit Path, backwards.

The Audit path is how you trace back a problem when it is identified from an Auditor. Its is a full backwards trace from implemented functionality to initial ideation.  It starts with understanding what your auditors look for, whether accumulated defects, compliance to company or government regulations, Performance….whatever gets considered broken or noteworthy is where you should start.

From there you work backwards into your release plans/tools, versioning practices, ticketing system, code review, code management repository, ticket creation and alllll the way back to ideation or identification. This view focuses on one unit of work as defined by the audit flag that might trigger. Its a useful way to see how development flows through your SDLC and understand it at a micro-level.

That could mean understanding your Release Plan, the tools used to track it, back to code management, through team review, all the way to work initiation and maybe even to idea from the user.  If you understand the audit path, you can ensure you intersect in the right places, even if you don’t get there in the same way.

SDLC/Agile Opportunities

Walking your audit path should provide you with a punch list of tools, approvals, databases etc.  At that point you can form a plan to insert your agile practices into the critical points of your SDLC.  Here is  a quicklist of the most common SDLC/Agile opportunities:

  • Requirements approval
  • Requirements retention
  • Test scripts
  • Code repository
  • Code Review
  • Test results
  • Push Approval to QA
  • User Testing
  • Push Approval for Production
  • Production Testing

Some Agile Practices that Satisfy

This list assumes that your SDLC will be satisfied with the spirit, or better of its requirements at each step of the audit path.  The Spirit, for example, would be recording code review approval somewhere it can be retrieved and matched to the code instead of via outlook email to a group email address or Identity Management workflow.
SDLC Requirement Some Agile Tool Solutions
Requirements approval Sprint backlog is stored in work tool/code repository.  The Product Owner controls the backlog so approval is implicit in its presence.
Requirements Retention The User Story can be stored anywhere. if your user stories contain architectural documentation include the feature into an updated architecture map. Link that version of the architecture map update to your work management tool.
 Test Scripts Choose a code repository tool, like GitHub, that allows you to write the tests in the tool, execute in the tool, and store local results.  All the records follow the code, usually by unique identifier.
Code Repository  Depending on whether you are setup for continuous delivery or not, you’ll want to ensure your tool is identifying or versioning Master according to each pull request it absorbs. Having all the records attached to the pull request is Wonderful for backwards tracking and seamless for the development team if setup correctly.
 Code Review  This is as simple as a +1 in the Code Repository Pull Request
 Test Results Write your tests in your repository – choose a testing tool that is compatible or write an API.  Schedule the tests to occur upon pull requests. Tests run, test results stored in the testing tool but are traced back to the work ID in your work system AND tracked to the version number through the eventual push to master.
Push Approval to QA/Production  Approval in the Pull Request in your work management tool
User Testing & Production Testing  You can manually link results of your User Testing to your work record in the code repository.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s