The Pivotal Glossary

This list is by no means complete. It is merely an MVP (you’ll learn about this term below) that we’ll continue to iterate on. Since it’s bound to get crazy-long, the list is split into easily browsable sections: Commonly Used Phrases, Product-related Acronyms, Roles, Iteration Workflow, Workflow and Process, and Methodologies.

If you think something is missing from this list, leave it with a definition in a response to this post.

Roles and Disciplines:

At Pivotal, we make an effort to staff engagements with balanced teams. This means having the right skills on a team in relation to the work they’re engaged in at the moment. When we work within this construct, we ensure that all perspectives — design, product management, and development — blend and inform each other so that we build products that are desirable, usable, and feasible.

• Design
  For Designers, the product should be something that users want and that solves real problems. Designers’ primary question is, “How is the user affected?” Designers more than anyone else on the team will help us solve for, “Is this a problem for users?” We expect our designers to be full-stack — they can easily shift between IA (Information Architecture), UI (User Interface), and UX (User Experience) skills as needed, as well as implementation.

• Product Management
  For Product Managers (PMs), the product has to support a sustainable business model. Product Managers’ primary question is, “By solving these specific user problems, are we creating valuable business outcomes?”

• Development
  For Engineers (also referred to as devs), the product implementation has to be feasible and robust. Engineers’ primary question is, “What are the technical complexities related to which technical implementation that satisfy the project and product goals best?” Engineers help us debate potential solutions and the technology constraints and realities of what we’re trying to do. Developers at Pivotal are also full stack — meaning they can work on both the front- and back-end side of the code.

Anchor: An experienced developer who, in addition to coding full-time, acts as a resource for the rest of the development team for technical and non-technical issues. They generally remain on the project from beginning to end.

CL (Client Liaison): The CL is responsible for the client relationship and the overall success of the project from the perspective of both the client and Pivotal.

DevOps (Development and Operations): A practice that emphasizes collaboration and communication between both software developers and other IT professionals while automating the process of software delivery and infrastructure changes.

IA (Information Architecture): The art and science of organizing and labeling websites, software, etc. to support findability and usability.

Pivot: (1) Synonym for current and former employees. If you work (or worked) at Pivotal, you’re a Pivot. (2) Pivotal customers that adopt our approach to modern software development are considered honorary Pivots. (3) A marked change in product direction.

UI (User Interface): The UI is everything designed into an information device with which a human being may interact; or how an application program or website invites and responds to interaction.

UX (User Experience): The process of enhancing user gratification by improving the usability, accessibility, and satisfaction provided in the interaction between the user and the product.

Methodologies:

A list of the approaches and styles we use for developing software here at Pivotal.

Agile: A software development methodology based on iterative and incremental development, in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It is a conceptual framework that promotes well-planned, small iterations throughout the development cycle. Teams that develop with agility optimize for learning about and responding to change; each time a team talks to users and stakeholders or builds or releases a new feature, they learn new information. The iterative approach enables the team to constantly act on new information and keep feedback loops short.

Lean Startup: Lean Startup is a practice, pioneered by Eric Ries (author of The Lean Startup, and Pivotal’s Entrepreneur–in–Residence), of launching a product rapidly to test assumptions, and then using customer feedback to evolve the product and reduce waste.

XP (eXtreme Programming): A flavor of agile methodology, XP highlights pair-programming, automated testing of code, avoiding programming features until they are needed, simplicity and clarity in code, expecting changes in the customer’s requirements as time passes and the problem is better understood, and frequent communication between all involved.

Pivotal Products-related Acronyms:

Great software needs support. That’s why Pivotal products (some of which are defined below) help developers all over get back to creating value and doing what they love: building, shipping, and running software.

BDS (Big Data Suite): Composed of Pivotal GemFire, Pivotal Greenplum, and Pivotal HDB, the Big Data Suite is our comprehensive platform of open data management solutions that allows enterprises to modernize their data architecture, discover more insights from their data with advanced analytics, and build analytic applications at scale.

BOSH (Bosh Outer Shell): An open source tool for release engineering, deployment, lifecycle management, and monitoring of distributed systems, like Cloud Foundry.

Cloud Foundry: Open source PaaS you can use to run 12-Factor applications. While Cloud Foundry is managed by the Cloud Foundry Foundation, it is a collection of smaller projects, each with its own PM, and the majority of those PMs are Pivotal employees on the R&D team.

DIEGO (Droplet Execution Agent written in Go): Diego is the container management system for Pivotal Cloud Foundry. The acronym should really be DEAGO, but who’s counting.

PaaS (Platform as a Service): A PaaS (pronounced pæz) is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app.

