Agile *

Временем управлять нельзя - это не ресурс и почему у меня внутри умирает один инженер? Предлагаю это проверить, получится ли прийти к чему-то общему.

We are a brokerage platform operating in a dynamic and complex domain. This specificity comes with a set of challenges. On the one hand, it entails a high variability of scenarios and potentially significant risks associated with errors. On the other hand, it has short development iterations with frequent delivery cycles. 

In this article, we will share how we maintain the quality of our numerous backend services, which provide essential information to our trading terminals.

Sometimes it seems that jokes about management implementing Agile to do more with less aren't far from the truth. I've rarely seen development teams understand Agile as anything more than a set of ceremonies, most often associated with Scrum.

In my experience, attempts to optimize team performance often boil down to changing the internal processes within the team itself. Meanwhile, critical decisions are made outside the team, remaining in a waterfall model. This creates a disconnect: on one hand, company management strives for the flexibility of Agile, while on the other, they continue to follow rigid patterns, limiting the team and preventing it from fully realizing its potential.

This week, I was reflecting on a recent one-on-one chat with a manager in my division about keeping our backlogs clean and dealing with those tasks that just keep getting pushed back.

I jot down my thoughts and decided to share them with you. It's a common issue, right? Tasks hanging around, always getting postponed. Let's talk about the mess this creates in our backlogs and how to handle it the right way.

Check out my latest article where I dive into the art of backlog hygiene. Trust me, your team will thank you for it!

Today, many companies are transferring their development processes to Agile frameworks. In this article, I discuss how the concept of a Project and the position of classic Project Manager are transferred in accordance with the Agile paradigm.

- Continuous Improvement is also a Project, a meta-Project, a maintenance that usually lasts longer than the main development project.

- If you can fit into the Sprint boundaries with your development cycle, then the concept of Retrospective as it is formulated in SCRUM may also suit you. But if you are bigger and not oriented on CI/CD, then be ready to make a hybrid of SCRUM with classical Project Management – thanks God SCRUM is good embeddable (proven by SAFe) !

- What is left out in when we run retrospectives quarterly? – Plan and Check. The placeholder of classical SCRUM Retrospective is quite suitable for that purpose, surrounded, of course, by some additional groomings, providing required action plans and decompositions up to sprint-length steps.

I am a Project Manager. 14 years of project management, 5 years in agile framework, last 4 years in product companies, last 3 years in ABBYY, mobile technologies. I would like to share my practical experience, how we have organized the planning in ABYY Mobile Technologies having SCRUM development.

“SCRUM — you get too little, and you need to add the missing.” The story about how we adjusted the Planning procedure for yearly roadmapping and budgeting, how we have organized the SCRUM‑planning for the feature‑driven development with product development cycle 2–3 months and more.

I believe listicles have a huge potential for testing demand hypotheses. Have you tried using listicles for your demand validation? If so - let us know in the comments how this worked for you.

Do you know these "Top N something something" kind of articles? Like:
- 5 best GPS vehicle trackers
- The 14 hair growth products that actually work
- Top 10 Best CRM Software Tools in 2023
They are often referred to as "listicles" - articles presented in the form of a list.

I love them - they make picking a new phone, a movie to watch, an app to install much easier. I also use them at work all the time while looking for solutions to everyday challenges.

So what if we use one of them to benchmark our product against the best available alternatives?

A similar article should have appeared earlier, about ten or fifthteen years ago, when Agile was just starting to be implemented in companies. How many mistakes, problems, conflicts could be avoided if managers immediately approached the issue correctly ...

But during this time, the experience of "implementing" Agile in different conditions, in different companies has accumulated, which should be generalized and widely disseminated.

This article could have been born about a year ago – that's when the PVS-Studio team decided to try agile. However, we wanted to experience it hands-on before we told the world about it. Aside from introducing agile, we decided to switch from Bitbucket to a new task tracker. We also wanted to upgrade many of our internal development processes. No time for an article!

We work using Agile: Scrum, or Kanban, or any other extended project management way. Agile appeared in 2001 as a result of a long discussion between really smart guys. They just formed best practices of management into the shape of short documents - the Agile Manifesto. But what did they want to replace by the Agile way? Most of you may say that they wanted the Waterfall to go to the past. But what would you think if I tell you that the “classical” Waterfall had been a really rare thing even for those days?

My way