Have you wondered what helps make contracts deliver better results? It's not specifying Agile approaches, but thinking of the development life-cycle, its impacts, and asking for demonstrable understanding of Agile approaches.

This short talk will discuss how a contract vehicle was established at the Environmental Protection Agency to improve contractor accountability and more importantly improve system reliability. It will include a short discussion of what next steps for following contracts should be included.

4 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

What were the problems being solved?

  • Development and maintenance were separated into multiple contracts
  • Development teams had little to no responsibility to produce maintainable software
  • This results in throwing it over the fence and in maintenance spelunking when there is a problem
  • Largest problem was an architectural issue that required months to change

What was the context? (Type of organization, information about the environment, team, technology, etc.)

  • Federal Govt Agency (Environmental Protection Agency/Office of Pesticide Programs (EPA/OPP)); takes in fees to register new pesticides and maintain exiting registrations (very little appropriations); examine pesticides in terms of human health & environmental impact and create a pesticide label on how to use the pesticide safely (label is the law)
  • Dev teams followed a waterfall process with a few hours hand-off to maintenance; additionally, the dev team did typical requirements analysis at start and UAT at end while maintenance team interacted with different parts of the business several times/week

Why was this important to solve or create?

  • EPA/OPP took in fees from registrants (manufacturers or their holding companies) that paid for people and systems (rather than appropriations sourced from taxes); failure to deliver these in the appropriate timeframe meant refunding the registrant – IT systems w/problems could contribute to this slowness
  • Not considering maintenance resulted in more problems for a different team to solve; this increased maintenance costs and reduced system reliability; system problems put the fees collected at risk for being refunded as well as potentially jeopardizing human health or the environment

What was done?

  • Created a full life-cycle BPA type contract to one vendor – this put both development and maintenance into the hands of one contractor – accountability!
  • Rather than specifying approach and techniques went with assessing past experience with Agile approaches and the results achieved along with how they thought these would apply to EPA/OPP
  • Made a quality assurance surveillance plan based on metrics – prioritized metrics differently in different task orders on the contract to allow the most important priorities to dictate how the contractor got evaluated
  • Main specification was a demonstrable practice of continuous improvement

What results were achieved?

  • Improved application maintenance; defects created and ‘spelunking’ time reduced
  • User understanding was also enhanced as Agile approaches started being used in the development area and even when they weren’t (i.e. waterfall was used), the experience of the contractor with the user in maintenance was invaluable

What were the next steps?

  • Improving metrics to increase technical health of products
  • Migrating several legacy systems to more modern architectures
  • Getting all teams focused on using agile approaches (more education on the government side)

Learning Outcome

Attendees will gain insight into -

  • leverage points for tying Agile principles to contracts
  • the relationship between contracts, development, and long-term sustainability through maintenance

Target Audience

Contracting Officers, Procurement Officials, Development Managers, CIOs/CTOs


The attendee should understand that putting items on contract is a risk sharing relationship.

schedule Submitted 3 weeks ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked Trent Hone

    Trent Hone - Systems for Learning - Lessons from the Trimble Software Framework

    20 mins

    Organizational agility requires more than “scaling.” It requires deliberately finding the balance between exploring new, innovative ideas and exploiting proven ones. Agile software techniques can enable individual teams to find this balance, but few established patterns exist for harnessing it at an organizational level.

    One successful model is the Trimble Software Framework (TSF), introduced by Trimble Navigation in the early 2010s. Borrowing from Agile, Lean, the Capability Maturity Model Integration (CMMI), and other proven methods, the TSF provided effective feedback to Trimble’s diverse collection of software teams on the effectiveness of their approaches. Where the TSF differed from other models was in its respect for variability.

    The other authors of the TSF and I recognized that by promoting continuous improvement without dictating the path it should take, software teams would be free to experiment with new methods and explore new patterns. This increased overall organizational agility as teams tailored known good practices to their specific contexts and developed new ones. The TSF became a feedback loop that enabled software teams throughout the organization to learn from one another and constantly improve. Come hear how this was done, what we learned along the way, and how we used variability to permit a more effective balance of exploration and exploitation.

  • Liked Jaap Dekkinga,

    Jaap Dekkinga, - Stakeholder involvement (sub title: How do I involve my stakeholders best in an Agile environment?)

    Jaap Dekkinga,
    Jaap Dekkinga,
    Agile coach
    schedule 2 weeks ago
    Sold Out!
    20 mins

    One of the struggles I have seen when organizations transition to Agile in relation to the Agile principle "Customer Collaboration Over Contract Negotiation" is: When and how do I involve the right customer.

    Goal of this presentation:

    • Provide tools on how to involve different types of stakeholders
    • Tool to identify different types of stakeholders

    In the presentation I will explain the 2 step process of:

    • Step 1: map out the players for a value stream, product, or feature(set) in a simple 2x2 Stakeholders Matrix (influence/power and interest)
    • Step 2: Learn about the tools and techniques to involve players in each quadrant based on their specific strength or opportunity

  • Liked Paul Boos

    Paul Boos - Describing Your Business with the Business Canvas

    Paul Boos
    Paul Boos
    IT Executive Coach
    schedule 1 week ago
    Sold Out!
    20 mins

    Do you find you need to explain you business quickly? Or that you need to understand various internal choices or external environment impacts on what you do or how you may need to adjust?

    A business canvas can be really useful for answering these questions. In this talk, I'll describe how I used a business canvas to represent the business model for the Environmental Protection Agency's Office of Pesticide Programs. By doing some logical analysis on current industry trends, I'll discuss how a colleague and I were able to develop a likely forecast of events (that proved true) that decreased the amount of registration fees we would collect. This change had a direct impact on the organization in terms of funds needed for people, systems, and analytical research.

    Learn how a business canvas can help you!