🚢 Continuous Deployment and Kanban
Code is pushed to production everyday and we pride ourselves about having a streamlined process and workflow that allows us to do continious deployments. There are benefits and risks to pushing code so often and we have found that small incremental changes are preferred over larger deploys.
Team Prism has adopted the Kanban form of the Agile methodology. We keep a clean backlog and each developer can pull work from the backlog that has a status of “Ready to be Assigned”. This keeps a steady flow of work for each person. Anyone can add items to the backlog and the team helps prioritize backlog work based on the organizational priorities and the current PI projects.
📡 Collaboration through Strong Communication
Colloboration is at the core of the team values. Proper colloboration means you are open to receive and give feedback because we are all trying to make our products and technology better. So it is crucial to approach feedback with the correct posture. So when giving and receiving feedback, please keep an open mind and with a willingness learn and grow.
There are several channels of communication. So let’s hightlight the main channels:
Slack - the backbone of communication for teams, projects, and orginazational updates.
Github - you will be asked to perform code reviews. Please use this opporutnity to provide helpful feedback. Try to avoid being too “nit-picky”.
Jira - all tickets should have suffienct details to acheive the taks outlined in the ticket. Don’t hesitate to leave comments with suggestions or questions in Jira. We are also asked to look into customer support tickets, please be respectful and throurough when providing answers to Ops issues.
Documentation - “Plan beats no plan everytime” and “documentation beats no documentation everytime”. Whether you are reviewing a project plan, technical workflow, or a system diagram, please feel free to ask questions, add addtitional context, or create new documentation to fill in the gaps. Please share your knowledge with the rest of the team!
Project Planning
“A plan beats no plan but no plan beats a bad plan” - Unknown
On Prism, planning is tool to help a project before coding begins. In theory, every initiative that we are asked to work should have a Product Requirement Document (PRD) or a Product Brief depending on the size of the project. This is not hard fast rule but if you are unsure of what is needed, please notify the Engineering Manager or Staff Engineer to get more context on the request.
After you have a good understanding of what is being asked of you, the next step is document the technical plan. We have 2 types of technical documenation that you can use to help you with document the technical solution. 1) The Technical Requirement Document and 2) the Technical Project Plan. Each has their purpose and place on a project. Let’s explore these documents and their purpose
Technical Requirement Document
What is the Purpose? As the name implies, this document outlines the requirements needed to deliver the request work. It outlines new/existing endpoints, new data tables, and special business rules. It also documents the current behavior to help the reader with differences between current functionality vs new functionality. It also has a section for outstanding questions or research needs.
Who owns creating this doc? Technical Business Analyst. If an engineer finds that a TRD would be useful, then please take the time to create one. Please send it to the Techincal Business Analyst on the team to review.
Examples Default 2FA
Technical Project Plan
What is the Purpose? To document the technical milestones, task breakdowns, objectives, dependences, and technical flowcharts.
Who owns creating this doc? The Engineer with input from a Technical Business Analyst if needed.
Examples Nudetect HRA UIS MDS Refactor
Not all projects will need to have both a TRD and Project Plan but it is always better to have one than to not have one.
🧠Enhancement Requests
On Team Prism, we encourage constant improvement. This includes improvements to our process, our tech stack, and workflow. We welcome impromptu conversations and discussion via Slack or Standups but sometimes you need to present change in a way that needs some more attention and thought. This is where our “Enhancement Requests” can help. It is not meant to be a cumbersome process but is meant to serve as a helpful tool to begin a conversation and to pitch an idea to the broader team.
So let’s say you have a great idea and you want to discuss with the team. Below is the general process:
Do your research. Before create a jira ticket, gather facts, resources, best practices, etc. Anything you can present to help with your pitch. Because you will be discuss proposed first steps and a pathway to adopt your change.
Create an Enhancement request epic in Jira. In Jira, create a new epic ticket following the template below.
Epic Title: Enhancement Request:[name] Add the following to the description:
- Problem Statement - 1 or 2 sentences describing the current state and pain points
- Solution Summary - paragraph describing the solution you are proposing.
- Initial Implementation Steps - the first steps needed to begin to implement the solution. It also ok to outline all the steps if it is a small implementation/start process.
- How to monitor the effectiveness of the solution. How can we tell things are improving?
- Resource links
- Any additional steps after the initial implementation (optional)
see NODE-3286 as an example
Notify the engineering manager that you have a new Enhancement Pitch to review. The EM will make sure all the details are present and help with filling in the gaps if needed.
Pitch your request at the next team stand up. You pitch should be 5-10 minutes and follow-up meetings can be scheduled if neccesary.
Approval and priority. The team collectively will determine if this is a good idea to move forward by a simple vote and the priority of when to work on it. One option may include breaking up the task and implementing some pieces right away vs later.
Examples of what should and should not be considered for the Enhancement Request Process
All of the ideas below are good ideas and needed but not every enhancement needs to handled through this process. If it affecting a single service and/or will not impact the mutlple teams, then just create a Jira task and prioritize it with the help of the team.
| Good for the Enhancement Process | Not good for the Enhancement Process |
|---|---|
| ✅ Introducing a new feature flag framework | ❌ New monitoring dashboard |
| ✅ A new jira status to the developer workflow | ❌ Adding more unit tests |
| ✅ A new node library to replace an exising one | ❌ Adding additional logging |
| ✅ Splitting up a current service into multiple services | ❌ Writing more documentation or flowcharts |
| ✅ Renaming services | ❌ Code clean up to a recently built feature |
| âś… A new e2e testing framework |
If you have any questions, please reach out to the EM or big it up on the next standup. No harm if you start to talk about an enhancement and decide to create a pitch for it later.
🗝️ Asynchronously
We have people working all sorts of different hours and from all sorts of different places on Team Prism and Jack Henry. That alone makes it hard to enforce a lot of tightly-coupled workflows during the day, but that’s a feature not a bug. Most of the work you do on Team Prism shouldn’t require you to be in constant communication throughout the entire day with someone.
It’s far better for everyone’s concentration and sanity if you collaborate as though most things will get an answer eventually, but not necessarily right this second. Your first choice of action should be to post a message, a todo, or a document about what you need to explain or need to know. Then others can read it on their schedule, when the natural lulls of the day allow it, rather than being interrupted right in their peak flow time.
Don’t take that as gospel, though. Some times you really DO need to tightly collaborate with someone for an extended period of time, and that’s fine. We have pings, hangouts, screensharing, or even Slack Huddles for when nothing else will do. (But most of the time something else will).
All that being said, you should still ensure that there is ample overlap with the people you work with most of the time. While most roadblocks can just as well be cleared in 15-30-60 minutes, they become real annoying if it’s a one-day turn-around every time.