How we do business

Potentially Shippable Increments (PSI) allow us to move fast without losing focus

While reading this article, note that I subscribe to what I call "agile with a lowercase a." What you'll read here is not strictly out of the Agile playbook. In the past, I was a certified Agile Scrum Master and what you'll read in this post is not that. Here, I'll explain what I've seen work and how the Prelude team is operating internally based on the principles of a PSI.

While leading a software development team for Innovative Software Engineering (ISE), a contractor of John Deere, I was introduced to something called the Software Development Life Cycle (SDLC). The cycle defines "the business of writing software."

Technically, SDLC is a 8-step process to follow when building software solutions in a business environment. The steps are:

  • Planning

  • Requirements

  • Design

  • Build

  • Document

  • Test

  • Deploy

  • Maintain

John Deere followed SDLC seriously, implementing it through the Agile methodology.

Most of us are familiar with Agile. We think of 2-3 week "sprints" where we define what work we want to do, execute on it, then do it again. This type of Agile is great for small teams but as you grow, so should your process. Sprints don't naturally allow you to look ahead and plan/forecast your upcoming work. A Potentially Shippable Increment (PSI) is an enterprise agile tool which allows you to create a block of sprints and split your work across them. A typical PSI may include 3-5 Sprints and should be aimed at solving problems, not creating small features. A PSI is designed to be capped with a literal release of the software which solves the problems.

Here's how it worked:

  • The company would meet with a small group of "power" customers, who would help drive objectives based on real-world problems.

  • These problems would be overlaid on top of business objectives the company had already established. This would result in 5-8 well defined objectives for the business to complete.

  • All technical teams would then co-locate for 2-days. They would first get introduced to the problems in a conference-style meeting. Then they would break into individual teams, where their project managers would define each team's specific role in solving each problem, as applicable.

  • The 2-day summit would end with each team having planned out their solutions, which were expected to fit within an 8-week block, consisting of four 2-week sprints.

  • This process would repeat every 8-weeks.

I was fully ingrained in this process for a few years, as an individual contributor, team leader and a project leader. In following years, I adapted this model for different companies as I managed teams and departments.

Enter Prelude

At Prelude, our development team follows a light PSI model, customized around the unique skill set our our talented engineers. Here's our process in a nutshell:

We organize around three 2-week Sprints, equaling a 6-week PSI. Each Sprint is labeled with A, B or C.

Step #1: Customer discussions

Two weeks before we start a PSI, we connect with our customer cohort to see what is and isn't working well for them in the field. We succeed and fail with our customers so everything starts there. Our cohort consists of a small group of power users who come from different backgrounds, red/blue, big/small, experienced/inexperienced.

Interested in joining our customer cohort? Reach out to us at support@prelude.org.

Once we understand the short term goals of our customers, we move on to internal discussions.

Step #2: Internal discussions

One week before the PSI, we meet internally to discuss the customer problems. We map this on top of our roadmap for the year and look for overlaps and holes. Based on what we see, we define 2-3 objectives for the team to execute on in the coming PSI.

Step #3: Planning

On PSI day we review our objectives as a full team. We discuss the objectives from the perspective of solving problems. Each objective we do should solve a distinct problem for our customers, otherwise it won't make the cut. With the problem stated and a general solution outlined, our team discussion revolves around poking holes in our implementation ideas so we can flush out any surprises.

During this meeting, we assign tickets to our technical team so everyone can see how they're helping solve the stated problem(s).

We finish by laying the objectives over three sprints to ensure it is a doable goal.

Step #4: Continuous checks

Every day we do standup meetings, discussing the progress and challenges we're all facing. During these meetings, we also look ahead at upcoming tasks and start defining their scope, flushing out more surprises and generally getting the wheels turning in our heads well ahead of getting the tasks on our plate.

The frequency and duration of standup meetings should be customized to your team. There is no hard-and-fast rule. Be open to constant changes as your team grows in size and experience. There is nothing worse than executing a process for process-sake. If something isn't working or is getting stale, look to change it.

Every two weeks during the PSI we meet for a longer time, doing a full team "check point" to see if we're still on track. We then position our next set of tasks in a sprint and start the iteration process again.

As we plan our sprint tasks and assign them out, we keep an eye out for two things:

  • Scope creep: Every ticket is given a Definition of Done (DOD) which clearly states what it means for that ticket to be complete. It's common for additional scope to be requested during a task, so we combat that by writing down what complete means before we start.

  • Estimated time: We take a swing at estimating the time each task will take so we can ensure our technical team members have no more than 75% of their time dedicated to business objectives. This seems counterintuitive at first but if you have solid technical talent, part of squeezing the most out of their skills means giving them room to breathe. You need to leverage their creativity not just their ability to follow through on defined objectives.

"I work in security, therefore this type of planning could never work for me." 

I've heard this comment at every company where I've set up a PSI structure for the red and blue teams. Of any sector that fights process, security has to be near the top. However, the PSI model can be applied with great success in the fast-paced, unpredictable world of cybersecurity work. You just need to plan for the unplanned. The PSI structure isn't waterfall: you aren't defining every task to the nth degree weeks in advance. You're plotting out the structure of how you want to work. In some organizations, this means planning at the task level. In others, it may mean lightly defined tasks. The key is to create clear boundaries around the work you're doing, centered around solving problems.

Here at Prelude, we sprinkle in other meetings, as and if they become relevant to us. Here are ones on our current calendar:

  • The Moonshot meeting. Here we spend a couple hours tackling hard problems.

  • The Tech Talk meeting. Here we spend 20 minutes, twice a week talking about a specific security topic. The goal is to spread knowledge and ensure all team members, especially those without security backgrounds, have a level-set on what to know.

  • The Deployment meeting. Right now, we're focused on creating a smooth, repeatable deployment mechanism for Operator versions. As such, we meet as a team to deploy the latest version of the software.

Here is what our calendar looks like, on a rotating 6-week cycle.

Lessons learned

Through applying the PSI at multiple companies - including giants like John Deere, FireEye and MITRE - I've noticed a few things that seem to be in common:

  • Technical teams respond well to process. Most technical staff will say they hate process - but only because they've experienced overbearing rules in the past. In reality, putting simple bounds around work (the PSI) - through the lens of solving problems - allows the team to focus on well defined problems.

  • Individuals are at ease. Without a process, good technical people feel like they can't take a break. If they're not "on" all the time, the project they’re on could change at any time. Decisions could be made behind their back, not out of malicious intent, but because a project manager is acting on a whim. A process where the work is well defined for the coming weeks/months allows technical people to be at ease, work deliberately and take time off without fearing things will be different when they return.

  • You need to allow for creative space. Business objectives are important - and they're how we get paid - but if you hire top talent (you should) you need to allow for creativity. The best technical workers aren't worker-bees. They have ingenuity and understand problems from a different perspective. By ensuring their schedules are only 50-80% full of "work" you'll end up with 100% of their applied skills.

  • Don't rock the boat. This one is important: as a project manager in charge of managing the scope of the work, do not change the objectives in the middle of a PSI. If you do this, you're throwing a wrench in the entire process. As a business - no matter how fast moving - you should be able to plan and stick to objectives in 6-week blocks. If you can't, you are lacking a focus at the business level and need to fix that first. Tasking should be agile and open for change throughout a PSI - but the objectives themselves should be set in stone and only rarely changed.


Here at Prelude we try to be open about all aspects of our operation, both by supporting the open-source community with our code as well as describing our internal processes. We hope this helps you think about process differently and maybe apply some of it to your own teams.

As always, reach out with any questions or comments.