Most of the code you'll see was created with a fairly consistent and specific process, and knowing that process can help you not only work with our products more efficiently, but also (we believe) make better quality changes.
"A strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision."
This prevents against "over-engineering", which not only would unnecessarily increase current costs of the product, but also cause expensive complications in future development in the product (for example, when an interface needs to change).
Writing failing tests first that are made to pass by writing code that satisfies the functionality tested. Contrast this to the traditional approach of writing the code first and then writing tests that supposedly confirm that the code works.
If you never saw the test fail, how do you know it's not giving a false positive? How do you know you don't have duplicate tests?
A product with the minimum set of features necessary to give the user a viable product that they can use, generally with the express purpose of soliciting feedback from customers on how they'll use it and whether they'll use it at all. This may or may not be a completely functional product; for example, the true inner workings could be based on some ugly manual process that would not be marketable as a real and scalable solution but that would allow the team to observe how the customer would use a particular interface.
Imagine spending weeks creating a resilient and fully automated process for regularly backing up all of the user information in the system, only to find out that the customer legally can't store user information and only wanted you to create something that would allow them to view and manipulate information within their current browser session. What if you had created just the interface for them according to their requirements and watched and asked questions as they used it? You would've discovered this undocumented need a lot sooner.
"Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer's changes are validated by creating a build and running automated tests against the build. By doing so, you avoid integration challenges that can happen when waiting for release day to merge changes into the release branch." -- "CI / CD / CD"
"Continuous delivery is an extension of continuous integration since it automatically deploys all code changes to a testing and/or production environment after the build stage." -- "CI / CD / CD"
"Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change [from being] deployed to production." -- "CI / CD / CD"
Gone are the days of running make prod on your IBM ThinkPad and emailing a zip file to your Ops team to be scp'd onto the production environments. If your testing and deployment process is not at least mostly automatic you're probably spending a ton of unnecessary time and inviting completely avoidable mistakes. The software is there; use it.
A developer-focused programming methodology comprised of pair programming, Test-Driven Development (TDD), delaying of decisions until the "last responsible moment" ( "LRM" ), an expectation that requirements will change, frequent communication, and small and frequent releases.
"Happy path" tests can generally be found at the "acceptance" level of testing, where overall functionality and interconnectedness of components is ensured by passing in a limited subset of possible inputs and seeing that components at least appear to be functional ("happy"). These tests are not meant to exhaustively test functionality and edge cases; that's a job for the unit tests.
Lean Product Development (LPD)
"Understanding who your users are, what their problems are, if those problems are worth solving before determining if you have the right solution for that problem. Once you do have the right solution, then it is building the smallest part of the product that is believed to provide the highest user value as fast as possible." -- "What is the Pivotal Process?"
Specifically, the "Pivotal Process" makes use of "Minimum Viable Product ( "MVP" ), Continuous Deployment ( "CI / CD / CD" ), actionable metrics, pivot or persevere, build-measure-learn cycles, business model canvas" -- "What is the Pivotal Process?"
Specifically, the "Pivotal Process" makes use of "personas, workflows, scenarios, information hierarchy, think-make-check cycles, wireframes, mental models, paper prototypes, assumptions, validation." -- "What is the Pivotal Process?"
Additional mindsets and principles
"Update when you can, not when you have to"
Especially considering the long process that sometimes accompanies releasing, due to things like OSM, it may be wise to update packages (especially JavaScript dependencies) well before you begin finalizing the release process.
A meeting between the Tech Lead (formerly anchor) and Product Manager (PM) to create new stories together that are ready for the rest of the engineers to get started on after "pointing" as a team (see IPM). The PM is there to offer his or her perspective on what is a priority, and the Tech Lead is there to offer his or her perspective on what is feasible and actionable within a reasonable amount of time.
IPM
The Iteration Planning Meeting is a meeting for all engineers and the PM of the team to ask questions and plan the next iteration (generally a week or two) of work, ultimately revolved around "pointing". Pointing is collectively voting on the point value of each story, taking into account complexity and risk of unknown obstacles.
Retro
A "retrospective" meeting for discussing the happy things, sad things, and questions (or "meh" things) that occurred over the last iteration. This may generate action items, though you may want to export those items to wherever you'll actually see and complete them. Here's some home-rolled retro software, and here's the lts-armenia board (created before we decided to rename away from LTS--TODO: consider renaming the board and coming back to fix this link).
Slack debrief
A meeting for regularly catching up on Slack channels, especially the public ones in which you are receiving your support requests and especially when you are receiving a significant number of requests. We have found this to be a reliable way to stay on top of who is waiting on an answer from us and what work we still needs to get done, in case any of it escapes capture in Tracker stories.
Scenarios
The following fictional example scenarios were created in an attempt to communicate these principles in a more engaging (and therefore hopefully more memorable) way. Warning: they are silly. Proceed at your own risk.