Pivotal Cloud Foundry®: Pivotal’s commercial version of Cloud Foundry, with additional functionality that guides you through set-up and does a lot of the work for you. Pivotal Cloud Foundry is an extension of our belief that modern software companies should be able to deploy code across all your environments, around the world, in seconds.

PWS (Pivotal Web Services): Sometimes referred to as “P-Dubs”, PWS is an application platform that is the publicly available version of Pivotal Cloud Foundry. PWS enables developers turnkey access to all the benefits of Pivotal Cloud Foundry all with just a credit card.

Spring: The Spring Framework is an open-source, Java framework that provides comprehensive support for developing Java applications. Spring handles the infrastructure so you can focus on your application. Nearly all of the Spring team are Pivotal employees but there are thousands of Spring contributors.

Workflow and Process:

These are words that may come into play when we’re building products or working on an engagement with a client.

AI (Application Instance): An Application Instance is a term used in Pivotal Cloud Foundry. It is a singular instance of a Cloud Foundry app that is deployed, and it occupies one allocation in a Diego cell. If there are ten app instances of one app, then there are ten running droplets of that app. Note, AI may also stand for Action Items, or, if you’re into that sort of thing, Artificial Intelligence.

Build: In a continuous environment, a build is a single processing of source code that produces an artifact for consumption in a later stage, or is a completed set of stages of a pipeline that produces the final artifact.

CATS (Cloud Acceptance Test Suite): Similar to BATS (Bosh Acceptance Test Suite), this is how we know our code is going to work. And no, we don’t name all tests after animals.

CD (Continuous Delivery): Continuous Delivery is a software development practice that allows automated software delivery and frequent releases, with little or no manual intervention. Continuous delivery provides the ability to reliably push software updates to users with no downtime, and the lag time from idea conception to production is minimized.

CI (Continuous Integration): Continuous Integration provides immediate feedback, historical results, and accountability. CI Systems are designed to automatically execute a suite of tests for each build and expose any errors in the process for immediate attention. You can’t have CD without CI. Concourse is our open source CI system that works out-of-the-box with Git repositories, S3 buckets, and other common external services.

D&F (Discovery and Framing): Sometimes mistakenly heard as “DNF,” this is Pivotal’s collaborative process that explores and validates product ideas to gain the definition and confidence needed for implementation. It covers the main goals and risks of the engagement, and focuses on user needs, experience, and value propositions at a high level. A D&F is typically held at the kickoff of the engagement, and the work done in those few weeks carries throughout the entire project.

Feedback Loop: For software, this means writing the feature, integration, and unit tests first, then writing code, so that feedback on the state of the code (and validation that it meets our understanding of requirements) is received in real-time. For humans, having shorter loops means that feedback received from users, stakeholders, and clients can be incorporated in a more timely fashion. Because Pivotal’s balanced product teams are small, co-located and multi-disciplinary, we also have short and frequent feedback loops between different perspectives and roles. If a developer pair has a question about the business value of a development task, all they have to do is turn around and ask the Product Manager.

MVP (Minimum Viable Product): A type of experiment that we view as the smallest possible version of our product that we can deliver — and most importantly — learn from. An MVP is not meant to be cheap, or final, but it must represent a valuable solution to the problem and give us a canvas upon which to iterate.

Pairing: Pair programming is the practice of having two developers work together at the same computer to complete each task. This practice leads to better decisions the first time around, fewer defects, better code, and ultimately much more sustainably efficient development. As pairs rotate, knowledge is spread rapidly through the team, avoiding knowledge silos. While pairing is most common among Pivotal engineers, we also pair within and across other disciplines, such as product, design, and R&D.

Personas: A detailed sample user of the product, based on averaging the patterns, goals and actions of a variety of actual users; personas are used to gain and retain empathy for the users we are solving for through exercises like scenarios.

PPI (Pivot Pong Interview): This Pivotal interview process is one we conduct with potential designers and product managers. It is, in part, a thought experiment where we try see the candidate come up with the simplest answers to a problem. For design candidates, this means constructing the simplest possible wireframes, for product, it’s coming up with the basic feature set for an MVP.

Prod: Short for Production, this is the environment your code resides on when it “goes live.”

RPI (Rob’s Pairing Interview): An RPI is an interview process named for Pivotal’s CEO, Rob Mee. This engineering interview style is about demonstrating a basic level of curiosity and the ability to communicate well. To pass an RPI the candidate must show that they are able to construct and logically to address problems, but passing does not necessarily mean that they are technically able (that’s for a different interview). The RPI has remained relatively unchanged since its inception.

