How Scrum Helps Developers Build Technical Skills and Flexible Architecture

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

The Purpose

Where Iterations Begin

Example of a worst-case scenario using Waterfall. Copyright © https://www.scaledagileframework.com
  • 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.
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:

  • 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?
Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design
  • 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.

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.

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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Anton Yarkov

Anton Yarkov

11 Followers

Senior Software Engineer and Engineering manager with 10+ years of experience in development of high loaded online systems.