Product Development: A How-To Guide from Red Collar, Part Two

Red Collar
8 min readApr 3, 2024

--

In the first part, we described the initial stages of product development at Red Collar. This time, we’ll discuss how work is structured within the Agile framework and the advantages and disadvantages of the flexible development methodology.

From “Waterfall” to Agile

Thus, through analytics and research, we understood what product the audience needs. With prototypes, we showed its prospective look, refined the design concept, and finalized it. Architects and developers pondered the technical foundation of the future product. Now, we’re defining a list of what and within what timelines we plan to develop — creating a project roadmap.

It’s crucial for us to correctly assess which functionalities are primary and which are secondary. Agile helps us in this regard.

Why Agile?

Much has been written about Agile in a clear and comprehensive way. We’d add that Agile is not so much a methodology as it is a philosophy, within which a flexible approach is realized using various tools. For us, the primary tool is Scrum, which is a methodology in itself.

It helps us break down development into stages we can understand — so-called “sprints,” during which, typically over two weeks, we complete tasks related to creating specific functionalities. But let’s take it step by step.

Agile: The Philosophy of Flexibility

Within the Agile framework, we develop digital products flexibly, iteratively, and transparently: step by step, we create and add new functionalities, gradually refine the product, and promptly make necessary changes.

What changes might these be? Typically, this is related to the changing market and how well the future digital product meets this market’s requirements.

For example, we started developing a certain service before COVID-19, and when the pandemic hit, we realized that the functionality we initially planned would no longer satisfy the audience’s needs. In such cases, we need to change priorities, analyze which features to add, incorporate them into the project roadmap, and continue development.

Agile, as a philosophy, and Scrum, as a way to implement it, imply active participation from the client in all processes and at all stages — this allows for necessary adjustments to the future product, control costs, and create exactly the product the market and the client need.

Being flexible — in practice, this is not only about being ready to change requirements but also about the development team and the client being ready for compromises and understanding. The market and the internal processes of the client change faster than serious products are developed. Sometimes, during the development process, the product significantly deviates from the original concept, influenced by the team, the global situation, and the client’s worldview.

— Irina Zakurdaeva, System Analyst at Red Collar

Agile is often depicted as a layered cake, where each layer is a stage of development: analytics, design, development, and so on. In the linear approach (like “Waterfall”), each stage typically consists of a single element, while in Agile, each stage is multi-layered. If we try to “slice” such a cake, each piece will contain all the main components of development. Each slice of this “cake” provides an overview of the project.

However, Agile isn’t without its drawbacks. It works well when the client is involved. That is, when there’s an opportunity to spend time on regular calls, monitor, and accept the work we completed during the sprint.

If the acceptance stage is omitted, the essence of the approach collapses.

The very flexibility that is a plus can also play a cruel joke on Agile.

Imagine: we’ve developed a roadmap and prioritized features, but after some time, the client comes up with new ideas for improving the product. It seems that all ideas are correct, but now we’ve deviated from the deadlines, forgotten about the priorities, and inflated the budget.

It’s important to maintain a balance between customer orientation and common sense: to assess what’s really important and what can be added to the backlog — that is, the list of tasks we will add after the main ones.

— Sergey Chistyakov, Technical Director at Red Collar

Scrum: The Tool of Flexibility

Scrum is a methodology that allows us to embody the philosophy of flexibility in our work, and we at Red Collar strive to follow it. A Scrum master — a specialist who knows how to organize the team’s work and all processes within Scrum so that they are understandable, controllable, and transparent to us and the client — helps us in this.

First, Scrum helps gather the ideal team within the company and organize processes within the team so that all participants know their goal, what tasks are currently at hand, and what awaits in the future.

Second, this methodology helps to hear and listen to the client, understand the market, and adapt — that is, be ready to make changes if they improve the product.

If we visualize the processes — or more correctly, ceremonies — within Scrum, it looks like a “donut” consisting of several layers.

The outer layer is the overall cycle of working on a digital product, within which two streams run in parallel.

The first stream is the product backlog, sprint backlog, and increment or demo.

