Agile development is about quickly responding to changes

The term “Agile” takes its roots from the Agile Manifesto written by seventeen enthusiasts and leaders of the software development industry in 2001. This Manifesto for Agile Software Development consists of only four values and twelve principles, but there is an infinite number of articles that try to explain the ideas behind them, with varying degrees of success. The goal of this article is different, so I would like to focus on what is important in the concepts of Agile from the architecture point of view.

One of the basic preconditions for the Agile approach to software development is that…

magic switch to the remote mode

I have been working with distributed teams starting from 2015. Before this, for more than six years, I had been working in co-located ones. I see many articles and blogs with recommendations for the teams who need to move urgently from their open spaces to home offices. Most of them are reasonable, and 100% helpful. However, I’m missing some crucial accents and the key message: you already have everything you need.

No illusions

There is nothing better than live communication. Even if someone invents full-size holograms like in science-fiction movies, it will not replace real interaction between people. …

Note: Velocity and Capacity are extensions to the Scrum Guide. Although it’s not a formal part of Scrum, their use is quite widespread and recommended as a best practice.


Like a speedometer in a car, which may help you calculate how many hours you might spend to cover a certain distance, Velocity helps a Team to forecast how many Sprints they need to develop new features. Following its ups and downs also allows a Team to analyze the progress they make as a result of any recently implemented improvements.

What is Velocity

Velocity is a measure of the amount of work a Team…

Product Backlog Refinement is a crucial task that makes Sprint Planning more predictable.

Imagine you are in a Sprint Planning meeting, discussing one of the Product Backlog items with your Team. It turns out that you need to get some clarification which could significantly impact estimations. However, the Product Owner can’t provide it right now as they need to talk to the Business Stakeholders. So what do you do? You could postpone the backlog item until the next Sprint? Or you could pull it into the upcoming Sprint and hope to get clarifications as soon as possible? …

Alexander Postnikov

Agile practitioner, consultant, and coach (PAL, PSM, PSPO, SPS, KMP, PSK, PSD)

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