Hands-on with Progress Tracking Cards: A Lightweight Method for Improving Your Software Practices
2:30 PM - 4:00 PM
Wed Feb 5, 2020
Founders I (Classroom - Max Capacity: 60)



This hands-on session is an opportunity for project contributors to level up their team’s software engineering practices. Led by the IDEAS-ECP team, this session will provide a brief overview of the Productivity and Sustainability Improvement Planning (PSIP) process. Attendees will learn about the value of user stories (as a flexible means for communicating about software requirements) and how to organize a PSIP cycle within their own team. For the hands-on portion, attendees may select a Progress Tracking Card (PTC) from the BSSw catalog and customize it to fit their current team and project, or define their own PTC.

PSIP is a software process improvement methodology that can help teams increase software quality while decreasing the effort, time, and cost to develop, deploy, maintain, and extend the software over its intended lifetime. The PSIP workflow is lightweight, intended to fit in with a project‚Äôs standard planning and development process.  A core tool of the PSIP process is the PTC – brief document containing the goal of the planning activity and a step-by-step list of qualitative descriptions and values that help to track progress. The purpose of the PTC is to help a team set and achieve improvement goals. The PTC is not a tool for external assessment or comparison with other projects.



This session will provide an overview of the Productivity and Sustainability Improvement Planning (PSIP) process: a lightweight, iterative workflow where teams identify their most urgent software development and sustainability bottlenecks and track progress on work to overcome them. It will include a hands-on session where participants are given the opportunity to reflect on existing practices in their current projects and create a plan for improvement. These plans will come in the form of Progress Tracking Cards (PTCs) which will be adapted from the existing BSSw catalog.


The objectives of the PSIP process are to capture and convey the practices, processes, policies, and tools of a given software project. The PSIP workflow is intended to be lightweight and fit within a project’s planning and development process. It is not meant to be an assessment or evaluation tool. Instead PSIP captures the tacit, more subjective aspects of team collaboration, workflow planning, and progress tracking. Additionally, in the potential absence of planning and development processes, and as scientific software teams scale to larger, more diverse, aggregate teams, unforeseen disruptions or inefficiencies can often impede productivity and innovation. PSIPs are designed to bootstrap aggregate team capabilities into best practices, introduce the application of appropriate resources, and encourage teams to adopt a culture of process improvement.

At the core of a PSIP cycle is a PTC. This brief document contains the target, or goal of the planning activity, title of the topic of improvement, and a step-by-step list of activities or outcomes that incrementally lead to improvements in team effectiveness and efficiency. Teams may select PTCs from the PTC catalog, define their own PTC, or modify PTCs found in the catalog. The purpose of the PTC is to help teams set and achieve improvement goals. The PTC is not a tool for external assessment or comparison with other projects. In fact, since PTCs are custom-designed for each project, comparisons are typically not possible.

Goals: The outcome of this session will concrete steps that teams can take to improve their development practices, in the form of a PTC. Participants will learn some of the skills needed to approach their teams and precipitate process improvement.

Target audience: Process improvement is valuable for all teams, but the lightweight nature of PSIP and PTCs is ideal for scientific software developers. Scientific software teams are typically focused on obtaining scientific results from the software they write. Funding is for generating results, not software. In this session, we will target individuals and teams that have little or modest formal software engineering training.

Elsa Gonsiorowski Systems Software Developer, Lawrence Livermore National Laboratory
Reed Milewicz R&D Staff, Sandia National Laboratories
Elaine Raybourn Principal Member Of The Technical Staff, Sandia National Laboratories