The NOSCRUM Process

In the Portland Acorns office, we developed a process named NOSCRUM. As a full stack satellite office, we work fairly autonomously on projects. Our team is much smaller than our HQ in Irvine (~9% of the size) so we needed to develop a process that worked well for a smaller team, kept our velocity going strong, and just enough process to keep the team comfortable. I was asked to share this by a handful of people so I decided I would share with the world.

The name, however, isn’t original and I owe it to Kris Gale who used this term at Yammer during our tenure there. However, it wasn’t a written process and more of a word-of-mouth philosophy. Since NOSCRUM grew organically at Yammer it was hard to explain the process to a team of new people outside the org without it written down. Internally we have a written document with some internal lingo and references to tools we use. Here I tried to make it more general for anyone to use.

The Glossary

Below are some definitions and materials needed in NOSCRUM. These are described more in detail after “The NOSCRUM Lifecycle” is described.

“Big Board”: A “Big Board” is a board of all projects. These are high-level and have a spec associated with them. Some teams have a physical board while some use digital versions.

“Project Lead”: Someone who leads a project but doesn’t necessarily have an official “lead” job title. For example, a junior engineer or associate product manager can be a lead on a project. There will be leads for each vertical of the project such as engineer and product.

The Rules

All of this is explained in more detail but these are the high-level rules to NOSCRUM:

1. There are no sprints. There is only the deadline.
2. All projects have a spec associated with them that all leads agree to before any work is started.
3. Every project has a kickoff with all stakeholders.
4. Individual contributors should only work on one Big Board item at a time.
5. Cut features and not quality.

The NOSCRUM Lifecycle

An Idea Is Conceived

A project is conceived somewhere. It could come from engineering, product, or even support. The project idea could be a simple verbal idea pitched to another team or could be fleshed out with a full spec. At this point though, for the product team, they will need to get it on the Big Board before anyone can work on it on engineering. For engineering, it needs to be approved at the Director level or above before it can be on the Big Board.

Product or Engineering, depending on the project type, will provide a spec in the form of a document such as a Google Doc. The document will have a summary of the project, why we’re doing it, requirements, designs or wireframes, KPIs, estimate timelines, and unknowns. A project should then be created in the software you use to track tasks. In Jira, you would create an Epic while GitHub you would create a project. Sticky notes work just as well if your team isn’t distributed.

The project leads for the product and engineering side should meet to talk about a timeline, any concerns or unknowns, and plan for what people will be needed (e.g. “requires 2 backend, 1 frontend, and 1 design person”). This should be a collaborative meeting where the scope is decreased or increased depending on timelines and any other factors that come up.

Designs may or may not be needed for the project. If a design is needed and none have been provided yet it’s up to the leads to decide if having no designs up front will hinder the project. Often projects can start without designs as long as the inputs and outputs of the project are defined and locked down. Projects shouldn’t begin until the leads feel like enough is locked down to start on.

Once all parties agree the kickoff begins!

It’s Begun

A kickoff meeting should be scheduled and set by a project lead. The meeting should go through the spec and allow everyone on the project to give feedback. The kickoff should include everyone who is touching it including, but not limited to, securities, support, QA, and so on. A kick-off doesn’t need to be super formal. If it’s something small a kick off can be a 15-minute meeting just to go through the document real quick.

In each spec document there should be a place for each team such backend, frontend, design, etc to put in the estimated days or weeks to complete based on what they know so far in this document. The document should also have a section to write unknowns. The leads should then figure out those unknowns as fast as possible and make those no longer unknowns.

Project dependencies will also be worked out during this process so that teams understand the order of operations for all project components. This is important so that all teams can manage expectations for each other and ensure that blocking issues can be resolved in a timely and efficient manner.

Next, each of team members should create tickets for how they’re going to complete the project. The reason we have each contributor make their own tickets rather than a manager or product person is because they understand the system best. Engineers building it look at the spec and break it out how they think it makes sense. Some people have one mega ticket with a checklist inside in the description, some make lots of top-level tickets, and some use sub tickets that correspond with specific pull requests. These are all fine. Tickets are meant just so everyone knows what people are working on and the progress of the project. You would associate these tickets with your Epic or project in your software.

It’s important to note that because everyone agreed to the given timeline tickets do not need to be in a grooming process because the spec itself should have been groomed.

To assist QA, it’s usually a good idea to provide steps on verifying the tickets with sample data, steps to test, and whatever else within the tickets created.

Development

NOSCRUM uses Kanban style over sprints for tracking tickets. In Kanban, there is no specific due date for an individual ticket or task, just the project as a whole. It’s just “get it done as fast as you can” and when all those tasks are done the project is done.

This means you would have some sort of board with multiple columns. Jira, GitHub, Trello, etc all support this. You will want 5 columns: To Do, In Progress, QA, Product UAT, and Done.

Put all tickets for the project in a To Do column before you start and once you start on one of them you move it to In Progress. You want to keep as little in progress as possible. Focus on a single task at a time if you can. If you’re blocked it’s good practice to mark the task as blocked somehow in the software you use and let the project team know.

Once it’s merged and deployed to your development or staging environment QA can start testing. Move the ticket to a QA column. If a ticket passes the QA member will move to Product UAT otherwise they will reopen it. The Product team would then verify those tickets that are visible to customers (things like new screens, logos, etc, not new API responses etc.) and move it to the Done column or reopen it. Note: this flow is visualized at the end of the guide.

