How ideas turn into code: a glimpse into project management methology

Solutions to tough challenges rarely emerge from a vacuum. In order to understand the relationships between roles, let’s assemble a team.

Imagine a corporate intranet project aimed to collect orders made by users, manage those orders and users, gather and generate statistics. The application interacts with enterprise resource planning software (ERP) and enables automated generation of invoices of orders.

Inquisitively, we delve deeper: who are the users, and what are their habits? How do users register and log in? What products are being sold? Where does product information come from? Can different users have different purchasing conditions and price lists? What activities does the administrative process involve? Based on what criteria and under what conditions is statistics generated? What type of ERP are we dealing with, and does it have a functional interface? Does the ERP create and generate invoices, or does the intranet?

There are always so many questions that comprehensive preparation from every angle is near impossible. The best practice for solving such complex problems is thus a targeted and role-based distribution of activities and preparations.

To address the tough challenge, we assemble a team of specialists:

It's worth mentioning that in such a team, the number of specialists and roles filled need not hold a 1:1 relationship. Depending on the complexity, scope, and timeline of the project, multiple team members may fill one role, or one team member may simultaneously participate in multiple roles.

For example, a designer in the team could simultaneously hold both the user experience (UX) and user interface (UI) designer roles. Similarly, a full-stack developer in the team could act as both a front-end (FE) and back-end (BE) developer simultaneously.

An exception lies in the separation of roles in service design and software development. This is because the skill sets of designers and developers are different enough not to have significant overlap. Exceptions prove the rule and consequently there are instances of previously code savvy designers.

Numerous examples of software testers turned developer as well as analysts who have dabbled in design and/or code. Diversity is great since modern software development relies on close collaboration. A deep understanding of various roles and activities provides the team with a strong advantage.

We have assembled the team and are ready to face challenges, but what's next? Simply, software development relies on three pillars:

By breaking down the software development process into these three key pillars, it becomes easier to understand the flow of activities from initial preparation to the final quality assurance. Each phase builds upon the previous one, creating a logical and systematic progression throughout the development lifecycle.

Everything cannot be done all at once. Thus every complex task must be divided and planned in sizable chunks. The preparation process can be viewed through the following activities.

Using our imaginary intranet project as an example we can see that it too  is built from various epics: registration and login, user management, product management, order processing, statistics management, and invoice generation.

When constructing a roadmap, it's important to consider the sequence of development epics. In this example, you can't generate invoices without orders. Orders in turn can't be processed without products and users. This means it makes sense to start development from epics that serve as prerequisites for subsequent epics. 

The cornerstone of the development project is detailed research and analysis. The goal of the research is to understand and map the various components of the project and provide developers with a visual/documentary foundation for executing development.

The detailed analysis becomes the "source of truth" throughout the project. Agile is based on an iterative, regular, and cyclical method of developing features. As an addition this allows separate roles to work in parallel.

The functional content of the work is open and subject to change. In comparison to traditional waterfall-type project management, agile development does not focus on completing the entire analysis and design before the start of software development. In agile methodology, design and analysis are performed just in time or in other words just before the start of the execution process.