From Old to New — Case Study, Part 2— The Process

The story of migrating an obsolete web application to a modern stack, progressively

We had a monolith obsolete web application, with an ancient and unmaintained stack, very bad code design and bug fixes that produce either new bugs or regressions. In this series of posts, I’ll describe the migration steps.

This is the second part of the series. In the first one I presented the effort we faced — the vision and the constraints.

This part is all about The Process.

When you talk about the process, the first thing that comes to mind is — What is the process? Give me the juice! What comes after what and why?

These are all valid questions, and we will get to them in just a few short paragraphs.

But before that, we have to talk about Motivation and Objections.

The process is very important since it raises predictability and lowers the stress of missing a step. It brings clarity to the table and exposes each team member’s responsibilities and how your team members and peers expect your deliverables to look and/or behave for their work to also be productive.

A few key concepts to note in the paragraph above:

• Predictability & Stress
• Clarity
• Responsibilities & Expectations
• Productiveness

Predictability is super important when it comes to the process since it makes the process manager’s job a lot easier — if all team members align with the process then the tasks naturally flow along the pipeline without the need to “unclog the pipes”.

Predictability (or lack of it) also affects Stress. Without process, team members are constantly occupied with their performance and the quality of their work. Is the UI design good enough for Engineering to use? Is the quality of the feature I implemented high enough? Does it scale?

This is really where the process shines — since Clarity lowers stress and increases predictability! It clearly outlines the Responsibilities of each team member and by extension — how her deliverables should look and behave — so that other team members’ Expectations are met for them to be able to do their work all that much better and/or easier.

All of the above increase Productiveness.

Productiveness — the quality of being productive or having the power to produce

If you got to this point, I hope that you are properly motivated and convinced that having a process is extremely important and must be defined.

Motivation — check ✅

The thing is, that the most important part of a good process is that everyone must be on board!

A process cannot be partially implemented or practiced by only part of the team.

Each step of the process MUST happen as defined and everyone MUST be on board

And this is why Objections are so important to manage.

Eventually, at some point, you will be faced with a team member that didn’t read the motivation section above and does not think the process is important. You must get him on board, otherwise, the process will break.

There are a few ways around this. The most obvious one is to pull rank. Regardless of if it is you that has the seniority, or you talk to his manager — the effect is the same — You make him go through the motions but he is not on board. On the plus side, he might get convinced down the road, but the motivation is not there from the get-go.

The less obvious option, but one that promotes the motivation to get on board, is to lead by example.

For example — say part of the process is to write a Tech Design Document for big tasks. If your team member is not on board, he will reject it. Instead of forcing him to write it (which will probably produce a low-quality document), you write it for him and demonstrate how it enables him and makes his job easier since most of the questions are already answered. Hopefully — after once or twice, he will be convinced and get on board.

Unfortunately, given that everyone has to be part of the process for it to be effective — if the “by example” approach didn’t work after giving it a chance, pulling rank is all you have left, hoping that he will be convinced down the road. It is not ideal, but it is better than sacrificing the process.

OK, so after covering why it is important and how to get the team on board, here is the process we defined and employed as part of the original effort:

Phase 1 — Product & UI/UX Design

• Weekly meeting — Product, UI design & Tech Lead — discuss the upcoming features and see rough UX designs. Make sure it aligns with the product functionality vision and discuss what is the Tech Lead’s estimated cost to implement it — make adjustments where needed. Usually, it boils down to the “holy triangle of cost” — which is a balance of time, effort & scope. So you want this scope by this date? Great, then it is a big effort — I need more people. Oh — you need it by this date and we only have that many people? Great, then we have to reduce the scope.
• Define UI/UX deliverables Definition of Done (DoD) — how the handoff should be documented in Figma.
• The designer marks the Jira task as “Ready for review”
• The Tech Lead reviews handoff, asks questions, and makes sure that the design aligns with the Design System (DS) for progressive improvement grooming. This step is very important for making sure designs for a feature align with the tokens defined in the DS — typography, spacings, color palette, and semantic colors as well as proper usage of atoms and molecules from the component library (this is also a good point to stop and think if we should extend the component library to support a new state or maybe it is better to create a new component that extends the existing one).
• Tech Lead marks the Jira task as “Ready for backlog”
• Jira automation creates a duplicate of the design task in the engineering backlog
• Assign the engineering task to an epic (design system, infra, a specific feature epic, etc)

Phase 2 — Development

• Sprint planning —define tasks from the backlog as part of the sprint scope and assign them to team members.
• Define DoD & time/effort estimations as points for each task. We defined 1 point as 0.5 days and used Fibonacci numbers for estimations so that a task can have 1, 2, 3, 5, 8, 13, or 21 points. We used Fibonacci because errors are an inherent part of estimations, and we wanted to leave room for those estimation errors. Also, we used “Scrum Poker” — it worked well for us to identify extreme estimations.
• Non-trivial tasks (5+) require a Tech Design Document (TD) and the sprint planning and task effort estimation should reflect it (a 5 might actually take 6 or 7, to accommodate for the TD, but that is OK because it falls below the next estimation step of 8). We used this template for TDs — it is easy to write a simple TD in 30 minutes or spend 3 days on really big or complex features, and the Q&A format really makes it easy to read. A TD must be reviewed and approved by a Tech Lead before actual implementation.
• Complex tasks (13+) must be broken down into smaller sub-tasks. This is mainly because large tasks become harder to manage, implement, and review, but also it is good practice since it helps to keep tasks from spanning multiple sprints. A task with a 13+ estimation should not go into sprint planning as is.

Photo by Huma Kabakci on Unsplash

So, this was the process we used. It made a lot of sense for us and helped team members raise productivity.

In the next part, I will go over the tech stack we chose, how we evaluated alternatives and why we eventually made the decisions we made.