Embedded – Observations of an Agile IV&V Guinea Pig

~95% of my 25-year software consulting career has been spent in the service of, or contracted to, various offices and agencies of the United States Government. A considerable portion of the last 15 of those years has seen me plying my trade in the form of Independent Verification and Validation (IV&V) at one agency in particular; and while the name of the agency isn’t relevant to this post, the fact that I’m working for the government is. You see, to those who have been working in the public sector for decades as I have, the concepts “government” and “agility” can seem almost mutually exclusive.

With that context you’ll understand my surprise when, a little over two years ago, our team was asked by the agency to perform IV&V work on a new project that was to be developed by – *gasp* – an agile development team. This being the agency’s first large-scale foray into anything agile, the project had a high level of visibility, so management was understandably nervous and wanted us – an Independent team they’d been trusting for well over a decade – to be involved from the beginning.

In our first IV&V team planning meeting, our project manager proposed that – in addition to our already refined IV&V processes – we try out a new role called an “Embedded IV&V Tester”. The idea was that, with the consent of both the agency and the development team, one of us would essentially join the development team as a testing asset – attend daily standup meetings, test the application right in the development environment, use the development team’s own processes and tools, etc.

Not to get all Liam Neeson on you, but I have a very particular set of skills. Skills that made me a good choice to fill this role.

  • At its core, this project is the conversion of a legacy PowerBuilder system to a modern .NET web application.
    • In a previous life I worked for Sybase as a Certified PowerBuilder Developer. The agency has given me access to the legacy system’s source, so when there’s a question regarding “how we used to do it”, I can find a definitive answer.
    • I’m also a Microsoft Certified Technology Specialist, and very familiar with C#. The development team gave me read access to their source code repository so I can research specific issues as well as give IV&V input regarding the use of third party libraries, automated test coverage, etc.
  • Second, the ability to interpret. I’ve been working with this agency’s users for quite a while; I understand a significant portion of their business and terminology. Being fluent in both “private sector tech” and “agency user”, I’m able to hear both sides of every conversation clearly and correct many misunderstandings as they happen in the regular product demo feedback sessions.

However, even without those skills, I think the benefits of the basic strategy are fairly obvious.

The development team – already used to the transparency that comes with agile methodologies – saw the benefits of this arrangement right away. Not only would they be essentially getting another testing and analysis resource for free, they’d also be able to run many questions/ideas/bug fixes by the embedded IV&V tester, further shortening the already tight feedback loop of a typical two-week development sprint.  They welcomed me into their team from the beginning and have shown an ongoing level of cooperation with our IV&V efforts heretofore unseen in my experience.

The agency instantly saw the value this arrangement presented to them as well – they would now have a level of insight into the development process they’ve never had before, as we can now provide our independent opinion of how the project appears to be progressing from the inside.

By the time we hit the third sprint, one less obvious benefit emerged: the embedded IV&V tester is also in a position to shorten the IV&V team’s feedback loop. In the past, if we had a comment, question, or concern about the way something was implemented, we would submit it along with our bug reports and wait for the developers to research answers and get back to us. Depending on the development shop, that process could easily take weeks – even months – and didn’t always result in the information we were looking for.

In the position of embedded IV&V tester, being neck deep in the development environment, I found myself able to field most of our IV&V questions myself. When I couldn’t find the answer, I generally knew who to ask and had the ability to contact them directly. Changing this measure of response time from weeks/months to minutes/hours had a tremendous effect on our own ability to complete our testing and related documentation.

I don’t mean to imply that this last 2+ years has been all rainbows and kittens; there have been plenty of challenges, some of which we’re still working through:

  • Performing thorough IV&V on a two-week sprint schedule without becoming invasive and slowing the development team’s momentum.
  • Maintaining that essential “Independent” element of our title while simultaneously cultivating close and open working relationships with both the development team and the agency’s representatives on this project.
  • Finding a new sweet spot in the information density of our documentation that would allow us to provide all of the detail required by the agency without all of the redundant, time-consuming pomp and circumstance.
  • The typical ebb and flow of government funding, occasionally forcing us to adapt to less resources even though the project pace and workload remain the same.

Even with these challenges, though, I feel like this experiment has been a success. Our IV&V work on this project is more focused, more productive, and even more valuable to the final product than it ever has been before.

Leave a Reply

Your email address will not be published. Required fields are marked *