Scoping: Prior to engaging with a potential client, these sessions are used to determine if we can support the project and if so, with what approach.

Staging: Where you push your code to test it before it goes live for all to see. Our CloudOps team calls their version of Staging “Jeff,” which we find hilarious, because it lets us say “we’re going to push to Jeff.”

Standup: A short, daily meeting. Most Pivotal locations call office-wide standup at 9:06am — immediately after breakfast — followed by break-out team standups. Most revolve around three agenda items: New Faces, Helps, and Interestings. New Faces is an opportunity to make introductions during standup to anyone new at the office that day, which could include anyone from a new client to an interviewing candidate. Helps offer Pivots a chance to ask peers for assistance, and Interestings allow time to share not-necessarily-work-related items.

TDD (Test-Driven Development): Test-driven development is a practice wherein the developer initially writes automated tests for a given feature, then codes the feature itself and ensures that it passes the tests. In other words, all code is guilty until proven innocent.

Iteration Workflow:

An iteration is planning and development cycle, typically spanning one week. An iterative and incremental process allows for change as we learn more about user needs, business goals, and technical implementation.

Acceptance Criteria: Usually included in user stories, these list specific tests and expected behavior from the user’s perspective that the application must pass in order for the story to be treated as complete.

Backlog: A list of prioritized stories that make up the planned work for the current iteration. Stories can be added and removed from the backlog and are continuously reprioritized during an iteration as the team learns new information.

Epics: A collection of stories that make up a larger product release, feature set, or development focus, and are useful for prioritizing and tracking groups of stories against other groups of stories.

Icebox: User stories that have not yet been prioritized.

IPM (Iteration Planning Meeting): The IPM is a weekly tactical planning meeting. Typically led by the PM, its aim is to ensure that the backlog is in good shape, and that the team members have a shared understanding of what the stories mean. Together they make sure the upcoming stories are validated, prioritized, and ready for developers. This is also an opportunity for the client to communicate the vision for the upcoming iteration.

Points: How a story’s complexity is measured, using either a linear-, Fibonacci-, or powers of 2-based point system. During an IPM, developers discuss and agree on point estimates that reflect stories’ complexities to the best of their understanding. Typically, stories rating 4 or higher are placeholders for further conversation.

Retro: Short for Retrospective, this meeting allows teams to give ASK-style feedback to each other. Team members will each identify aspects of the previous week that were both good and bad, reflect on issues raised, and assigns action items to remedy any issues. Retros often begin by reviewing the previous week’s action items to improve accountability. And sometimes they have wine and cheese.

Tracker: Officially called Pivotal Tracker, this is a widely-used homegrown agile project management tool for defining and tracking project lifecycle as a collection of prioritized software development tasks.

User Story: A user story is a definition of a product feature written in a user-centric, value focused, and narrowly tailored way. User stories are designed to explain the who, what and why of the smallest incremental feature that can be added to a product. A story typically follows the form: “As a <role>, I want <goal/desire> so that <benefit>.”

Velocity: A measure of how many expected points a team can deliver in a given iteration calculated by averaging the points delivered in previous iterations. Teams track their velocity to be able to have more confidence in their planning, and as a proxy for team efficiency and happiness. A choppy velocity indicates that the team wasn’t able to release new features and functionality with consistency, and decreases the team’s predictability.

Commonly Used Phrases:

While a lot of these phrases are not coined by Pivotal, they are things you might hear in one our offices around the world.

ASK (Actionable, Specific, and Kind): Pivotal has a strong feedback culture that originally grew out of our pair programming practice. ASK are the principles we use when we give each other feedback. Making explicit what good feedback looks like makes it easier for us to share high quality feedback often, which in turn makes us better at paired collaboration.

Done Means Done: This saying from XP is used when describing how to know a task is complete. When you ask for a feature it’s only “done” when the code is tested and clean, and the feature works and is ready for production.

DRY (Don’t Repeat Yourself): The DRY principle states “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” Apropos of DRY sometimes you just have to WET, which stands for “write everything twice.”

Keep it Simple: Simply, an overall company philosophy.

Strong Opinions, Lightly Held: It is important to be flexible in your beliefs — however strong they are — because otherwise it undermines your ability to take in evidence that clashes with your opinions.

TLA (Three Letter Acronym): Usually the first letters of a three-word phrase, TLA is itself a self-referencing definition. As author Douglas Adams said: “The World Wide Web is the only thing I know of whose shortened form takes three times longer to say than what it’s short for.”

Thanks!

Thanks to the following, who helped me think about jargon and assisted in providing definitions:

Jim Park and James Young (Cloud Ops); Sid Ho and Mike Stallard (IAD);