Converting a successful, ongoing project with 2M lines of code to agile presents unique challenges that are not covered in most books and courses on agile; this talk describes successful strategies used on the FBI CODIS project. This is an up-to-the-minute account of our (continuing) experiences instituting agile practices, paying down technical debt, and addressing the concerns of skeptical governance and oversight groups.
We have heard the reports of unsuccessful programs "rebooted" and rescued through the use of agile software development models. And there is a wealth of information available on how to institute agile practices such as test automation and refactoring into Greenfield projects. But what about a highly successful, longstanding, waterfall-based government program with over 2 million lines of code and 15 years of history? How do you institute DevOps practices on a project that uses 100% Microsoft platforms? How do you write automate tests and refactor mercilessly on a project where the majority of the business logic is written in SQL? How do you deliver valuable software when the oversight framework requires you to maintain over 50 separate documents? How can we institute Scrum while simultaneously undergoing CMMI level 3 certification?
  This experience report describes specific practices that we adopted during our two year (and counting) experience transforming the FBI CODIS project to Agile. Many topics will be discussed including sprint length, technical/testing sprints, technical user stories, story point budgeting, paying down technical debt, instituting agile practices such as pair programming, responding to unexpected events, and others. Each practice will be analyzed in terms of the cost versus benefits and when and how it may be most beneficial. This talk attempts to provide context and insight into when and how specific approaches might provide the most benefit for legacy modernization projects or projects answering to skeptical oversight groups.


Outline/Structure of the Talk

Outline/Structure of your session:

  1. What is CODIS?
  2. How did the project evolve over time?
  3. What are the biggest differences between the previous waterfall lifecycle and the new Scrum lifecycle?
  4. Discuss ramifications of key up-front decisions
    1. Staffing an automation team
    2. Quantifying everything we do: technical user stories
    3. Technical / testing sprints.  Why have them?
    4. When do we start sprint 1?  What is sprint “zero,” anyway ?
  5. Challenges we faced and how we met them
    1. Poor automated testing coverage, implications for manual testing
    2. Working in a time box, within a fixed price contract—what if we don’t finish all our “must do” items?
  6. Benefits we observed
    1. Ability to adjust to unforeseen circumstances: 4 months of extra unplanned effort!
    2. Customer can reset priorities
  7. Transition: Base year to option year one
  8. New Challenges in year two
    1. Meeting definition of done
    2. Maintaining technical documentation
    3. What about DevOps?
    4. Jump-starting automated testing within a legacy environment
    5. Producing an RTM: Can we create an “Agile RTM”?  How do we maintain traceability in an agile context?
  9. Looking ahead to year three: next steps
  10. Lessons learned

Learning Outcome

Sharing Lessons Learned:

  1. Agile benefits can be realized even on successful waterfall projects
  2. Understand that there is no silver bullet when it comes to Migrating legacy projects to Agile.
  3. Legacy projects need a planned, incremental adoption of agile practices
  4. Get an expert tool smith
  5. Start scrum even without everything in place
  6. Feel free to experiment, but some scrum practices are better done by the book
  7. Adopt a systems thinking approach to addressing technical debt

Specific topics will be discussed including BDD, DevOps, lightweight documentation and Continuous Delivery

Target Audience

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


schedule Submitted 6 years ago

  • Andrea
    Agile Coach
    schedule 6 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.

  • 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.

  • Craeg K Strong

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

    60 Mins

    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.

  • Raj Indugula

    Raj Indugula - Agile Testing: Guiding Principles and Enabling Practices

    Raj Indugula
    Raj Indugula
    VP, Technology
    schedule 6 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.

  • 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.