There should be weekly stand-ups as it progresses. This is a chance for anyone to say any blockers they’ve hit and their progress and if they’ve run into anything that could mean missing the deadline. People are strongly encouraged to raise these flags outside of stand up. The sooner everyone knows about blockers or anything that could cause us to miss our deadline the faster the leads can react to cut scope or renegotiate the deadline.

In the case of something running later than planned and scope needs to be cut you should always cut out the features and not the quality. If there is a feature that is too complex to get done in time, ask yourself if this feature is truly needed for launch. If not cut it. If it is needed, try to cut down the scope of that specific feature. If all else fails we suggest pushing the deadline not the quality of the project.

Note: For smaller teams without QA or a Product specific team the QA and Product columns can be just “Test” or “Verify” columns.

It’s Completed

A project is completed when everything is done and deployed. For a warranty period decided by the leads, the same team members should be taking any bugs pertaining to those new features and minor improvements such as more tests, more comments, and general clean up. This is usually 1–2 weeks.

Once it’s deployed and done, but before the end of the warranty period, a retro meeting should be had for the project. For small projects this can be 30 minutes or for large projects this could be an hour. The meetings are meant to talk about what worked well, what didn’t work well, and action items for the next project. Retros are per project because if you’re not in the project it’s hard to get context or you’re zoning out while they talk about their project.

Ongoing Support

The warranty period allows the team members that have the most knowledge about the project to fix anything major after its released. After the warranty period is over these team members are no longer responsible to fix these features. That falls to the Support Crew.

The Support Crew is just like a project team in that it’s full stack including Customer Support, QA, etc and the team disbands after a period of time. The team members for this are rotated just like a project as well. This is often a good team to put new members into or people who had just come off a stressful project. It gives new people an opportunity to go through deployment cycles and the organization’s processes. For both old and new members it gives them a chance to work on systems they’ve never worked on before which makes the team much more rounded or “T-shaped” and gives them confidence on working on those systems in a project later.

This setup always makes sure your bugs are being worked on and doesn’t pull other contributors off their projects with specific deadlines. Pulling project teams off the project into bugs makes timelines much harder to estimate and more unreliable.

For teams with “on call duty”, this usually becomes this team. This team never takes on new features. It only focuses on bug fixes and improvements to existing features. For example, a button that doesn’t work on a certain platform or a button that is too small and hard to tap on mobile so they make it bigger would be something the support team would handle. However, the team wouldn’t add a new button.

Note: For smaller teams, there’s usually not enough resources for a Support Crew. This team isn’t crucial to NOSCRUM if you’re lacking resources but as your team grows we strongly suggest thinking about having even a small Support Crew of one person if you can.

What’s a Big Board

A Big Board is a project board with company priorities ranked from most to least and contains information such as who the leads are, the team members, date, and so forth. A physical board or a digital board both work fine. Digitally you can simply use Google Sheets or software like Airtable. Here’s some information we suggest you put on yours:

1. Project name
2. Link to the project spec
3. Status (examples: “Not Started”, “In Progress”, “On Hold”, “Delivered”)
4. Target Date
5. Project Lead
6. Project Team

Here’s a basic version you could make in Google Sheets. Note that in row 3 there’s a project with some of the team members as row 1. That means it can’t be started until the first project is complete and why it says “Not Started”

Some additional fields that can be helpful are:

1. Product Lead (like an engineering lead but on the product side)
2. Health (use colors like green, yellow, red, black to indicate if it is on time, looks like it’s going to be late, is late, or blocked)
3. Latest update (a sentence or two of the current status. For example, “waiting on designs”, “in QA” and so forth)

What’s an Engineering Lead

In engineering, anyone can be an engineering lead for a project. Generally, bigger more complex projects would be given to a lead or senior engineer, however, small projects are given to mid-level or even junior level people. We heartily believe in giving people opportunities to shine so everyone will eventually get a chance to lead a project.

The responsibilities of an engineering lead are:

1. They are the decision maker on tech for the project. They’re encouraged to get opinions but since they know the project the best they can decide how to move forward. For example, a choice between doing something “right” vs doing something that’s a stopgap until a future project.
2. They are the person other engineers should ask first. For example, “was the button supposed to do X or Y?” should be asked to the project lead before bubbling it up. The lead should have the best understanding of the project so they will probably know better than anyone else in engineering.
3. They are the one making sure the project is on pace. The lead should bubble up any blockers, concerns, or questions to the manager or product lead as soon as they come up. “No news is good news” in terms of timelines and blockers so if the team hasn’t heard anything they will let you keep on getting things done.

Conclusion

NOSCRUM is something we feel works well. It distributes the ownership and keeps the team’s velocity strong while remaining flexible. However, we know that this process itself is a process of learning and experimentation. You can consider this NOSCRUM 1.0 and edits to this I’ll keep updated and put notes below of what changed. If there are any major changes there will be write-ups about what changed and the details of why.

Bonus:

This link has a video and explanation of the Big Board at Yammer so you can get another point of view of the Big Board in use in the real world: http://fasterthan20.com/2013/12/hack-big-board-at-yammer-and-microsoft/