How much testing is enough for software that can condemn a man to death? Traceability in an Agile Federal Government Agency Context

Using tools like TDD and ATDD, Agile provides the means to be confident that your brand new software is well tested-- even for life critical situations such as criminal justice software.  But hold on a minute!  It is a rare mission critical system that is built completely from scratch.  There are always legacy components your team didn't build or doesn't control.  Maybe the previous contractor built it-- but now they are gone and it is your problem.  How can you be certain that everything functions properly in such a situation?  How much testing is enough?  How can you know whether a system has been tested?  These are the questions that standards such as CMMI and PMBOK seek to answer with traceability.

The debate about traceability has been raging for a long time, with passionate advocates on both sides of the argument.   Projects following traditional waterfall methods, and projects that conform to PMBOK or CMMI standards often create and maintain a requirements traceability matrix, or RTM, a document that traces “shall” requirements to functional capabilities and testcases.  Some Agilists argue that the RTM is rarely consulted in practice, so the significant efforts required to maintain such a document are “waste.”  Others point out that agile practices such as TDD provide all the traceability that may be needed. This talk will explore the underlying reasons why traceability may be important and worthwhile in many Federal government contexts, and review exciting new technologies that may provide an “agile answer” to this conundrum.


Outline/Structure of the Talk

  1. What is traceability?
  2. What does a traditional RTM look like?
  3. What are the underlying concerns for maintaining an RTM?  How many of them still apply, even in an Agile setting?   What about a Federal government context?
  4. Explore Agile tools that may be used to maintain traceability
    1. BDD tools such as SpecFlow
    2. Living documentation
  5. What about legacy code?
  6. Explore Hybrid strategies
  7. Demo and workshop
    1. SpecFlow
    2. Pickles
  8. Planning your adoption strategy: what is a realistic roadmap?
  9. Closing thoughts

Learning Outcome

  1. Understand the underlying reasons why traceability has traditionally been seen as an important goal
  2. Identify a set of evaluation criteria to help determine when traceability concerns are cost or risk justified on a given program and when they may not be
  3. Learn and explore agile techniques for maintaining traceability that minimize cost and maximize effectiveness

Target Audience

Federal managers, project managers, contract officers, vendor managers, technical leaders, QA practitioners, software engineers

schedule Submitted 5 years ago

Public Feedback

comment Suggest improvements to the Speaker

  • Andrea
    Agile Coach
    schedule 5 years ago
    Sold Out!
    60 Mins

    Project success =  f (listening, feedback, intentionality, practices) 

    To make your agile practices and processes come to fruition, you need to cultivate an environment that promotes listening, learning, inquisitiveness, intentionality and top notch feedback that everyone is comfortable with. 

    Agile projects succeed when there are frequent high-quality reinforcing feedback loops. I will share communication models based on Clean Language questions of David Grove and the Systemic Modelling techniques of Caitlin Walker that can greatly increase clarity, sense of purpose and listening skills within your team and collaborative endeavors.  These include: Clean Questions, Clean Feedback, and Clean Setup.

    This is a hands-on, try it out, concrete practice session.

  • Liked Shawn Faunce

    Shawn Faunce - Engaging a Product Owner on a Government Contract: Challenges and Solutions

    30 Mins

    Great systems require active, capable Product Owners.  Functional innovation is not possible without their commitment and involvement in the project.  Too often in government contracting, the Product Owner is an Absentee Owner.  Agile Development teams often seek out tools and techniques to create great systems, however too frequently what is holding them back is the lack of an engaged Product Owner. Teams in this situation must face the elephant in the room if they desire to build a system that brings positive change in efficiency, productivity, quality, usefulness, and adoption.  This talk shares solutions I have used for challenges I see again and again on government contracts.

    The talk begins with some introductory material on the problem, its causes, what I mean by functional innovation, and why this is required to build great systems.  I describe four challenges with Product Owner engagement that are not unique to government contracting, but that I see recurring on projects: committing staff, procurement practices, role ambiguity, and absentee ownership.

  • Liked Raj Indugula

    Raj Indugula - Agile Testing: Guiding Principles and Enabling Practices

    Raj Indugula
    Raj Indugula
    VP, Technology
    schedule 5 years ago
    Sold Out!
    60 Mins

    Despite the belief that a shared context and collaboration drives quality, too often, software testers and quality professionals struggle to find their place within today's integrated agile teams.  This session is a practitioner’s view of testing and testing practices within an iterative/incremental development environment.  We will begin with a discussion of some of the challenges of testing within an agile environment and delve into the guiding principles of Agile Testing and key enabling practices.  Agile Testing necessitates a change in mindset, and it is as much, if not more, about behavior, as it is about skills and tooling, all of which will be explored.

  • Liked Craeg K Strong

    Craeg K Strong - Lean Documentation in a Federal Government Context: How an Agile team can meet mandatory Federal IT governance documentation requirements

    3 Mins

    Many Federal government agencies are implementing Agile methods in addition to or in lieu of traditional waterfall lifecycle models.  However, comprehensive documentation is often still required by Federal IT governance, legal, regulatory, or statutory frameworks, or to meet outside audit or “watchdog “ requirements.   The Agile Manifesto values “working software over comprehensive documentation,” but that does not mean that Agile teams cannot or should not produce valuable documentation.  Although there are some well-publicized Agile success stories in the federal space, some agile federal projects are receiving criticism for failing to meet applicable standards when it comes to documentation deliverables.  With Agile’s emphasis on small, lean teams and intensive technical practices such as pair programming, meeting documentation requirements set forth by Federal IT governance poses challenges for Agile teams in the Federal space.  This session will review the documentation that is typically required in a heavily regulated environment, and discuss specific techniques for reducing, replacing, generating, or “slimming” the document deliverables.  Specific tools, techniques and best practices will be reviewed and analyzed with “before” and “after” snapshots and a look at cost versus benefit.    Documentation generation is an area of intensive activity with some very exciting new developments that can change the game significantly for the better!  Tune in to share insights and discuss strategies for breaking down one of the last big barriers to significant agile adoption in the federal space.