How Scrum Helps Developers Build Technical Skills and Flexible Architecture
By: Anton Yarkov
Tags: Careers, Agile, Scrum, Clean Architecture, Architecture

This is my own article re-published from DZone https://dzone.com/articles/how-scrum-helps-developers-build-technical-skills-flexible-architecture.

Copyright © Max Degtyarev (https://www.behance.net/maxdwork)

Developers who tried to build at least one product for an end-user know how many things are essential in a product: thoughtful UX, friendly UI, good performance and stability, security and data consistency, logging and maintenance, etc.

Multiply this to the number of platforms that you have to support. Add marketings and licensing, client support and bug reports, new feature requests, and competitive product pressure.

It’s hard to track everything in one head, and it is even harder to be perfect at every job. That’s why we work in teams. That’s why we use project management processes.

Nowadays, hard skills (i.e., technical skills, problem-solving skills, etc.) are the skills many developers and companies care about most. It’s a norm to keep working with the guy who has terrible Soft Skills, just because he has excellent Hard Skills, kind of.

I think that’s because it’s hard to grow and maintain those skills, and it’s easy to become off-the-track in our fast-changing world if to stop doing this technical work for a while. Some engineers are afraid of losing focus by being attracted to other ceremonies related to project management methodology. Speaking of Scrum practices, I regularly meet developers who are don’t care about it. Many engineers tend to think that their work is not related to how we manage our projects.

However, the important thing is that business needs are more than just code. And software development is not only about coding. And today, I want to show how tightly coupled those things and how it may improve or affect each other directly. As an experienced engineer myself, I think some developers will get pretty direct references on enhancing their Hard Skills while keeping in the Scrum loop.

The Purpose

Many developers pretend their work to be a loop of eat-sleep-code-repeat. It may look like a joke, but that’s really how many engineers think about their dream job. Well, it’s just me and my code, right?

I think it’s clear that the problem of this thinking is the lack of purpose.

One of the purposes of any commercial organization is earning money in exchange for goods that they made and shared on the market (would it be a product or expertise). And since many people should work in teams to create those goods, they need a kind of orchestration. Project management helps organize processes to achieve the goals, show the results, and deliver value to a customer. As a result, a company gets revenue.

In fact, organizations that lack project management frequently get into the trap of not knowing what’s going on and where to go. Finally, it causes massive layoffs.

Where Iterations Begin

People don’t like buying inferior products, so an organization should maintain quality and success with some cadence. And it’s hard to create a perfect product without large investments and efforts in terms of time, skills, and money. So, the world decided to do it iteratively. Moving step by step, measure feedback, provide a clear and transparent overview, and sometimes pivot the product to 180 degrees.

In other words, at any given moment, an organization has to decide where to go next. Top management needs to keep the balance of product value and revenue.

To achieve that, organizations have to identify the right moment and right movement, and the right point of effort.

The right point of effort can help leverage your organization, while the wrong one will lead to failure.

I want to refer to a brilliant set of articles with an excellent summary of the Theory of constraints. It tells about some straightforward ways of allocating resources to move projects forward in an efficient manner. Hundreds of organizations around the world proved it.

If you need to make one outcome from everything above, it is just one thing: the direction will be changing.

In startups, you never know what problem you will focus on 6 months from now. For example, no one knows if a video-based dating service will become a famous video- and music-streaming platform (YouTube). People could hardly imagine that games created for socialization and exploration will become co-workers’ chat (Slack). And businesses that didn’t pivot at the right moment have died.

Example of a worst-case scenario using Waterfall. Copyright © https://www.scaledagileframework.com

With this in mind, Agile methodologies started to gain popularity. The agile approach’s primary differentiator is short iterations instead of significant milestones stick to the goal, leaving the business opportunity to stop at any given point and refine the strategy. Below you can find the list of reasons why organizations would want to change the plan:

Ability to adjust quickly upon identifying the problem, the right point of effort, new revenue streams.

Opportunity to grow by re-investing revenue by reasonably small portions.

Cut the costs of failure or wrong decisions made in the beginning.

Of course, you cannot deliver a full solution in every iteration. So, many teams adopting incremental delivery using so-called CI/CD (continuous integration and continuous delivery). This approach requires developers to build systems differently.

An example of an iterative approach and incremental delivery. Copyright © https://www.scaledagileframework.com

Flexible Architecture

What does all of this mean for you as a developer? From the developer’s standpoint, it means you should avoid up-front design. It’s being proven by many organizations that up-front decisions tend to be wrong in most cases, so teams have to split their work into chunks and make smaller decisions at every step. I want to refer to another excellent article outlining more details specific to Agile. But software developers should keep in mind that there are two types of decisions that you can make in software design:

1. Decisions that you can roll back easily.

2. Decisions that are hard to roll back.

Decision 2s are the most problematic. Using the term of up-front design, I mean the set of decisions that one cannot rollback. As software developers, we have to think about the flexibility of software architecture. We have to leave the opportunity to postpone the decision of type 2 for the latter. Later you make the decision; more facts you have that confirm its correctness. In other words, think about questions like this:

If you are OK on vendor lock today, would you be feeling so in 2 years after your team has made 2 million lines of code?

If you stick to a particular framework, would it be possible to switch to another framework within one week (when the first one becomes outdated or contain many critical issues)?

If you choose to use a new shiny programming language, are you confident enough to have enough knowledgeable colleagues to maintain the project for several years?

Developers’ hard skills grow when they learn to notice the need for such decisions; they make a thoughtful analysis and identify solutions to make their architecture clear and flexible.

If you or developers in your team already apply this type of thinking, then you’re probably on the safe side. If you are not, your hard skills will grow as you learn to notice the need for such decisions; you and your team will start making a thoughtful analysis and identifying solutions to make architecture clear and flexible.