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

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.

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.

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:

Decisions that you can roll back easily.
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.

Another tricky question is how to handle requirements changes? I want to refer to Bob Martin’s book called Clean Architecture. In this book, you will get several practical pieces of advice on keeping sustainable software architecture in the world of changing requirements. You can start by reading the short version of the clean architecture. And I will quote from the book to outline the main direction of his reasoning:

When requirements change, the difficulty in making such a change should be proportional to the scope of the change, not to the shape of the change. The difference between scope and shape often drives the growth in software development costs. It is the reason that the first year of development is much cheaper than the second, and the second year is much less expensive than the third.
The goal of software architecture is to minimize the human resources required to build and maintain the required system.

Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design

But let me give you one piece of advice that’s not in the book: developers have to build as little as possible and deliver as much as possible. Here is the reasoning:

Less new code requires less maintenance. If you are a senior software developer or an architect , think twice before writing a new shiny software component, as its maintenance costs grow progressively.
Less new code means fewer things will possibly break: if it works, don’t touch it.
Less new code means less cognitive load.
Less new code means more predictability. It’s pretty usual software developer’s attitude to creating their bicycles; I build ones myself because it helps me learn by making some new staff. But we don’t have to do it for production.

By new code, I mean the code was written by your team, of course. Sometimes you have to write your own framework from scratch, but that’s an infrequent need. But it also doesn’t mean you should pick one of the existing frameworks and stick to it. Instead, it would be best if you integrated one of the existing stable frameworks into your software with all necessary levels of abstractions around, so you could change this as soon as it stops doing what you need. This level of accuracy requires advanced hard skills.

Maybe it sounds like theoretical advice, but with some practice, it will become less cumbersome. This recommendation is pretty severe. Finally, relying on existing solutions means moving responsibilities off your shoulders.

Software developers are hired for (in most cases) making software changes as quickly as business needs. A developer can support this need by building a flexible architecture. To do this, the development team should continuously communicate with the business about requirements and direction. Simultaneously, the development team should control technical debt, maintenance costs, follow software design principles of loose coupling and high cohesion, count system interdependencies, and many other details. Not doing one of those aspects will lead to a decrease in speed and ease of making changes. You are going to have questions from the business.

One side of it is widely known as Agile Architecture or Lean Architecture. And it’s essential to understand, and I want to underline this: Agile Architecture and The Clean Architecture are tightly linked. While Agile Architecture lets you ensure that you’re are doing the right thing and leave the flexibility where it’s needed, at the same time, The Clean Architecture principles enables you to apply technical all the experience and knowledge as required.

Strong Developer

It’s a pretty vague term that is changing its meaning from organization to organization. But what’s not changing and always the fact is: you will be treated as a strong developer (resulting in all the potential benefits) if you can build a software architecture that meets business needs.

Today’s business needs are tightly related to iterative project management. And developers need to grow their skills in software design and architecture to help their businesses to grow.

It’s a challenging task for a developer to build a flexible architecture. You have to learn a lot to gain the necessary knowledge and practice a lot using those principles. At the critical moments, you will have to assert the importance of architecture over features’ urgency to the business. And you will face hard times deciding how to make a program structure flexible and clear without breaking its behavior. But it drives you to succeed in your career.

Guess how the software had changed when Android and PayPal were products designed to solve particular problems and then generalized to become a world-known. Android started as an OS for cameras. Now it’s working on more than 50% of devices across the planet. PayPal started as a money transfer for Palm OS. Currently, it serves millions of transactions from around the world.
It’s probably not just a monotonous growth from release to release. It’s a major big bang requiring a lot of adaptation (imagine the number of cludges in code, ah?), refactoring, and in some cases, re-work from scratch. We can assume this as worse and most challenging cases. But still, you never know.

And Where is Scrum?

After I made a parallel between business needs and developers hard skills, I’m ready to list the bullets how the Scrum process, being properly adopted, helps with that:

Enable teams to act with an understanding of business goals. Teams have answers to questions like Where are we?; What are we doing and why?; How do we approach the goals?; and How do we measure success? Having those answers allows developers to build more loosely coupled systems, leaving space for flexibility and future changes and becoming better and better in work estimation.
Enable teams to act independently, make decentralized decisions, and not afraid to try new ideas. Imagine you made a wrong decision for the 2-weeks sprint, built the staff, and demoed the results at the end of the sprint. It’s not that bad if you need to roll it back in terms of a large or medium-sized organization. In fact, it’s the cost of getting new knowledge. As a developer, you can try something new, being not afraid of failure. And failure is one of the best teachers.
Enable teams to control growth. If you build something large, you have to measure all the code base aspects: how maintenance costs grow? What are code quality metrics like test coverage, cyclomatic complexity, or maintainability index? How technical debt change in time? When you don’t have iterative cadence, it’s easy to skip, miss, or forget about measuring and tracking details. Not doing this doesn’t break anything immediately; instead, it means postponing to the times when you will not fix it at a reasonable price.

Summary

Some people are messing with the terms of specifications and requirements. The specification is a way to describe behavior and expectations from a product formally. Requirements include the development process as well as the process of delivery. It includes how frequently you will have to make changes. It also includes who is going to request those changes. Many of those details may look like a separate thing but may quickly end up as one of the most critical requirements, and thus, it should be reflected in software architecture.
Developers should be interested in and fully involved in the processes and methodologies of software development. This way, they might observe and consider all the hidden expectations and help businesses solve their needs. Without looking at this, you can find yourself locked on technological stacks, stuck to the wrong decisions made many years ago, degrade with the system you own forever.

Blog

How Scrum Helps Developers Build Technical Skills and Flexible Architecture

Anton Yarkov