The product backlog is a strategy that allows us to see where the product is heading and what we need to do.

The sprint backlog is the tasks we need to develop within a specific sprint.

The increment is precisely the feature we’ve successfully developed within the sprint.

The demo is a way to show the client and the team what we’ve implemented during the sprint. Moreover, it helps match the client’s expectations with what we were able to develop.

As a rule, a demo is held once or twice a sprint, its main feature being that the client is always involved. The demo transparently demonstrates where time and money were spent. At this point, the client can influence the further course of development.

The second stream consists of routine process ceremonies: sprint planning, dailies, sprint review, and retro.

Sprint planning is about planning the volume of work and its assessment when the team understands how many story points and tasks it can complete based on the goals, overall roadmap, and current situation. Planning is based on the team’s “velocity” — the volume of tasks each development member can complete within one sprint.

Dailies (planning meetings) are short daily meetings (usually no longer than 15 minutes) where teams discuss problems arising during development and current plans for each day. Dailies provide a quick snapshot for management and the team.

The review (Sprint Review or Demo) is a meeting at the end of the sprint where the team presents intermediate results to stakeholders to receive feedback.

For the whole team, a retro takes place — this ceremony allows each team member to express the difficulties encountered during development, what they would like to improve, and what went well. This helps the project manager and Scrum master adjust processes so that all team members can comfortably and efficiently perform their tasks.

Beginning Development

Within the Scrum methodology, we work in sprints — time intervals from one to four weeks, during which the team adds specific features to the future digital product.

Essentially, the result of each sprint is a ready-to-use feature.

So, we start moving along the roadmap: assessing what we will take in the nearest sprint and what major and minor tasks we will include.

It’s now important for us to correctly assess which functionalities are the most priority and what needs to be developed first, what we plan for later, and what can be sent to the backlog altogether. We decompose all these elements: create large tasks (epics) and break them into smaller ones (user stories), which, in turn, are divided into even smaller ones (tasks). User stories and tasks are precisely what we will include in the sprints. Such detailed and thorough breaking down of large tasks into smaller ones makes the development more controllable, flexible, and transparent.

The tasks distributed across the sprints are shared with the team: designers, developers, and QA engineers. All team members begin work in parallel.

For example, while the design is being prepared, the backend developer can start working on the backend, the frontend developer can prepare the library of elements, at the same time, the technical writer or analyst develops the documentation, and QA engineers write test cases and checklists.

When the design is ready, the backend developer will make changes that couldn’t be considered without the design, and the frontend developer begins their main volume of work.

Typically, a classic sprint lasts two weeks, but depending on the complexity of the tasks and the client’s needs, the sprint can be shortened to one week or, conversely, extended to four.

The result of each sprint is a ready feature that performs a specific function: for instance, user registration, product comparison, adding a product to the cart, creating a wishlist, and so on.

Development is considered complete when all the tasks outlined in the project roadmap are completed and accepted by QA engineers, and when the client receives a ready-to-use product that meets all their requirements.

Not by Agile Alone

As you might have guessed, we value Agile for the flexibility and transparency of processes within the team. Also, the expenditure of resources must be transparent and understandable to the client, so we work on a “Time & Materials” system.

Within this system, we compile and send weekly reports detailing what was done: how many hours were spent and on what. With this approach, the client can balance the budget and understand what and to what extent resources were spent.

Wrapping Up

Having planned work according to Agile, adjusted the team’s work according to Scrum, and reported on work according to “Time & Materials,” we brought the project to its logical conclusion — its release. But our work doesn’t end there; often, within product development, we continue collaborating with the client: supporting the ready digital product to keep it up-to-date and meet all tasks and requirements.

Our series of publications doesn’t end here: next, we’ll talk in more detail about how each team works on creating digital products, what the tasks are, and what results this leads to.

Follow us on LinkedIn and X (Twitter)!

--

--

Red Collar

🏆 An award-winning agency with over a decade of expertise, delivering design and development services globally | 🌍 redcollar.co | 📩 hello@redcollar.co